Saying What, Not How

Imagine hiring an architect to design your dream house. You would not say, 'First draw a rectangle on paper, then add a triangle on top for the roof, then draw squares for windows.' You would say, 'I want a three-bedroom house with big windows, an open kitchen, and a porch facing the backyard.' You describe what you want — the outcome — and let the expert figure out how to get there. Prompting an AI to build something works the same way. The AI is the expert at code, structure, and technique. Your job is to tell it what you need, not to walk it through every step.

Outcome Language vs. Process Language

Process language tells the AI what to do step by step: 'First create a variable called score. Then write a function called addPoints. Then...' This sounds precise, but it actually makes your prompt worse. You are now responsible for every technical decision, and you are probably missing dozens of details the AI would have handled better on its own. Outcome language describes what the finished thing should do or be: 'I need a score tracker that starts at zero, adds 10 points when the player presses the spacebar, and displays the current score in the top-right corner of the screen.' Notice the difference. The outcome version says nothing about variable names, function names, or file structure. It does not need to. The AI handles those. You handle what matters: what the finished thing should do for the user.

Here is a side-by-side comparison on the same task — a button that changes color when clicked: Process prompt: 'Add a click event listener to the button. In the listener function, check if the button's class includes blue. If it does, remove blue and add red. Otherwise remove red and add blue.' Outcome prompt: 'Make the button toggle between blue and red each time it is clicked.' Both prompts could produce the same code. But the outcome prompt is shorter, clearer, and leaves room for the AI to choose a cleaner implementation. The process prompt locks you into a specific technique that may not even be the best one — and if you got any detail wrong, the AI follows your wrong instructions precisely.

When Process Language Is Useful

Process language is not always wrong. There are two situations where specifying the how makes sense: 1. You have a strong technical reason. If a project must use a specific library, structure, or API because other code depends on it, say so. 'Use the Fetch API, not Axios' is a meaningful constraint, not micromanagement. 2. You are correcting something. If the AI built the feature wrong, you sometimes need to say how to fix it: 'Instead of removing the element, hide it with CSS so it can be shown again later.' That is process language in service of a specific correction. Outside those cases, stay in outcome language. You will get better results faster.