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 offers a test: give the request to a colleague who has minimal context on the task and ask them to follow it. If they would be confused, Claude will be too. Asking them to follow it is the part that does the work. "Improve the page" is perfectly readable and impossible to follow. "Every lesson is readable at 375 pixels wide", which is the width of a small phone, is followable, and two people would later agree on whether it happened.

Evidence is what ends the work, and naming it up front is what stops "done" from meaning "the agent ran out of things to change". Put the test, the build or the screenshot comparison in the same message as the work, so finishing and checking are one instruction rather than two. Section 6 covers the harder half, which is deciding whether the check that then runs actually proved anything.

Constraints protect what already exists, and the most reliable form of one is a pointer rather than a description: name an existing file as the pattern to follow.

The boundary is the part most people leave out, and it is what stops a locally sensible idea from becoming an unapproved second feature. The same guide 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. What it does not need is the same request sent again with more adjectives, which is where this page started.

What to do

1. Write the four lines before any non-trivial task, paste them in as the request, and let the agent choose the implementation inside them. In full, for one real feature:

   textCopy

   Outcome:       /orders lists the signed-in user's orders, 50 per page,
                  newest first.
   Evidence:      pnpm build passes, then /orders renders correctly for an
                  empty account and for an account with 120 orders.
   Constraints:   reuse the loader in src/lib/orders.ts, and match the
                  markup pattern in src/app/invoices/page.tsx.
   Out of bounds: no login changes, no database changes, no new dependency.

2. Send the check with the work rather than in a follow-up message, and then look at what the check printed rather than at the sentence summarising it.

3. Read the final diff against the boundary you wrote, rather than against how confident the summary sounds. Reading a diff covers how to see one and what to look for.

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 finding out the whole of the first request: "list every file that touches the orders table and tell me which one owns the query. Change nothing."

A boundary also only works while you hold it. When the excluded thing turns out to be necessary, extend the boundary out loud, rather than letting it widen while nobody names it.