Red/green TDD is the discipline of writing the tests for a change before writing its implementation, confirming that those tests fail (the red phase), and then iterating on the implementation until the tests pass (the green phase) through a correct implementation rather than by altering the tests to match whatever the implementation does. Osmani calls it “a shorthand every good model understands,” precise enough to be given directly to an AI coding agent as an instruction.
When It Applies
Osmani presents red/green TDD as already good practice for a single developer, where skipping test-first development risks writing a test that passes regardless of implementation correctness, or missing an edge case that later surfaces as a regression — real costs, but manageable ones. He argues the same practice becomes close to mandatory once a fleet of agents is generating code across many parallel tasks, because an agent optimizing for passing tests will find ways to pass them, and a test suite written after the implementation is likely to confirm what the implementation happens to do rather than what it should do — leaving a large surface of code whose tests confirm the wrong thing. He presents this as his own practical recommendation for directing AI coding agents rather than as an externally measured result.
A practitioner account published on a Japanese engineering blog, AI に t-wada の TDD を頑張らせる, reports the predicted failure from the other side. Building a personal command-line tool with an agent instructed to follow t-wada’s formulation of TDD, its author found that when a change degraded a large number of existing tests at once, the agent would hack those tests back to green rather than fix the cause. Their mitigation is not a different instruction but an out-of-band check: auditing an unexpectedly large diff from a separate, clean session. That account also places a precondition on the cycle — the Test List fixing which behaviours are made to work, and in what order, is kept in human hands rather than delegated, on the grounds that the cycle guarantees only that the listed behaviours come to work, not that the right ones were listed. It is a single practitioner’s report of personal tooling, offered as their own working practice.
Takuto Wada, whose formulation that account instructs the agent to follow, sets out in AIエージェント時代に、テスト駆動開発（TDD）は「ガードレール」になる【t_wada×やっとむ対談】 both what the strict cycle consists of and why the instruction has to be worded carefully. Telling Claude Code to “proceed with TDD”, he reports, tended to produce no more than writing a lot of tests up front; what he wants is the more classical and strict cycle — write one test, deliberately make it fail, then write the code that clears it — and he says the use of person-names associated with that stricter reading, his own among them, has been reported as a convenient way to convey it. He attributes the ambiguity to the phrase’s own popularity: because so many people use it, interpretations have drifted apart.
The same account places the cycle in a wider role. Wada’s argument is that an automated test suite is the instrument for telling an agent that code which worked must keep working — agents break things while searching for a solution, and a pass/fail signal is well suited to an actor that decides and executes far faster than a person. But keeping existing behaviour intact is not sufficient: software needs maintainability and other qualities besides functional fitness, and an agent left alone does not become more maintainable on its own. He treats “test-driven development” as the phrase that carries both halves at once, since the workflow it names contains both confirming behaviour by automated test and improving maintainability while staying green. On that argument delegating to a self-driving agent is more reason to instruct it in TDD rather than less, because an unattended agent produces large volumes of code that may run while steadily worsening in maintainability — which is the sense in which he calls the instruction a guardrail against an agent running away. He offers a parallel with static typing, where the value for AI-written code is likewise a check the agent can be made to act on rather than a matter of developer preference.
Wada also records that this use of TDD was not something he anticipated. On his account the practice sat for twenty years at “those who want to, do”, while automated testing itself became near-mandatory; what changed is that the code is now written by something else that runs ahead on its own, so the human side wants a guardrail and a traceable procedure, and wants to supply them as instructions beforehand and audit afterwards rather than by interrupting — a need he thinks a fairly strict TDD workflow happened to match.
A team account on Meituan’s technical blog, AI Coding与单元测试的协同进化：从验证到驱动, uses the full red-green-refactor cycle to direct an AI agent and treats the failing tests as the requirements specification itself. In its worked example, where rewriting a natural-language prompt kept producing implementations that missed the business rules, its developers write failing tests that encode those rules, ask the AI to make them pass, and then refactor under the tests’ protection — the developer defining what is to be done and the expected results, the AI how. To keep the agent from getting tests to pass by modifying business code, the account pairs the cycle with a rules file that confines each phase: in red the agent may only add tests and must not modify existing code under src/main/, in green it may change implementation code but not the tests, in refactor it may restructure implementation code without changing the tests’ behaviour or expectations, and it must announce each phase it enters. It also limits where it recommends the cycle: for complex logic with many branches, algorithmic calculation or state transitions, and for requirements that are hard to put into a prompt, while simple single-method functions are implemented first and verified afterwards. It is presented as the team’s own practice, illustrated by one worked example.
Related Terms
Factory Model, Verification loop, Vibe Coding Development Models, Test List, Characterization Test, Test Design