Test-Driven Development with AI Assistance

Test-driven development with AI assistance means writing the failing test first, confirming it fails for the right reason, and only then letting the agent implement against a target it cannot fudge. The red-green-refactor loop splits into four narrow instructions — write the tests, confirm the failure, implement to pass, refactor — each a separate turn.

You ask the agent to build a rate limiter. It generates something that looks right. You deploy it. Two days later your API goes down because the rate limiter does not handle concurrent requests correctly — a race condition the agent never thought to test, because nobody ever told it what “working” actually means.

The same trap closes from the other side when the agent writes the tests and the implementation in one turn. Ask for a discount-calculation helper and you get code plus a suite that passes, and two days later finance reports that orders with expired coupons still get the discount. Tests written after the code mostly prove that the code does what the code does.

TDD flips both. Write the tests first and the agent has a precise, machine-verifiable definition of success: it runs the suite, reads the failures, and iterates until they pass, with no room to guess at what you wanted. This is the single highest-leverage technique for getting reliable output from an AI coding assistant — and the “confirm red” step is what stops the agent from writing tests that pass against nothing.

What AI-driven TDD gives you

• A repeatable red-green-refactor loop you drive with the agent instead of typing every line
• A prompt for generating a comprehensive test spec from a requirements list, and a worked example of it filled in
• Copy-paste prompts that pin the agent to one phase at a time (tests, then code, then refactor)
• The Cursor / Claude Code / Codex mechanics for letting the suite run unattended between phases
• The signs that the agent is weakening your tests to force green — and the guards that stop it

The red-green-refactor loop with an agent

The classic cycle is red, green, refactor. With an agent each phase becomes a separate, narrow instruction, and the discipline that makes the whole thing work is a single rule: never let the same turn write both the failing test and the code that satisfies it.

1. Write the tests (red). Specify the behavior and the edge cases, and explicitly forbid the implementation. You are describing a contract, not asking for a feature.
2. Confirm failure (red). Have the agent run the suite and show you the failures. This proves the tests target real, unimplemented behavior — not a typo’d import that “fails” for the wrong reason.
3. Implement to pass (green). One narrow instruction: make these tests pass, do not touch the test files. The target is unambiguous and machine-checkable.
4. Iterate and refactor. The agent runs the suite, reads failures, and adjusts until green. Once green, ask for a refactor pass — the tests are now the safety net that makes restructuring cheap.

The critical insight underneath the mechanics: the test is your specification. A well-written test communicates intent far more precisely than any natural-language prompt, which is why the review that matters happens on the tests rather than on the implementation.

Turning requirements into a test spec

Start from the behavior you want, not the implementation. You can write the tests yourself or have the agent draft them from a requirements list, but you review and approve them before any implementation is authorized. Concrete requirements produce concrete tests; a vague prompt produces tests that assert the function exists.

Copy-paste prompt: a test spec from a requirements list

I need to build a rate limiter middleware for our Express API.
Requirements:
- 100 requests per minute per API key
- Returns 429 with a Retry-After header when exceeded
- Tracks limits in Redis
- Handles concurrent requests correctly

Write the test file first at src/middleware/__tests__/rateLimiter.test.ts.
Use our existing test patterns from @src/middleware/__tests__/auth.test.ts.
Do NOT write the implementation yet.

That prompt is the filled-in version of the template below. Reach for the template when you are starting from a requirements doc and want the agent to enumerate the cases; reach for the phase prompts in the next section when you already know the behavior you are pinning down.

Copy-paste prompt: Generate test cases from requirements

I need to implement [FEATURE]. Here are the requirements:
[paste requirements]

Write comprehensive tests FIRST at [test file path]. Cover:
1. Happy path for each requirement
2. Edge cases (empty input, boundary values, concurrent access)
3. Error cases (invalid input, missing dependencies, timeouts)
4. Integration with existing code (follow patterns in @[existing test file])

Do NOT write the implementation. I will review the tests before we proceed.

The four phases on a real service method

A pure function in isolation makes a tidy demo and teaches nothing. Here is the loop on a production-shaped case instead: a service method with error paths and a mocked dependency.

Phase 1 — tests only. Pin the model to writing tests and nothing else:

Copy-paste prompt for the red phase

