Spec-driven development for people who don't write specs
Most engineering teams stopped writing specifications years ago, and for reasonable reasons. The forty-page requirements document was out of date before anyone finished reading it. Agile taught us to talk instead of write, and for teams of humans that mostly worked.
Then the team acquired a member who does exactly what it is told, at speed, with no shared context and no ability to walk over and ask a clarifying question. Working with AI tooling has made specification matter again, and the teams that notice this early are pulling ahead.
Why the assistant needs what your colleague didn't
A senior engineer picking up a vague story fills the gaps from years of context: how this codebase does things, what the product manager probably meant, which corner cases bit the team last quarter. An AI assistant has none of that unless you give it to them.
So vague stories produce plausible code that solves a slightly different problem. It compiles, it may even pass the tests you wrote, and it is wrong in ways that surface in review or, worse, in production. The time you saved on typing you spend on reading and redoing.
The fix is not a bigger prompt. It is a clearer story.
What a good enough spec looks like
Nobody is asking for the forty pages back. A specification good enough for AI-assisted work fits on a screen and answers four questions.
What is the observable outcome? Not "add caching" but "the dashboard loads in under a second for accounts with fewer than ten thousand rows, and the numbers match the uncached version."
What are the constraints? Which patterns in the codebase must this follow, which libraries are off limits, what must not change.
What are the edge cases you already know about? The empty list, the duplicate, the user with no permission, the timezone. Listing five of these takes two minutes and saves an hour.
How will we know it is done? Acceptance criteria written as things a person or a test could check. If you cannot write these, the story is not ready, for a human or a machine.
That is a spec. It is a paragraph and a short list.
Templates make it a habit
Teams that do this well do not rely on discipline. They put the four questions into the story template so that every story arrives with the slots to fill. The assistant's own instructions point at the template, so it knows where to look and what to ask for when something is missing.
The most effective version we have installed is a template plus a rule: the assistant must restate the outcome and the acceptance criteria in its own words before writing any code, and stop if it cannot. That one rule catches most ambiguity at the cheapest possible moment.
Traceability comes free
A pleasant side effect of specifying first is that every commit can point at the story that justified it, and every story can point at the acceptance criteria it met. When something breaks, you can walk from the failing behaviour back to the decision that caused it in minutes.
For teams that need to show a skeptical manager, or an auditor, why the AI-assisted work can be trusted, that trail is the answer. It is also what lets you delegate more to the tooling over time: work with a clear spec and a checkable definition of done is exactly the work an agent can take further on its own.
Start with the next story
You do not need a process change to try this. Take the next story on the board and rewrite it against the four questions. Give it to the assistant. Compare the result to the last three stories that went in vague.
Most teams do not need convincing after that. They need the template, and a week of practice.