Ready and Done When an Agent Writes the Code

🧩 Concept

I've sat through enough Definition of Done discussions to know how they usually end: someone adds "and has high test coverage", everyone nods, and the document goes back into Confluence for another year. That used to be fine. The definition was a formality because the real quality control was the engineer who typed the code and understood every line of it.

That's not the situation anymore. When an agent writes most of the code, the ticket is the prompt and the DoD is the only thing standing between the output and production. Both documents suddenly matter a lot, and most of them weren't written to carry that weight.

Writing code got cheap. Saying what you want precisely, and checking what you got precisely, did not.

The DoR covers the first. The DoD covers the second. If either one is a list of adjectives, "clear enough", "properly tested", "meets our standards", it will fail quietly. An agent satisfies the letter of a vague rule faster than any person ever could, and it won't tell you it did.

🔹 1. Where the effort went

I don't want to oversell the industry numbers, because they're all self-reported. But they are remarkably consistent, so here they are:

Google — ~75% of new code is AI-generated; engineers approve every change
Stripe — 1,300+ agent-written PRs merged a week, CI retries capped at two; a person reviews every PR
Meta — low-risk diffs flow through a risk-scored pipeline, reverts at a third of the usual rate; risk tier decides how much attention a change gets
Uber — AI comments on 90% of ~65,000 weekly diffs, 75% rated useful; noisy comment types get switched off
Anthropic — AI review on every PR, substantive review comments went from 16% to 54%; humans still approve
Spotify — background agents must pass fixed checks before a PR even opens; they tried an "AI judge" as a gate and removed it as too rigid

Nobody in that table removed the human. Nobody let the model be the gate. Agents draft and review, deterministic checks block, people approve. That's the whole pattern, and it's less exciting than the headlines suggest.

The counter-evidence deserves equal time. The 2025 DORA survey, about five thousand people, found that AI amplifies whatever a team already is, and that delivery stability still correlates negatively with adoption. METR ran a randomized trial where experienced developers were about 19% slower with AI tools while believing they were 20% faster. Small sample, early-2025 tools, I know. But the perception gap is the part I keep coming back to. If engineers can't feel the slowdown, you need numbers from the system of record, not from a survey. And the gates need to exist before the volume arrives, not after the first incident.

🔹 2. Definition of Ready: the spec is the product now

Here's the thing that took me a while to accept. Every ambiguity in a ticket used to be resolved by a human who'd ask a question in standup. Now it gets resolved by a model, silently, in whatever way is easiest to implement. The ticket doesn't need to be "clear enough for an engineer to estimate". It needs to be clear enough that there's nothing left to guess.

So a ready ticket needs a few things it didn't need before.

Acceptance criteria that are actually agreed, not just listed. Product and engineering sit down, argue about the edge cases, and write down what they settled on. That conversation is the design talk, and it has to happen before any code exists, because afterwards the code will have already picked an answer.

A spec, in one place. I genuinely don't care whether it's the ticket description or a Markdown file next to the code. I do care that there's exactly one home, because the moment there are two, one of them rots and your "specs before code" metric starts measuring the disagreement instead of the practice.

Depth that matches the size of the change. A bug or a config flip gets a few lines of how. A feature that touches three services gets a design lock first, then a contract at the file level: which files, which methods, which tests, which pitfalls. Writing that takes twenty minutes and saves two review rounds. I've watched it happen enough times to stop arguing about it.

And one sentence about what to observe after release. The metric, the log line, the alert that proves it worked. Without that sentence, the DoD's "working in production" is a feeling, not a check.

What I'd remove: story points as a proxy for coding time. If your points measured how long the typing would take, they don't measure anything now. A 300-line change can be an afternoon. A 20-line change to a billing rule can be two days of spec, review and verification. Either re-base the points on spec-and-verify effort, or stop pointing stories, keep them small, and forecast at the feature level as a range. I lean towards the second, but I'd try it on one feature before deciding.

🔹 3. Definition of Done: replace adjectives with evidence

My rule for the DoD is simple. If a line can't be checked by looking at GitHub or the CI, it's an opinion, not a criterion.

