Skip to main content

Command Palette

Search for a command to run...

The AI Developer Definition of Done: What Ship-Ready Means When Agents Write Your Code

What ship-ready means when AI agents write your code, the TDD, self-review, CI repair, and governance checklist for AI-accelerated teams in 2026.

Updated
•11 min read•View as Markdown
The AI Developer Definition of Done: What Ship-Ready Means When Agents Write Your Code
D
PhD in Computational Linguistics. I build the operating systems for responsible AI. Founder of First AI Movers, helping companies move from "experimentation" to "governance and scale." Writing about the intersection of code, policy (EU AI Act), and automation.

When a human developer says done, it means they wrote the code, tested it, reviewed their own work, and believe it is ready for peer review. When an AI agent says done, it means the model finished generating output. These are not the same thing, and the gap between them is where bad merges, technical debt, and production incidents live.

In 2026, with AI agents now writing a fast-growing share of committed code and teams merging dozens of pull requests a day, the definition of done needs to be explicit, measurable, and enforced, not assumed. This article defines what ship-ready means for AI-generated code and gives you the AI code review checklist that separates teams who ship fast from teams who ship fast and then spend the next week fixing what they shipped. It answers a deceptively hard question: when is AI code ready to merge?


Why the Old Definition of Done Fails

The traditional Definition of Done was designed for human developers:

  • Code is written
  • Tests pass
  • Code review approved
  • Documentation updated
  • Deployed to staging

This assumed the developer understood every line they wrote. With AI agents, that assumption breaks:

  • The developer may not understand the generated code. Claude or Codex produced a large diff in seconds. The developer approves it because it looks reasonable and the tests pass. But they did not write it, so they cannot confidently say whether it handles edge cases, follows the project's conventions, or introduces subtle bugs.

  • Tests passing is necessary but not sufficient. An AI agent can write code that passes existing tests while introducing new untested behaviour. The tests verify what they test, they do not verify what they do not test.

  • Speed creates review pressure. When the agent produces a PR in minutes, the human feels pressure to review it just as fast. Fast production leads to fast (and shallow) review.

This is not hypothetical. In a METR randomized controlled trial, experienced developers took 19% longer to finish real tasks when they used AI tools, even though they believed the tools had made them faster (S2). The time did not disappear; it moved into reviewing, correcting, and understanding generated code. Making that work explicit is the whole job of AI coding agent governance.


The AI Developer Definition of Done (2026)

The Checklist

Every piece of AI-generated code is done when ALL of these are true:

1. Tests Written and Passing

  • New functionality has new tests (not just existing tests passing)
  • Edge cases are covered (empty inputs, null values, boundary conditions)
  • Tests are readable by a human (clear names, clear assertions)
  • Test count has not decreased

Why this matters: An AI agent can produce code that passes existing tests by coincidence. New tests prove the new code works as intended, not just that it does not break what existed before.

2. Self-Review Completed

  • The agent (or a second agent) has reviewed its own diff
  • The review identified at least one thing to improve (a review that finds nothing is suspicious)
  • Improvements were applied before human review

Why this matters: Self-review catches a large share of issues before a human ever sees the PR. It is the cheapest quality gate available.

How to do it:

# Claude Code: generate, then review.

> **TL;DR:** What ship-ready means when AI agents write your code, the TDD, self-review, CI repair, and governance checklist for AI-accelerated teams in 2026.

# First, implement:
claude   (prompt: implement the feature)
# Then, review the diff you just produced for security
# issues, missing error handling, untested edge cases, and
# CLAUDE.md convention violations:
claude   (prompt: review your own diff and fix what you find)

3. CI Green (Not Just Tests)

  • All CI checks pass (tests plus lint, type checks, and security scans)
  • If CI failed, the agent repaired it before requesting review
  • The CI repair did not introduce new issues

Why this matters: AI agents frequently produce code that passes tests but fails linting, type checking, or security scanning. A done PR has all checks green, not just the test suite.

CI repair loop:

Agent generates code → CI runs → CI fails on lint →
agent reads the CI output → agent fixes the lint → CI runs again →
CI passes → ready for review

4. No Regressions

  • Post-merge rework rate tracked (target: under 10% of PRs need follow-up fixes within 7 days)
  • No existing tests were deleted or weakened to make new code pass
  • No functionality was silently removed

Why this matters: The most dangerous AI coding pattern is passing by deletion, the agent removes a test or a feature to make its new code work. This must be caught before merge.

5. Human Comprehension Check

  • A human can explain what the code does in one sentence
  • A human reviewed the diff for architectural fit (not just correctness)
  • If the human cannot explain a section, they asked the agent to add a comment explaining WHY (not WHAT)

Why this matters: Code that nobody understands is technical debt from the moment it merges. The comprehension check is the counter to what Thoughtworks' Technology Radar calls cognitive debt (S1), the growing gap between how much code exists and how much any human actually understands.

6. AGENTS.md / CLAUDE.md Compliance

  • Code follows the conventions documented in AGENTS.md
  • No hardcoded secrets, PII, or credentials
  • Internal links point to existing pages
  • File naming follows the project's convention

