The six parts of a request
Most disappointing output comes from a request that left the model to guess. Each part below exists to close one specific guess.
| Part | Prevents |
|---|---|
| Context — the actual file, error, or data | Answers about a codebase you don't have |
| Task — one concrete change | A sprawling refactor you didn't ask for |
| Shape — the output format or signature | Rewriting the result to fit |
| Constraints — what not to do | New dependencies, new patterns, new files |
| Purpose — what it's for | Wrong trade-offs made silently |
| Example — one input and expected output | Ambiguity about edge cases |
[Context] Here is src/lib/pricing.ts and the failing test output.[Task] Fix the rounding so totals never end in .005 rounding down.[Shape] Keep the existing calculateTotal signature.[Constraint] No new dependencies. Money stays integer paise.[Purpose] This runs on every invoice; correctness beats elegance.[Example] calculateTotal([1005, 1005]) should return 2010, not 2009.Give real context, not descriptions of it
The single largest quality difference is whether you pasted the actual thing. A described error is a summary that has already lost the detail that identifies the cause. A described file is your mental model of the file, which is often wrong in exactly the way that caused the bug.
- Paste the full error, including the stack trace, not the first line
- Paste the file, or the relevant function plus its imports and types
- Paste a real sample of the data, with anything sensitive replaced by realistic dummy values
- Say what you already tried and what it did — this prevents the first three suggestions being things you've ruled out
Specify the shape you want back
Left unspecified, output defaults to a tutorial: explanation, a complete file, and commentary. Usually you want a diff, or one function, or three options with trade-offs. Asking is enough.
- "Only the changed function, no explanation" — for a small fix
- "Three approaches with trade-offs, no code yet" — when the decision matters more than the typing
- "A unified diff against the file I pasted" — when you'll apply it by hand
- "TypeScript, strict mode, no `any`" — a constraint that eliminates a whole class of returned code
Iterating on a bad result
When output is wrong, the instinct is to rephrase the whole request and start again. That throws away everything that was right. Correcting is usually faster and produces better results.
- Say specifically what's wrong"This adds a dependency; do it with the standard library" beats "try again".
- Give the new information the failure revealedThe real error from running it, or the type that turned out to be different.
- Keep the parts that were right"The structure is correct; only the date handling is wrong."
- After three failed attempts, start freshBy then the history contains three wrong approaches, and they anchor everything that follows.
When the prompt isn't the problem
Prompting is a real skill with a low ceiling. Past a point, better wording stops helping, and the honest diagnosis is one of these:
- The task depends on knowledge of your systems that isn't in the request and can't be — no phrasing fixes missing information
- You don't yet know what correct looks like, so no specification is possible. Work that out first, on paper
- The problem is genuinely novel, which is where these tools are weakest and you are most needed
- The codebase is inconsistent, so "match the existing style" points at three different styles
Common mistakes
- Describing an error instead of pasting it
- Asking for a large feature in one request rather than several reviewable steps
- Rephrasing from scratch instead of correcting one specific thing
- Leaving output format unspecified and then rewriting the result
- Pasting real credentials or customer data into a prompt
Key takeaways
- Context, task, shape, constraints, purpose, example — each closes one guess
- Pasting the real file and the real error is the biggest single quality lever
- Correct one thing at a time; start fresh only after three failures
- Better wording can't supply information the request doesn't contain
Try it yourself
Take your last vague request and rewrite it with all six parts. Run both. The difference in what you keep is the clearest demonstration of why the structure matters.