The situation
You ask for a dashboard. The agent chooses the users, the data, the layout and the definition of done. The first result is polished but wrong, so you add more instructions to the same vague request.
The idea in one paragraph
A useful request names the outcome, the evidence that will prove it, the constraints that shape it and the boundary it must not cross. It does not prescribe every keystroke. It gives the agent enough room to solve the job while keeping product decisions with you.
| Part | Question to answer | Short example |
|---|---|---|
| Outcome | What should exist afterward? | A readable orders page |
| Evidence | How will we know it works? | Build passes; empty and filled states render |
| Constraints | What must remain true? | Reuse the current content loader |
| Boundary | What is excluded? | No auth or database changes |
How it actually works
The outcome is a result, not an activity. "Improve the page" is activity-shaped; "make every lesson reachable on a 375px screen" can be checked. Constraints preserve facts such as the current stack, accessibility rules or files that must not change. The boundary prevents a locally sensible idea from becoming an unapproved second feature.
After a poor first result, inspect which part failed. If the outcome was ambiguous, rewrite it. If a constraint was missed twice, begin a clean session with the corrected brief. If the evidence was weak, add a check. More adjectives rarely repair a missing decision.
What this changes for you
- Write four lines before a non-trivial task: outcome, evidence, constraints and out of bounds.
- Let the agent choose implementation details inside that box.
- Compare the final diff and checks with the box, not with how confident the answer sounds.
Where it breaks
A brief can become a miniature specification that takes longer to maintain than the work. Small, reversible edits need less ceremony. The other failure is false precision: do not invent a metric or file list when discovery should determine it.
Terms used on this page
- Outcome: the observable result the work should leave behind.
- Evidence: the check or observation that would prove the outcome exists.
- Constraint: a condition the solution must preserve.
- Boundary: an explicit statement of what the current work does not include.
Read next
Markdown files are the memory explains where those decisions live after the conversation ends.