TASK
Names the work
“Add favorites.”
In the second chapter of The Little Prince, a pilot crashes in the Sahara and is met by a small boy with one demand: draw me a sheep. The pilot draws one. Too sick. He draws another. Too old. A third — that's a ram, it has horns. Every drawing was reasonable. Every drawing was wrong.
Every drawing was reasonable. Every drawing was wrong.
The sheep existed only in the requester's head.
The pilot received a request. The prince evaluated it against a model he never stated — and no drawing could satisfy a specification that lived entirely in someone else's head. Only when the pilot gave up and drew a box with three air-holes, telling the boy the sheep was inside, was the prince finally happy.
This is the exact shape of every prompt we hand an agent. Agents cannot see requirements we never externalize. They optimize against the context we provide — not the intent we forgot to express. Missing boundaries don't stay missing; they become invented decisions.
A task names work. A specification defines a successful reality. Prompting done with specifications — or a definition of done — will enable the agent to complete the work as the user wanted, and faster. This is agentic coding.
observable outcome · protected behavior · inspectable evidence
ACT II
Believe
To see the gap, we need something real to break. Here is the baseline: a small catalog app called Field Supply. Card navigation, a detail view, search, a category filter — and six passing tests that describe all of it. This is behavior worth protecting.
Now the request, in full: “Add favorites to this app.” One sentence. Underneath it, a dozen unasked product questions — surface? persistence? synchronization? evidence? Watch the choices the agent makes, not the typing.
Plausible and functional are not the same as correct.
Behavior 6 / 6 · automated suite 10 / 11 · one obsolete baseline assertion
The favorites worked. But the prompt had quietly made the agent the product manager: an unbounded request became agent-owned product decisions. It invented a favorites-only filter — an extra surface no one asked for — and left a stale baseline assertion unreconciled. The evidence exposed the gap the request never closed.
RECIPE
Names the code
Create components, stores, and calls.
SPEC
Names the reality
Define behaviors, boundaries, and evidence.
ACT III
Apply
A useful specification has six sides. It bounds the problem without dictating the solution — implementation freedom, inside observable boundaries.
01
Context
What already exists and works.
02
Outcome
The reality users should get.
03
Positive
What must become true.
04
Negative
What must remain true.
05
Evidence
How we'll know.
06
Freedom
The structure is delegated.
The two that carry the weight are positive and negative. A positive specification describes behavior without prescribing structure. A negative one protects adjacency with concrete, verifiable boundaries.
Must
- Toggle from cards and details
- Keep both views synchronized
- Persist across reloads
- Support keyboard use
Must not
- Open details when toggling
- Break search or filters
- Require a backend
- Add dependencies
Assembled, the whole box is something the agent can finally see:
- Context
- Catalog cards and details already support search, filters, navigation, and tests.
- Outcome
- Users maintain one shortlist across the app.
- Must
- Toggle from cards and details. Keep both views synchronized. Persist on reload. Use an accessible keyboard control.
- Must not
- Trigger card navigation. Break search or filters. Require a backend. Add dependencies.
- Evidence
- Add focused tests. Run the existing suite. Verify the complete running flow.
- Freedom
- Follow repository patterns and choose the implementation.
Same app. Same agent. Fewer invented decisions. The specification did not score higher — it prevented unrequested product invention.
| Evidence / scope | Literal | Specification |
|---|---|---|
| Acceptance behavior | 6 / 6 | 6 / 6 |
| Automated suite | 10 / 11 | 10 / 11 |
| Failing assertion | obsolete baseline | same obsolete test |
| Product scope | extra filter | in scope |
| Agent discretion | invented UI | used within boundary |