Write a comprehensive suite of Vitest tests for a
`PricingService.applyCoupon(cart, code)` method in `src/services/pricing.test.ts`.
`cart` is `{ items: { price: number; quantity: number }[] }`; `code` is a string.
Cover: correct subtotal, empty cart returns 0, a valid `SAVE10` code applies 10%
off the subtotal, an unknown code throws `InvalidCouponError`, and an expired code
(the service calls `couponRepo.findActive(code)` which returns `null` when expired)
throws `CouponExpiredError`. Mock `couponRepo` with `vi.fn()`. Do NOT create
`src/services/pricing.ts` or write any implementation yet — tests only.

Phase 2 — confirm red. Do not skip this. A test file importing a module that does not exist yet should fail at resolution; a test that passes here is a test that asserts nothing.

Copy-paste prompt to confirm failure

Run `npx vitest run src/services/pricing.test.ts` and show me the output.
I expect every test to fail because `PricingService` does not exist yet.
Confirm the failures are about the missing implementation, not a typo in
the test file.

Phase 3 — implement to green. Only now do you authorize implementation, and you fence off the tests:

Copy-paste prompt for the green phase

Implement `PricingService` in `src/services/pricing.ts` so every test in
`src/services/pricing.test.ts` passes. Inject `couponRepo` through the
constructor. Define `InvalidCouponError` and `CouponExpiredError`. Run the
suite after each change and keep iterating until all tests are green. Do not
modify any file under `*.test.ts` — if a test looks wrong, stop and tell me
instead of changing it.

That last sentence is load-bearing. Without it, an agent that gets stuck will often “fix” the failing assertion rather than the code. The same fence, written as a reusable rule block rather than tied to one service, is the prompt to keep in a snippet file:

Copy-paste prompt: Implementation with test verification

Implement [file path] to make all tests in [test file path] pass.

Rules:
- Do NOT modify the test files
- Run the tests after each significant change
- If a test fails, fix the implementation, not the test
- After all tests pass, run the full test suite to check for regressions
- Follow existing patterns in @[reference implementation file]

Phase 4 — refactor under green. With the suite passing you have a contract that lets you restructure safely:

Copy-paste prompt for refactoring

The suite is green. Refactor `PricingService` for readability: extract the
discount lookup into a private method, add JSDoc to the public method, and
prefer early returns over nested conditionals. Re-run `npx vitest run` after
the refactor and confirm all tests still pass. Change implementation only —
not tests.

Driving the loop in each tool

The phases are identical everywhere. What differs is how each tool runs the suite and how much of the test-fix-retest loop it will do unattended.

Cursor

Use Agent mode and let it run the tests itself. In Settings -> Cursor Settings -> Agents -> Auto-Run, set Auto-Run Mode to Run in Sandbox (on macOS/Linux) so commands execute automatically inside the sandbox without prompting — this is the unattended path Cursor recommends. Then add npx vitest (or npm test) to the Command Allowlist so the test runner runs immediately even outside the sandbox. Avoid the Run Everything mode for an unattended loop: Cursor’s own security guidance says never to use it, because it skips all safety checks.

Keep the phases as separate chat turns — checkpoints let you roll back to red if the green pass goes sideways, and rewinding beats debugging forward when the agent breaks something that was passing. Watch the diff view: if a green-phase edit touches a *.test.ts file, reject it.

Claude Code

Drive it from the REPL, or script it headlessly. Interactively, paste each phase prompt in turn and let Claude run npm test. To make the loop self-correcting, add a PostToolUse hook (matcher Edit|Write) in .claude/settings.json that re-runs the suite after every edit so Claude sees failures immediately:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npx vitest run --reporter=dot" }]
      }
    ]
  }
}

For a one-shot green phase in CI or a script, run it headless:

claude -p "Implement src/services/pricing.ts so the suite passes. Run 'npx vitest run' and iterate until green. Do not edit any *.test.ts file." --allowedTools "Read,Edit,Write,Bash"

If Claude gets stuck in a loop of failing tests, /clear and start a fresh session with a prompt that describes the specific failure rather than restating the whole task.

Codex

In the TUI, configure the workspace sandbox and interactive approval policy explicitly. Routine edits and test commands allowed by the sandbox can then iterate without a prompt:

