A prompt is a work order
The most important mindset shift: stop treating prompts like search queries. Treat them like work orders. A work order explains what to do, what not to do, and what the result should look like.
When you hand a task to someone on your team, you don't just say "handle the cache thing." You briefly explain what it's about, what matters, in what format the result is needed, and what the risks are. Exactly the same elements belong in a good prompt.
Five building blocks
Extended experimentation has settled on five elements as a scaffold:
- Goal: what should be true at the end? How do I know the task is done?
- Context: language, framework, constraints, data structures. What the model needs to know to respond specifically.
- Format: code block? Step by step? Diff? Code only, no explanation? Without a directive, the model decides for itself.
- Boundaries: what shouldn't happen. Which changes are off-limits, which assumptions you're not allowed to make.
- Verification: how do you know the answer is correct. Test description, success criterion, example output.
Common mistakes
- Overly open questions: "How do I improve this code?" — improve for what? Performance, readability, security?
- Missing context: a question about code without the code. The model has to guess, and guessing leads to hallucinations.
- Several tasks in one prompt: "write, optimize, document, and test." None of the four gets handled thoroughly enough.
- No boundaries: without explicit limits, the model allows itself library swaps, architecture changes, full rewrites.
- Pleasantries instead of substance: "please kindly help me..." costs tokens and adds no information.
Iteration is part of it
A good prompt often doesn't come together on the first try. The first attempt is an approximation, the second refines it, the third is usually precise. That iteration doesn't cost time — it saves time.
What helps while iterating: honestly checking which of the five spots the first prompt fell short on. Was the goal too vague? Was context missing? That's what shapes the next attempt.
Keep good prompts
Once a prompt fits a task well, I move it into a central collection: code reviews, bug diagnosis, refactoring plans, PR descriptions. One proven prompt per task type, refined over weeks.
In a team this is even more valuable: a shared collection of good prompts is one of the most underrated forms of engineering knowledge.
What bad answers tell you
Bad answers are a source of learning. Was the answer generic? Context was missing. Did the model answer a different question? The goal was unclear. Did it come back in the wrong format? The format spec was missing.
Reading bad answers as feedback on your own prompt gets you learning faster than blaming them on the model.