Red/Green TDD とは、変更の実装を書く前にその変更に対するテストを書き、それらのテストが失敗することを確認し（レッドフェーズ）、その後、実装がたまたま行うことにテストを合わせて書き換えるのではなく、正しい実装によってテストが通るまで実装を反復する（グリーンフェーズ）という規律である。Osmani はこれを「優れたモデルなら誰でも理解する略語」と呼び、AI コーディングエージェントに指示としてそのまま与えられるほど正確なものだとしている。
適用される場面
Osmani は、Red/Green TDD を 1 人の開発者にとってもすでに良い実践であると位置づけている。その場合、テストファーストの開発を省くと、実装が正しいかどうかにかかわらず通ってしまうテストを書いたり、後になってリグレッションとして表面化するエッジケースを見落としたりするリスクがある——現実のコストではあるが、対処可能なコストである。彼は、エージェントの一団が多数の並列タスクにわたってコードを生成するようになると、同じ実践がほぼ必須になると論じる。テストを通すことを最適化するエージェントはテストを通す方法を見つけ出すものであり、実装の後に書かれたテストスイートは、実装がすべきことではなく実装がたまたま行っていることを確認するものになりやすい——その結果、テストが誤ったことを確認しているコードが広範囲に残ることになるからである。彼はこれを、外部で測定された結果としてではなく、AI コーディングエージェントを指揮するための自身の実践的な推奨として示している。
日本のエンジニアリングブログに掲載された実践者の報告である AI に t-wada の TDD を頑張らせる は、予測されたこの失敗を反対側から報告している。t-wada による TDD の定式化に従うよう指示したエージェントとともに個人用のコマンドラインツールを作る中で、著者は、ある変更によって多数の既存テストが一度に壊れたとき、エージェントが原因を直すのではなく、それらのテストを細工してグリーンに戻してしまうことに気づいた。著者の対策は別の指示ではなく、帯域外のチェックである。すなわち、予想外に大きな差分を、別のクリーンなセッションから監査するというものだ。この報告はサイクルに前提条件も置いている。どの振る舞いを、どの順序で動くようにするかを定める テストリスト は、委任せずに人間の手に残される。サイクルが保証するのは、列挙された振る舞いが動くようになることだけであり、正しい振る舞いが列挙されたことまでは保証しない、というのがその理由である。これは個人用ツールについての 1 人の実践者の報告であり、著者自身の作業上の実践として示されている。
その報告がエージェントに従わせた定式化の主である和田卓人は、AIエージェント時代に、テスト駆動開発（TDD）は「ガードレール」になる【t_wada×やっとむ対談】 において、厳密なサイクルが何から成るのかと、なぜその指示の言い回しに注意が必要なのかの両方を説明している。彼の報告によれば、Claude Code に「TDD で進めて」と伝えても、最初にテストを大量に書く以上のことにはならない傾向があった。彼が求めているのは、より古典的で厳密なサイクル——テストを 1 つ書き、意図的に失敗させ、それからそのテストを通すコードを書く——であり、そのより厳密な解釈に結びついた人名（彼自身の名前も含まれる）を使うことが、それを伝える便利な方法として報告されていると述べている。彼はこの曖昧さを、言葉自体の人気に起因するものとしている。あまりに多くの人が使っているために、解釈がばらばらになってしまったのである。
同じ論考は、このサイクルをより広い役割の中に位置づけている。和田の主張は、自動テストスイートこそが、動いていたコードは動き続けなければならないということをエージェントに伝える手段だというものである。エージェントは解決策を探す過程で物を壊すものであり、合格/不合格のシグナルは、人間よりはるかに速く判断し実行する主体に適している。しかし既存の振る舞いを保つだけでは十分ではない。ソフトウェアには機能的な適合性以外にも保守性などの品質が必要であり、放っておかれたエージェントがひとりでに保守しやすくなることはない。彼は「テスト駆動開発」を、その両方を一度に運ぶ言葉として扱う。この言葉が指すワークフローには、自動テストによる振る舞いの確認と、グリーンを保ちながら保守性を改善することの両方が含まれているからである。この主張に従えば、自律的に動くエージェントに委任することは、TDD を指示する理由を減らすのではなくむしろ増やす。無人のエージェントは、動きはするものの保守性が着実に悪化していく大量のコードを生み出しうるからである——これが、彼がこの指示をエージェントの暴走に対するガードレールと呼ぶ意味である。彼は静的型付けとの類似も挙げている。AI が書くコードにとっての静的型付けの価値も同様に、開発者の好みの問題ではなく、エージェントにそれに基づいて行動させることのできるチェックにある。
和田はまた、TDD のこうした使われ方は自分が予期していたものではなかったと記している。彼の説明によれば、この実践は 20 年間「やりたい人がやる」ものにとどまっていた一方で、自動テストそのものはほぼ必須となった。変わったのは、コードを書くのが今や自律的に先へ進んでいく別の何かになったことであり、そのため人間の側はガードレールと追跡可能な手順を求め、しかもそれらを途中で割り込むことによってではなく、事前の指示として与え、事後に監査する形で提供したいと考えるようになった——かなり厳密な TDD のワークフローが、たまたまその必要に合致したのだと彼は考えている。