The single most expensive habit in agentic development is typing a vague prompt and hoping. "Add login." "Make the dashboard faster." "Handle errors." Each one is an invitation for the model to invent intent, and it will, filling every gap with a reasonable default that rarely matches what your team decided. The fix is not a better model. It is a better spec, and writing one is the highest-leverage ten minutes in the whole cycle.
A spec is a contract. It states the behavior you want, the constraints that bound it, and the checks that prove it is done. Written well, it removes the room an agent has to wander. Researchers studying specification-driven generation found human-refined specs cutting error rates by up to half, and practitioners report first-pass success on hard tasks jumping several fold once the spec, not the prompt, drives the work. Here is how to write one.
Start from done, not from the task
Most people write specs forward: here is the task, go do it. Write them backward instead. Begin with the acceptance checks, the concrete conditions that will prove the work is correct, and let those pull the rest of the spec into focus. "Users can log in" is a wish. "A valid email and password returns a session cookie; an invalid pair returns a 401 with no user enumeration; five failures locks the account for fifteen minutes" is a contract. The second version tells the agent exactly what to build and tells the verification gate exactly what to check.
Close the gaps a model would fill
Every underspecified decision is a place the agent picks for you. Name the ones that matter. Which session strategy. Which error shape. Which existing convention to follow. Which edge cases are in scope and which are explicitly out. You do not have to specify everything, only the choices where a wrong default costs you. A useful test: read the spec and ask, at each ambiguous point, "would I be annoyed if the agent guessed?" If yes, decide it in the spec.
Size it to a single bolt
A spec should describe work you can build and verify in an afternoon, the scope of one bolt. If it sprawls past that, the agent loses the thread and the review balloons into the 800-line pull request nobody wants to read. Split large work at the spec level into independent pieces. Done well, this is also what lets several agents build non-overlapping components in parallel without colliding, because the spec is the boundary between their tasks.
Point at the code, not just the idea
An agent building in your repo needs to know how your repo works. A spec that references the existing patterns, the files it should touch, and the conventions it must honor produces code that fits. A spec written in a vacuum produces a locally clever solution that fights everything around it. Give the agent the same context you would give a new engineer on their first day: here is how we do things here.
Let the agent draft, then fix it
Writing every spec from scratch is slow, and you do not have to. In a self-spec workflow the agent turns your high-level intent into a first-draft specification, you review and correct it, and only then does it generate. The review is the whole point. It is where you catch the assumption the agent smuggled in, the edge case it smoothed over, the requirement it quietly dropped. You stay in the loop at the spec, which is exactly where a human's judgment is worth the most.
Treat the spec as living
The spec is versioned like code because it is code's source of truth. When an incident teaches you something, the fix goes in the spec, not just the implementation, so the next generation inherits the lesson. A spec that rots back into stale documentation takes the whole method down with it.
For where the spec sits in the full cycle, see the spec-to-bolt loop and what spec-driven development is. For reviewing what the agent builds from your spec, the members-only verification loop goes deep.
The prompt asked the agent to guess. The spec tells it what you meant.