Agents Skip the Red Phase
The default behavior of most AI coding agents is to generate code and tests simultaneously. Left to their own devices, agents write tests that confirm what the code already does — not tests that define what the code should do. The result is a green test suite that exercises nothing and catches nothing. [1]
This matters more than it might seem. AI-generated code introduces 1.7x to 2.7x more defects than human-written code, and 70% of engineering leaders report that quality has already degraded as AI accelerates development. [2] Teams using AI assistants without quality guardrails report a 35–40% increase in bug density within six months. The speed is real. The reliability gap is also real.
Red-green TDD — write a failing test first, then implement until it passes — is the simplest guardrail that addresses both problems at once. And it turns out to be a natural fit for how coding agents work.
The Pattern: Red-Green-Refactor for Agents
Traditional TDD follows three steps: write a failing test (red), write the minimum code to make it pass (green), then clean up the implementation (refactor). With an AI coding agent, the same cycle applies but the roles shift. You write the specification as a test. The agent writes the implementation.
Simon Willison, creator of Datasette and one of the most experienced practitioners of agentic coding, describes red-green TDD as “a pleasingly succinct four-word prompt that unlocks substantial engineering discipline already baked into the models.” The prompt is simply: Use red/green TDD. [1]
The red phase is the critical part. When the agent writes a test first and confirms it fails, it proves two things: the test actually exercises new behavior (not something that already passes), and the test harness is wired up correctly. Without the red phase, agents routinely produce tests that pass vacuously — tests that look right but assert nothing meaningful.
Why Test-First Works Better with AI Than with Humans
Developers have debated test-first development for decades. Some teams swear by it, others find it slows them down. With AI agents, the calculus changes in three ways.
First, agents are fast but imprecise. An agent can generate hundreds of lines of code in seconds, but without constraints, the output drifts from intent. Tests written first act as behavioral constraints — they define the contract before the agent starts implementing. This is the core insight behind spec-driven development: the specification, not the code, is the artifact you maintain. [3]
Second, agents don’t resist writing tests. One of the persistent frictions of TDD with human developers is the discipline required to write the test before the implementation. Agents have no such resistance. When prompted to use red/green TDD, they follow the cycle naturally — write test, confirm failure, implement, confirm pass. The pattern plays to their strengths: generating code that matches a clear specification.
Third, tests prevent the most common agent failure mode. The biggest risk with coding agents is not that they write code that doesn’t compile — it’s that they write code that compiles and runs but doesn’t do what you intended. A failing test is the cheapest possible way to catch this. If the test passes before the agent writes any implementation, something is already wrong. [4]
The Anti-Pattern: Testing After
The opposite approach — letting the agent write code first, then generating tests — is common and dangerous. When an agent writes tests after implementation, the tests tend to mirror the implementation rather than the specification. They test that the code does what the code does, not what the code should do. This is tautological testing, and it catches approximately zero regressions.
Research backs this up. A 2026 arXiv study on AI coding agent regressions found that adding procedural TDD instructions (telling agents to “always run tests”) without targeted test context actually increased the regression rate from 6.08% to 9.94% — worse than no intervention at all. When agents were instead given structural knowledge about which tests were affected by their changes, the regression rate dropped to 1.82% — a 70% reduction. [5]
The lesson: procedural rules (“always write tests”) are less effective than structural context (“these are the tests affected by your change”). Red-green TDD provides both — the procedure (write test first, confirm it fails) and the context (the test defines exactly what should change).
Practical Setup
The simplest way to adopt red-green TDD with an agent is a four-word instruction in your project’s configuration file. For Claude Code, add to your CLAUDE.md:
## Testing
Use red/green TDD for all new features and bug fixes. Write the failing test first. Confirm it fails. Then implement.
Some practitioners go further. One developer built a custom Claude Code slash command that enforces the red-green cycle by validating test failure before allowing implementation to proceed. [6] The command runs the test suite after the agent writes a test, and only proceeds to implementation if at least one test is red.
For teams with existing test suites, the workflow looks like this:
Describe the behavior you want — in natural language or as a test stub
Ask the agent to write a failing test that captures that behavior
Run the test — confirm it’s red (this is the step most people skip)
Ask the agent to implement until the test is green
Review the diff — the test tells you exactly what changed and why
Step 3 is the one that matters most. If you skip it, you lose the entire value of the pattern. A test that was never red provides no confidence when it’s green.
Beyond the Prompt: Structural Approaches
The four-word prompt works well for individual features. For larger codebases, structural approaches offer more leverage. The TDAD (Test-Driven Agentic Development) framework takes this further by building a dependency graph between source code and tests. Before an agent commits a patch, the system identifies which tests are affected by the change and runs them. This targeted approach outperforms blanket “run all tests” instructions because agents get focused context instead of procedural rules. [5]
Spec-driven development extends the same principle upstream. Instead of writing a test first, you write a specification first — then the tests are generated from the spec, and the implementation is generated from the tests. The spec becomes the source of truth, the tests become the verification layer, and the code becomes the regenerable output. [3] This pairs naturally with the agentic coding workflow where you direct agents rather than writing code yourself.
What Changes and What Stays the Same
Red-green TDD is not new. Kent Beck described the pattern in 2003. What’s new is that AI coding agents make it dramatically more productive. The friction that kept many developers from adopting test-first development — the time cost of writing tests before implementation — largely disappears when an agent handles both sides of the cycle.
What stays the same is the core discipline: the test must fail before the implementation exists. That single constraint — confirming the red phase — is what separates useful agent-assisted code from plausible-looking code that silently drifts from your intent.
Four words. Substantial discipline. The models already know how to do it. You just have to ask.