"Reviewed by the team" becomes one required approval from a code owner, on the final commit, with stale reviews dismissed on push. The author never approves their own PR. A bot's approval doesn't count. All of that is branch protection settings; it costs an afternoon.

"High test coverage, total must not drop" becomes diff coverage on changed lines, say 80%. Total coverage is the metric everyone games without meaning to. It punishes you for deleting dead code and rewards you for tests that assert nothing. I've seen a team's coverage rise while their bug rate did too.

"Meets quality standards" becomes the list of required checks: security scan, quality gate, no open AI-review finding, architecture rules. If a standard isn't a check, it's a wish.

"Properly tested" becomes: verified on stage against the test plan, and every defect found there gets a regression test in the same PR. Not a follow-up ticket. The same PR.

"Documentation updated (optional)" stops being optional. The service's docs change in the PR that changed the behaviour. Docs updated later are docs updated never. I've never seen an exception.

"Live and working as intended" is verified against the observation you named in the DoR. Deployed is not working.

Two more things, and then I'll stop.

Separate Done from Released. Done is engineering's: merged through the gates, verified on stage, deployable. Released is product's go/no-go plus confirmation in production. When "done" depends on a release window or one person's signature, every sprint metric becomes a function of someone's calendar. I've seen a whole quarter's velocity chart explained by a product owner's holiday.

And add the one rule that makes the system learn: every production bug becomes a new test or check, and the bug ticket says which one. Your gate set should grow out of real failures, not out of whoever had the strongest opinion in the retro.

🔹 4. Architecture rules as code

An agent will happily pass every test while importing across a boundary you consider sacred, reaching around a module's public API, or adding a dependency cycle. A person reviewing a 400-line diff is not going to catch that reliably. I don't catch it reliably, and I look for it.

Rules written in prose, the kind that live in a CONTRIBUTING file or get pasted into the agent's context, are context. They aren't a gate. The agent reads them and then does whatever makes the tests green.

So encode the structural rules you already have. Layer and package boundaries with ArchUnit on the JVM, go-arch-lint or depguard in Go, dependency-cruiser in TypeScript. Forbidden imports: handler reaching into repository, one service reaching into another's internals. The domain invariants that are structural, like "no write to a versioned entity without a version check", as a Semgrep rule. And CODEOWNERS on test files, so that a deleted or skipped test is a separate, visible review item. More than one company's early background agents "fixed" red builds by commenting out the tests. Yours will too, if you let it.

Run the rules in warn mode for an iteration, look at what they catch, then make them required. Have each rule cite the decision it enforces, so the rule set and the architecture docs can't quietly diverge.

🔹 5. Guardrails for AI review

A few things I'd insist on if you turn on AI review for every PR.

Give engineers a thumbs-down, and actually cull the noisy finding types every month. A required check everyone scrolls past is theatre, and it takes about a quarter to get there.

Keep the LLM in the advisor seat. It produces findings for a human. The gate is "no confirmed finding left open", which is deterministic. Spotify tried a model as a pass/fail judge and pulled it because it blocked valid changes. I believe them.

Cap the fix loop. Two automated rounds, then a human looks. An agent chasing green has every incentive to take the shortcut.

And don't set targets on "share of code written by AI". It comes from a commit trailer anyone can switch off. Report it if you like. Don't manage to it.

⚙️ Recommendations

Levels of AI maturity, whatever scale you use, are earned by checks, not declared. Move up when the next level's gates work for you. Step back when they stop working. Nobody likes the second half of that sentence, which is why it matters.
Fix the repo settings before you buy anything. Required security scan, required code-owner approval on the final commit, AI review on every PR. An afternoon of work, more impact than any tool.
Decide where the spec lives before you measure "specs before code". Otherwise the number is an artifact.
Keep a tripwire. If median time-to-merge gets 20% worse for two months while the maturity score goes up, review the process, not the metric. Watch revert rate and failed deploys too; those are the ones the DORA data says are at risk.
Small slices. One spec, one small PR, merged often. Big changes were already hard to review. They're impossible for people who now have to review ten times as many.