Better prompts for coding: a practical field guide
Stop writing 'fix this'. A short, opinionated guide to prompts that consistently get usable code on the first try.
The single biggest determinant of AI coding quality is the prompt. Not the model, not the tool, not the tier. After watching hundreds of prompts across dozens of engineers, here is what consistently works.
The four ingredients
- Context: which files matter, what they do, and what constraints apply.
- Goal: what 'done' looks like, in one sentence.
- Constraints: language, framework, style, anything off-limits.
- Verification: how the model (or you) will know it worked.
A template that works
Try this shape: 'In <file>, we need <goal>. The relevant code is below. Use <library/style>. Do not change <area>. When done, the test in <file> should pass.'
It feels mechanical. It also routinely turns a 'fix this' prompt that produced garbage into a one-shot success.
What to leave out
Do not include code the model does not need. Long prompts dilute attention and make 'lost in the middle' more likely. Curate ruthlessly.
Do not bury the goal. Put it in the first sentence. Models, like tired humans, pay most attention to the start and end of long messages.
Iteration patterns that work
- If the first answer is wrong, do not just say 'no, again'. Say what was wrong and why.
- If the model keeps misunderstanding, restart the conversation with a tighter prompt instead of piling on corrections.
- Ask for a plan before code on anything spanning more than one file.
- Ask for tests before the implementation when correctness matters more than speed.
The meta-point
Prompting is engineering. It deserves the same care you would give to writing a good ticket for a contractor. Five extra minutes spent on the prompt saves an hour of cleanup later.