Good prompts aren't clever. They answer one question: how is the model supposed to know what I mean? Learn the habits of people who prompt agents all day: point to where knowledge lives, show a gold standard, state constraints and exit criteria, and use the short phrases that carry a lot of discipline.
Key takeaways
- Ask of every prompt: how is the model supposed to know what I mean? Training data, the codebase, the context, or me?
- Point to where knowledge lives: files, folders, docs, screenshots, a working example to imitate.
- Describe the task, the guardrails and the exit criteria, then let the agent work. Don't script every step.
- Short phrases like “first run the tests” or “use red/green TDD” carry a lot of built-in discipline.
- You can just talk to it: ask why, push back, ask it to simplify, ask it to ask you questions.
Try it with your agent
Take a prompt you'd normally fire off:
Here's a request: "[your usual one-liner]" Don't do it yet. Tell me what information you'd be missing to do it well, where in the codebase you'd look for it, and ask me up to 3 questions to fill the gaps.
Transcript
Intro
The best prompts for coding agents aren't clever. There are no magic words. They just answer one question better than most people bother to.
The kidnapped engineer
Thorsten Ball, who builds the Amp agent, uses this picture. Imagine a brilliant senior engineer, kidnapped and locked in a room, with only a computer and your note: fix the bug with the upload. What do they know? What are they missing?
Where knowledge comes from
His core question is: how is the model supposed to know what I mean? There are only four places the answer can come from. Its training data, which knows general programming. Your codebase, if it can find the right part. Whatever is already in its context. And your head, which it can only reach through your prompt.
A better prompt
Compare two prompts. The first is the note in the locked room. The second answers the question. It describes the symptom, points to the files, names a working example to copy, states the constraint, and says what done looks like.
Look at what each part does. The symptom says what's wrong. The pointers save the agent from reading the whole repo. The gold standard shows what good looks like. The constraint closes a gap. And the exit criteria tell it when to stop.
The one-two punch
Thorsten's favorite trick is the one-two punch. Instead of cramming everything into the first prompt, he first asks the agent to find the relevant code. That loads the right files into its context. Then he makes the real request.
Show, don't describe
Notice how much work examples do. Simon Willison often tells the agent to imitate existing logic elsewhere in the project, instead of describing the rules. And Thorsten says ninety percent of his prompts include a screenshot: a bug, a design, a customer message. Pictures and examples are cheap, dense context.
Guardrails and exit
How much detail is right? Boris Cherny warns against scripting every step. With modern models, describe the task, describe the guardrails, describe the exit criteria, and then let the model cook. He even suggests giving it tasks slightly harder than you think it can do.
Phrases that pack a punch
Some short phrases carry a surprising amount of discipline, because the habits are already baked into the models. Simon Willison starts sessions with: first run the tests. That's four words, and the agent will keep running them. Use red green TDD. Ask me questions if anything is unclear, because agents rarely ask on their own. And copy how another part of the code does it.
Just talk to it
And remember you can just talk to it. Cat Wu from the Claude Code team says even experts forget this. Output too complicated? Say: simplify it. Something looks off? Ask why it made that choice. Airbnb's engineers found that after a few rounds of pushing back, the agent often admits it was wrong. You can even dictate by voice. What matters is how much information you give, not how polished it sounds.
Executive communication
Thariq Shihipar from the Claude Code team sums it up. Sufficiently advanced prompting is indistinguishable from sufficiently advanced executive communication. Clear context, clear goal, clear constraints. The same things that make a great brief for a human.
Quick check
Quick check. Which addition would most improve the prompt: fix the flaky checkout test? Tap your answer.
Try it
Try this with a prompt you'd normally send. Instead of running it, ask the agent what it would be missing and where it would look. You'll quickly learn which parts of your intent never made it out of your head.
Recap
Recap. Ask how the model is supposed to know what you mean. Point it at files, examples and screenshots. Give guardrails and exit criteria, then let it cook. And talk to it like a colleague. Next: the habit that makes agents trustworthy. Giving them a way to check their own work.