The first prompt people learn is usually a request for a feature. "Add workout logging." "Make a dashboard." "Build a settings page." The agent can act on that, but it has to guess what the finished thing should feel like. It will make dozens of small choices while it works, and every choice it guesses wrong becomes something you have to unwind later.
A useful prompt describes the result in your terms. You do not need to tell the agent how to write the code. You need to tell it what you should be able to do when the work is finished.
I am building a workout tracker for myself, so I will use the same feature three ways.
Start with the moment of use
Here is the feature request version:
Add a way to log sets.
The agent might build a form with five fields and a Save button. It has completed the request, but the result could still be annoying in the gym.
Here is the same request with the result filled in:
When I am standing in the gym, I want to log another set with one tap.
Use the weight and reps from my last set as the starting values. Let me
change either value before I save. After I save, keep me on the same
exercise and show the new set in the list.
This gives the agent four decisions it no longer has to invent: the action should be fast, the last values should carry forward, editing happens before saving, and saving should not send me to another screen.
You can write this kind of prompt without knowing anything about code. Describe where you are, what you are trying to do, what should already be on the screen, and what should happen next. If timing matters, say so. "I will use this with one hand" is more useful than naming a layout system you read about online.
Give context only when it changes the answer
More context does not automatically make a better prompt. The agent already has the project files, its standing rules, and the conversation. Repeating all of that makes the important part harder to see.
Include the facts that change what a good result looks like:
This is only for me. I use it on my phone between sets. I often repeat
the same weight and reps. I care more about logging quickly than seeing
every detail on this screen.
Leave out facts that do not affect this feature. The app's future pricing, every screen you might build, and a long description of the whole idea can stay in the project docs. If the agent needs one of those details, it can read the file or ask.
There is one exception. Repeat a constraint when getting it wrong would be expensive. If the app must keep all data on your computer, say that again when a feature touches storage. If you have already decided there will be no accounts, repeat it when the agent proposes sharing. Important constraints should also live in the project's standing rules so you do not have to remember them in every conversation.
Ask it to show the decision
Some work is cheap to change after it is built. Some is easier to settle while it is still a sketch. Screens, flows, and tool choices are usually in the second group.
For the workout logger, I would add:
Before you build it, show me the flow in a small mockup. I want to see
how many taps it takes to log a second set.
You can ask for a mockup, a short plan, two options, or a plain explanation. Pick the smallest thing that lets you judge the choice. You do not need a long planning document for a button label, and you should not wait for a finished app to find out the main action takes four screens.
Correct the first wrong turn
The first result is part of the conversation. Look at it as soon as there is something to see. Try the button, read the page, or walk through the flow. If it feels wrong, say what happened and what you expected:
Saving a set takes me back to the workout list. I expected to stay on
this exercise so I could log the next set. Change that flow and remove
anything that only supported the old one.
That last sentence matters. Agents are quick to add a second path while leaving the first one behind. Asking it to replace the wrong approach keeps the project from collecting two versions of the same idea.
Correcting course after the first screen costs very little. Correcting it after five more features have been built around the wrong flow costs much more. You do not need a perfect prompt up front. You need a clear result, the few facts that shape it, and a quick look at what the agent made.
I build Koda, a Mac app where you describe the result and the agent handles the code. The same prompting method works with any coding agent.
Use this shape for your next prompt:
I want to [the result you want] while [where or when you will use it]. When I [take the main action], I expect [what should happen next]. The important constraints are [only the facts that change the answer]. Before you build it, show me the smallest plan or mockup that will let me check the flow. Improve the existing version if there is one, and remove anything this replaces. Then build it and try the full flow yourself.