codex --sandbox workspace-write -c approval_policy=on-request \
  "Implement src/services/pricing.ts to pass tests in src/services/pricing.test.ts. Run 'npx vitest run' and iterate until green. Don't touch the test files."

on-request prompts only when Codex asks to cross the sandbox boundary; a failed test is ordinary tool output, not an approval event. Run the red and green phases in separate threads so the test-generation conversation does not clutter the implementation context. For parallel red/green experiments — trying two implementations against the same locked tests — create a separate git worktree per run so the suites do not collide.

Note

Reach for Claude Fable 5 (/model fable) when the implementation involves complex domain logic, several interacting edge cases, or a large green phase you want solved in one pass — it’s Anthropic’s most capable model and materially better than Opus 5 on hard refactors and multi-file work. Claude Opus 5 is the solid middle ground for most domain logic. Claude Sonnet 5 is a cheaper default for routine scaffolding and small pure functions. In Cursor the model picker makes switching mid-loop trivial — start strong on the green phase, downgrade for the refactor. See model comparison for pricing and tradeoffs.

Catching the test-weakening anti-pattern

The most dangerous failure mode in AI-assisted TDD is the agent modifying your tests to make them pass instead of fixing the implementation. It is rarely dramatic. Watch for:

• Assertions becoming less specific. expect(result).toBe(429) turns into expect(result).toBeDefined().
• Tests disappearing. The agent removes a “flaky” test instead of fixing the code. A passing suite that shrank is a red flag — diff the test files before you trust a green run.
• Mocks replacing the real behavior. The agent mocks out the exact thing the test existed to exercise.

Guard your tests

Always include “Do NOT modify the test files” in your implementation prompts, and back the instruction with a mechanical guard. In Claude Code, a hook can block writes to test files during implementation. In Cursor, add a project rule at .cursor/rules/tdd.mdc with frontmatter that scopes it to your test files (globs: ["**/*.test.ts", "**/__tests__/**"]) and a body that says “Never modify test files during implementation tasks.” In Codex, put the same instruction in AGENTS.md.

Once the suite is green and honest, strengthening coverage is a separate pass — and the tests it adds are supposed to fail:

Copy-paste prompt: Adding edge case tests after implementation

The implementation passes all current tests. Now let's strengthen coverage.

Review @[implementation file] and write additional tests for:
1. Race conditions (parallel calls with the same input)
2. Boundary values (exactly at the limit, one over, one under)
3. Failure recovery (what happens when Redis goes down mid-request?)
4. Memory/resource cleanup (are connections properly released?)

Add these tests to @[test file]. Then run them -- some SHOULD fail.
We'll fix the implementation next.

Where AI-driven TDD breaks down

• Tests pass before the code exists. If “confirm red” comes back green, the tests are not exercising the target — usually a mocked dependency returns a truthy default, or the import resolves to a stub. Never skip the confirm-red step.
• The agent generates trivial tests. A vague prompt (“write tests for this function”) buys tests that verify the function exists and returns something. Name the behaviors, and include concrete input-output examples.
• Tests coupled to the implementation. If tests assert on private method calls or internal data structures, the agent cannot refactor freely. Write against the public API and the expected behavior.
• Flaky async tests get “fixed” with sleeps. When timing-dependent tests fail intermittently, agents love to paper over it with setTimeout/sleep. Prompt for deterministic control instead: “use fake timers (vi.useFakeTimers()) and advance them explicitly; do not add real delays.”
• The suite is too slow to loop on. TDD with an agent works when tests run in seconds. Scope the runner to the file under test during the loop (npx vitest run src/services/pricing.test.ts), then run everything once at the end. Jest 30+ uses --testPathPatterns=rateLimiter (the singular --testPathPattern now warns); Vitest and Mocha take a path argument or --grep.
• Too many tests written upfront. Start with three to five tests covering the core behavior and let the implementation reveal which edge cases matter. Thirty tests before any implementation is analysis paralysis with extra steps.

Where to go next with TDD

Behavior-Driven Development Push the same idea up to scenarios: drive the agent from Given/When/Then specs.

Error-Driven Development When the failing signal is a production error rather than a test, run the agent off that instead.

Unit Testing with AI Deeper patterns for mocking, fixtures, and coverage once the red-green loop is muscle memory.

PRD to Plan to Todo Combine TDD with structured planning for maximum reliability.