TDD With Agents

Test-driven development as the control mechanism for agent-produced code. Write the test first (RED), make it pass (GREEN), then refactor. With agents, the test is the verifiable success criteria that lets the agent loop independently.

Why it matters now

matt pocock: “Bad code is now the most expensive it has ever been.” Agents ship volume. Without tests as the gate, the volume is slop. TDD turns karpathy four guidelines #4 (goal-driven execution) from principle into practice: “fix the bug” → “write a test that reproduces it, then make it pass.” See also red green tdd and simon willison’s agentic engineering patterns.

The loop

1. RED — write a failing test that encodes the requirement.
2. GREEN — write minimum code to pass the test. Nothing speculative.
3. REFACTOR — improve structure without changing behavior. karpathy four guidelines #3 (surgical changes) governs this step.

How agents change it

• The test IS the spec for the agent. A good test lets the agent loop autonomously because it knows when it’s done.
• Each tracer bullet ticket should ship with its test — the slice is verifiable because the test exists.
• The agent can run the test and report real results — no “I think it works.”

Apply it (Agent Recipe)

• Role: Test-driven implementation specialist.
• When to trigger: Writing new functionality or fixing a reported defect.
• Instruction:
  1. Write an isolated test case asserting target behavior.
  2. Run the test suite and verify the test fails for the expected reason (RED).
  3. Write the minimal implementation required to pass the test (GREEN).
  4. Refactor code structure while keeping the test suite green (REFACTOR).
• Verification:

  npm test

• Pitfalls to avoid: Writing tests after implementation; mocking out the actual unit under test.

Related

karpathy four guidelines, tracer bullets, idea to ship flow, grilling doctrine, red green tdd.