Outcome and boundary

Ask Claude Code for a dashboard and it will choose the users, the metrics, the layout and its own definition of finished. What comes back is polished and wrong in three places you never mentioned.

Adding adjectives and sending the same request again gets you a different wrong answer. Neither message ever said what the finished thing had to be, so the agent kept deciding that for you.

The idea

A request an agent can finish names four things: the outcome you want to exist afterwards, the evidence that will show it exists, the constraints the solution has to preserve, and the boundary it must not cross. It does not prescribe every keystroke. Those four keep the product decisions with you and leave the implementation decisions with the thing doing the implementing.

How it works

The outcome has to be a result rather than an activity. Anthropic's prompt engineering guidance gives a test for this: show the request to a colleague with no context on the task, and if they would be confused, the model will be too. "Improve the page" fails that test. "Every lesson is readable at 375 pixels wide" passes, because two people would later agree on whether it happened.

Evidence is what ends the work. Anthropic's Claude Code best-practices guide is blunt about the failure it prevents: the agent stops when the work looks done, and without a check it can run, "looks done" is the only signal available, which leaves you as the verification loop. Naming the test, the build or the screenshot comparison inside the same request moves that loop into the session.

Constraints protect what already exists, and the most reliable form of one is a pointer. The same guide recommends naming an existing file as the pattern to follow instead of describing the pattern in prose.

The boundary is the part most people leave out, and it is what stops a locally sensible idea from becoming an unapproved second feature. Anthropic describes the most useful specifications as self-contained: they name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step.

After a poor first result, work out which of the four was missing. An ambiguous outcome needs rewriting. A missed constraint needs stating once, plainly. Weak evidence needs a check added. Once you have corrected the same issue more than twice, the session is carrying your failed attempts as well as the job, and the same guide says a clean session with a better prompt generally beats a long one full of corrections.

What to do

1. Write four short lines before any non-trivial task: outcome, evidence, constraints, out of bounds. Then let the agent choose the implementation inside that box.
2. Put the check in the same message as the work. "Run pnpm build, then open /orders at 375 pixels wide and confirm the empty state renders."
3. Read the final diff against the boundary you wrote, rather than against how confident the summary sounds.

Where it breaks

Four lines is not a fee on every request. A typo, a log line or a rename is smaller than its own brief, and Anthropic's guidance notes that a deliberately open request is useful while you are exploring and can afford to course-correct. Match the ceremony to how expensive a wrong answer would be.

False precision is the opposite failure. Inventing a file list, a metric or an interface before you have looked hands the agent your guess as a constraint, and it will loyally build around it. When you do not know yet, say so and make discovery the outcome of a first, separate pass.

A boundary also only works while you hold it. If the excluded thing turns out to be necessary, that is a new decision to make deliberately rather than something to let drift into the current diff.