TDD for agents
Many agentic workflows converge on the same shape: write a Markdown file at the root of your repo, point your agent at it, and let it loop until it meets a stated goal. Test-driven development is a natural fit for that shape — the tests are the goal, and “all tests green” is an unambiguous exit condition the agent can check without you.
The basic loop
In this paradigm you ask the agent to write tests first. You review them (or have another agent review them), then ask the agent to implement the feature until every test passes. You revise the tests a little, the agent revises the code a little, and when everything is green you move to the next feature — with a fully testable one behind you.
The loop is four steps:
- Provide the prompt, spec, or task description.
- Provide the tests up front — written by hand, or generated by the agent.
- The agent writes code to pass those tests.
- Repeat 2 and 3 until the goals in step 1 are met and all tests are green.
What makes this work for agents specifically is that step 4 is machine-checkable. The agent does not have to guess whether it is done.
Similar but different TDD philosophies
The same philosophy can be implemented in several ways.
Policy-enforced TDD. TDD Governance for Multi-Agent Code Generation via Prompt Engineering pairs the user’s request with a policy for tests. The policy is derived from the early Beck and Martin TDD literature and encoded as a machine-readable manifesto — see tdd_principles_manifesto.json, which lists principles such as Eliminate Duplication, High Cohesion, Loose Coupling, and Test-First Gate. The agent must comply with the policy or the run is considered failed. The architecture separates model proposals from deterministic validation, enforcing phase ordering, bounded repair loops, and validation gates.
Spec-and-tests-driven generation. whenwords takes the design one step further: it is a relative-time-formatting library that contains no code. You hand a model a SPEC.md and a tests.yaml, and it produces an implementation in your language of choice that passes every case. The tests are language-agnostic input/output pairs written up front by a human or another agent. The same spec has been used to generate working implementations in Ruby, Python, Rust, Elixir, Swift, PHP, and Bash.
How to write TDD prompts
In this philosophy the way you phrase a task changes. Prompts become verifiable actions rather than open-ended intentions:
| Instead of… | Transform to… |
|---|---|
| “Add validation” | “Write tests for invalid inputs, then make them pass” |
| “Fix the bug” | “Write a test that reproduces it, then make it pass” |
| “Refactor X” | “Ensure tests pass before and after” |
As with any agentic development, the standard software engineering practices still apply. If you ask your agent to “write tests for all functionality and make sure they’re green,” it will probably fail. Break the intent into small, atomic pieces and build the feature up gradually.
This is the same “ask small” advice from the YC guide to vibe coding.