Most teams have an unspoken rule: the work is done when it runs. AI pairs make code that runs almost immediately, which compresses the visible part of the job and leaves the invisible part — the part where the engineer convinces themselves the code is correct — under-staffed. The workflow below is what the invisible part looks like when you give it a name and a place in your day.
Why this matters
The cost of a workflow is paid in the seconds you stare at the screen before typing. The cost of skipping the workflow is paid in the hours you spend three weeks later, trying to remember why a piece of code exists. AI pairs make the first cost more visible because they can produce a runnable answer in twelve seconds. They make the second cost less visible because the answer looks plausible even when nobody understood it. A workflow that names each stage closes the gap between what is shipped and what is understood.
Why a workflow at all? Doesn't AI mean you can just iterate?
Fast iteration is a virtue when the cost of a wrong answer is small. It is a trap when the cost is paid by a future maintainer who is not you, or by an on-call engineer at 2 a.m. who has to root-cause a regression you did not write tests for. The workflow below is built on a single observation from our regression data: engineers who name the stages of their work ship code with measurably lower defect rates than engineers who do not, even when both are using the same model. The naming matters because it forces a moment of explicit handoff between "I am exploring" and "I am committing."
The diagram above is the platform's scoring pipeline. The workflow we recommend for production work is structurally the same, with one extra stage in front: Spec. That stage is what most teams skip when they say they are vibing.
The six stages, in order, are: Spec, Spike, Defend, Test, Review, Ship. Each has an exit gate. You do not advance until the gate is open.
What goes in the "spike" stage that doesn't usually exist?
The Spike stage is where you let the model be sloppy on purpose. You ask for the worst possible first draft and you accept it. You run it. You watch it fail. You note where it failed and you throw it away. The point is not to keep the code. The point is to surface the assumptions that were not in your spec — the libraries you forgot to constrain, the edge case you did not think about, the data shape the model invented because you did not specify one.
Most engineers do the Spike accidentally and then mistake the output for a draft. The workflow makes it deliberate. The spike is not a draft. It is reconnaissance. The exit gate is: you can name three things you learned that were not in the Spec, and you can write them into the Spec before you start over.
Test and Review are the heaviest stages by time. Spec is the lightest. This is the inverse of how most engineers feel about the work — they think the spec is heavy because they are not used to writing one. In practice it takes nine minutes if you have the habit.
How does the "defend" step work in solo work, not just interviews?
The Defend stage is where you write down, in plain prose, why the code does what it does. Not what — the code already says what. The why. Three sentences per non-obvious decision. You write them in the PR description, in a comment, or in a private notes file that lives next to the code. The exit gate is: you could hand the PR to a reviewer who does not know the system, and they could ask one question and you could answer it without checking the chat history.
Engineers who only encounter the Defend step in interviews treat it as a presentation skill. That is the wrong framing. In solo work it is a debugging tool. The act of writing the reasoning down catches errors that the model did not catch, because the errors live in the gap between what you specified and what you accepted. We see this in our data: about a third of all bugs that survive the Spike stage are caught during the Defend stage, before any test is written.
| Stage | What to do | What to skip | Exit gate |
|---|---|---|---|
| 1. Spec | Write the problem, the success criterion, and the rough shape of the answer. | Pseudocode, file names, function signatures. | You can describe the change in three sentences without using a code-like word. |
| 2. Spike | Generate the worst first draft. Run it. Note what was wrong. | Polishing, refactoring, naming. | Three named assumptions you can write back into the Spec. |
| 3. Defend | Write the reasoning behind each non-obvious decision, in prose. | Documentation comments, type annotations. | A reviewer could ask one question and you could answer without history. |
| 4. Test | Write tests for the assumptions you wrote in the Spec and the cases you found in the Spike. | Coverage targets, mocking ceremonies. | The Spec assumptions are each enforced by at least one failing-then-passing test. |
| 5. Review | Self-review the diff against the Spec. Read the diff backwards. | Re-running the model. Reading the chat again. | Every line in the diff appears in the Spec or the Defend notes. |
| 6. Ship | Merge with a clean PR description. Add the rollback plan. | Long retrospectives. The next ticket. | Someone else can revert this without paging you. |
Where do most engineers cut corners — and what does it cost?
The two most-cut corners are the Spec and the Review. The Spec is cut because engineers feel they already know the problem; the Review is cut because the PR looks right and the tests are green. In our regression-rate data the cost of cutting the Spec is roughly 1.8x the regression rate; the cost of cutting the Review is roughly 1.5x. Cutting both — which is what most "vibe coding" looks like in practice — multiplies, not adds. The regression rate on no-Spec, no-Review code is about 2.4x the workflow baseline.
The Spec costs nine minutes. The Review costs eighteen. Twenty-seven minutes of work avoids, on average, two hours of follow-up across the lifecycle of the change. The workflow is not slow. It is the absence of the workflow that is slow, because the cost is moved into a future you cannot see.
The bug taxonomy that explains why each stage exists.
From Codritium Research
Where the AI Pair Fails
A taxonomy of the 1,876 bugs AI-assisted engineers shipped during our 2026 benchmark. Twelve bug classes, ranked, with the code patterns each one travels on.
Common questions
Is this slower?
About 20% slower in elapsed time on the first task. By the third task the cadence is faster than ad-hoc, because the Spec and Defend stages compound — you stop re-deriving the same assumptions every time.
Do I need to write a spec for a 30-line fix?
A three-sentence spec, yes. A formal document, no. The Spec stage is not paperwork — it is the act of stating what you are about to change, in prose, before you change it. Even a one-line bug fix benefits from a one-sentence spec.
What about hotfixes?
Skip the workflow for true hotfixes. Define 'true' narrowly: a production incident is open, the rollback is harder than the fix, and a senior is on the call. Everything else benefits from the workflow.
How does this fit a Scrum sprint?
Each stage is a sub-task on the ticket. Most teams find the Spec and Defend stages cleanly map to the 'definition of done' criteria they already have on paper but never enforce. The workflow makes them enforceable.
Do I have to use AI at every stage?
No. The workflow assumes AI is used in the Spike stage and optional in the others. Some engineers use AI only for the Spike and Test stages and write the rest by hand. Our data shows no meaningful score difference between full-AI and partial-AI workflows when the stages are honoured.
Where to go next
- See the bug taxonomy: Where AI pair programming fails
- Read the rubric that grades workflow adherence: The Defensibility Rubric, 2026
- Practice the workflow on a Codritium challenge in the challenge catalog