Why this matters: The governance files are the agent's operating manual. Code that violates them was either generated without reading them (a configuration issue) or the agent ignored them (a prompt issue). Either way, it should not merge.

7. Risk Explanation

  • For any change that touches authentication, data access, external APIs, or deployment: the agent (or human) has written a one-sentence risk explanation in the PR description

Why this matters: A note that says only changed the auth middleware is a merge-anxiety generator. A note that says changed the auth middleware to add rate limiting, existing API consumers may start hitting rate-limit errors once they exceed the new ceiling is actionable.


The AI Self-Review Loop and TDD for AI Agents

The most effective pattern for AI-generated code quality is Test-Driven Development, not as a philosophy but as a practical loop that pairs test-first development with an AI self-review loop and an automated CI repair loop:

Agent writes tests for the feature (before the implementation)
   → tests fail, as expected (the feature does not exist yet)
   → agent writes the implementation
   → tests pass
   → agent self-reviews the diff and fixes what it finds
   → CI runs lint, type, and security checks
   → if CI is red, the agent reads the output, fixes, and re-runs
   → a human reviews the final PR

This loop produces higher-quality output than letting the agent write everything at once because:

  • Tests define expected behaviour before the agent has a chance to hallucinate it
  • Self-review catches issues the tests do not cover
  • CI repair is automated, not manual

Claude Code TDD Example

# 1. Write failing tests first
claude   (prompt: write failing tests for a user registration
#         endpoint, validate email format, reject duplicate
#         emails, hash passwords, and return the correct
#         success, validation-error, and duplicate responses)

# 2. Implement against the tests
claude   (prompt: implement the endpoint so every test passes,
#         following CLAUDE.md and the existing auth middleware)

# 3. Self-review before a human sees it
claude   (prompt: self-review for SQL-injection risk, password
#         hashing strength, safe error messages, and AGENTS.md
#         review-guideline compliance)

# 4. Run the full CI locally, then open the PR
run the tests, the linter, and the type checker; when everything
is green, the PR is ready for human review

Measuring Done Quality

Track these metrics to know if your Definition of Done is working:

Metric Good Bad How to Measure
Post-merge rework rate Under 10% of PRs need fixes within 7 days Over 25% Count follow-up commits to the same files within 7 days of merge
Self-review issue rate Self-review finds 1 to 3 issues per PR Finds 0 (suspicious) or 10 or more (too late) Log self-review findings
CI repair cycles 0 to 1 repairs per PR 3 or more Count CI runs per PR before green
Human review time 5 to 15 min per PR 30 or more min, or rubber-stamp (under 1 min) Track review duration
Comprehension coverage Every PR description explains the change PRs merged without descriptions Audit PR descriptions

The Anti-Patterns

The agent said it's done, so it's done

No. The agent completed generation. It did not verify correctness, architectural fit, or governance compliance. Generation is the first of seven steps.

Tests pass, ship it

Tests verify what they test. They do not verify what they do not test. New code needs new tests. Passing existing tests is necessary but not sufficient.

I'll review it later

Later never comes. If you cannot review it now, do not merge it now. The PR can wait. The production incident it causes cannot.

The self-review found nothing

A self-review that finds zero issues is either a perfect implementation (unlikely) or a shallow review (likely). Prompt for a deeper pass: Look specifically for edge cases in error handling and assumptions about input format.


Frequently Asked Questions

How long should a human review of AI-generated code take?

5 to 15 minutes for a typical feature PR. If it takes much longer, the PR is too large, ask the agent to split it. If it takes only seconds, the review is too shallow.

Should the reviewing agent be different from the writing agent?

Ideally, yes. A different agent (or the same agent with a reviewer prompt) catches things the writing agent's context window biased it to miss. This is why Codex auto-reviews and Claude Code self-review are valuable, they provide a second perspective.

Does TDD slow down AI-generated development?

In wall-clock time, writing the tests first adds a little generation time. In total cycle time, TDD is faster because it eliminates most post-merge rework. The modest upfront investment prevents a much larger rework cost later.

How do I enforce this in my team?

Add the checklist to your PR template. Add CI checks for test count (which must not decrease), linting, and type checking. Add a required reviewer. These are free governance controls that GitHub provides natively.


Further Reading

  • We Built the Engine But Not the Chassis: AI Team Velocity
  • Codex GitHub Connector: Automated PR Reviews
  • Shadow AI Agents: The Governance Gap
  • Solo Developer vs Enterprise: AI Agent Adoption Realities

Done Is a Standard, Not a Feeling

When an AI agent produces code, done is not when generation finishes. It is when tests are written and passing, self-review is completed, CI is green, a human can explain the change, and the risk is documented. That is seven steps, not one.

If your team needs help building the governance layer, Definition of Done, AGENTS.md, review automation, CI gates, start with an AI Readiness Assessment. The process maturity dimension directly evaluates whether your team's quality gates can handle AI-accelerated output.

For ongoing governance support, explore our Fractional CAIO retainer.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.