AI already writes a real slice of your production code, and your team’s trust in it is falling at the same time. That gap is the churn you feel every sprint: a developer types a loose prompt, reads a plausible diff, merges it, and the bug shows up two weeks later. The problem was never the model. It was the input. This playbook treats AI codegen as an engineering-discipline problem: write the spec first, generate second, and check the output against a contract instead of a memory of a chat.
What happens by default: requirements live in the prompt box and then vanish, so nobody can diff intent. The agent guesses the edge cases, some guesses are wrong and silent, and review turns into archaeology where the reviewer reverse-engineers what was meant. A change means re-prompting from scratch, context is gone, and drift creeps in. Acceptance becomes a vibe, and “looks good” merges bugs.
What good engineering discipline does: intent becomes a versioned artifact you can review, diff, and reuse. Non-goals and constraints are written down, so the agent cannot wander. Review checks the code against the spec, not against a chat log. A change edits the spec and regenerates one affected slice, and “done” means the acceptance tests pass.
State the goal, the users, and what “done” means in testable terms, with no implementation talk. Then turn that spec into a technical plan with architecture, data model, and named trade-offs. A criterion-to-design map is the checkpoint here. If an acceptance criterion has no design that satisfies it, you caught the gap before a line of code was generated.
Break the plan into units small enough to read in one sitting, each mapped to at least one acceptance criterion. A task that touches ten files is a plan failure, not a task. Any task that maps to nothing is scope creep or a missing criterion, and both are worth a five-minute conversation before you generate.
The agent generates task by task, and each task is reviewed and tested before the next one starts. Because the spec and plan are versioned artifacts, a change is an edit plus a regenerate of one slice, not a blank re-prompt. That single mechanism is why teams report roughly an order of magnitude fewer regenerate-from-scratch cycles.
Take a single medium feature and push it through Specify, Plan, Tasks, and Implement using the templates inside. The goal is a ready spec and a criterion-to-design map produced without hand-holding, plus one feature that ships with tests tied to its acceptance criteria.
Before any task reaches an agent, it clears a written gate: the spec is ready, criteria are testable, inputs are named, constraints are in context, and a human owner is assigned. If a task fails the gate, do not prompt harder. Fix the spec or split the task.
Store specs and plans next to the code so they version with it, and connect acceptance criteria to your pipeline. Specs stop being chat logs. PRs reference the spec they satisfy, and review time on AI-generated changes starts to drop.
Roll the flow out across net-new work and measure regenerate-from-scratch cycles, rework rate, and PR review time. Baseline them for two weeks first. Without a baseline you cannot prove the win, and this is a win worth proving to the people who fund it.
Give a capable model a contract and it compounds your best engineers. Hand it a wish and it compounds the guesswork. Everyone on your team has model access now, so access is not the edge. The edge is the written contract the model has to satisfy and the checkpoint that fails loudly when it does not. Start with one feature and one gate this week, and let the spec, not the prompt, decide what ships.
No. Old-style docs described a system after it was built and rotted the moment code changed. A spec here is the input the agent builds from and the reviewer checks against, and it lives in the repo so it versions with the code. It is a contract that does work, not a document that gathers dust.
Net-new features with real acceptance criteria, and any work you hand to an AI agent. Those are the places where “almost right” costs the most and where a testable spec turns a plausible-looking diff into something you can actually verify.
VPs of Engineering, engineering managers, and staff engineers who own delivery on teams using AI coding tools, and who need a repeatable way to make AI-generated code reviewable and safe to ship.
The first draft arrives slower and the finished, mergeable change arrives faster. Prompt-and-pray feels fast because the first diff appears in seconds, but the cost shows up in review and in production. A spec front-loads the thinking so review becomes a checklist instead of an investigation.
No. Spec Kit is an open-source toolkit that makes the flow easier, but the value is the flow itself: specify, plan, tasks, implement, with a validation checkpoint at every seam. You can run the four templates by hand on day one and adopt tooling later.
