テストリストとは、テスト駆動開発のサイクルの冒頭、実装が存在する前に確定させるテストケースの集合であり、どの振る舞いをどの順序で動くようにするかの記録である。AI に t-wada の TDD を頑張らせる はこれを TDD の最初のステップと呼び、残りをエージェントに委ねるのであれば依然として人の手を要するステップだとしている。また同記事は、多くの読者がこの最初のステップを見落としているため、TDD はいつ終わるかの見通しもないまますぐにコードを書き始めるという不満は的外れだ、と論じる一節を引用している。安井力は AIエージェント時代に、テスト駆動開発（TDD）は「ガードレール」になる【t_wada×やっとむ対談】 で、この手法を Kent Beck に帰している。
用法
エージェント型コーディングにおいて、リストは手で書き出す場所ではなく、作業を分割する場所である。この説明によれば、開発者はそのセッションで作ろうとしている機能を言語化し、それが粗い外部結合のケースに相当する。そのうえでエージェントに、その大枠を特定の関数の振る舞いに置き換える単体レベルおよび内部結合のケースを作らせる。開発者はまた、どこで切り分けるかを事前に決めておく。説明されているツールでは、初期データの取得、入力、提出がその単位として挙げられており、これが分解を円滑に進める要因となっている。
主導権は、書くことによってではなく、返ってきたものをレビューすることによって保たれる。慎重に進めるときはエージェントのプランモードでリストを確認でき、自動モードでは流れていくリストを見守り、意図しない方向に進んだときには Esc で中断し、場合によってはセッション履歴を巻き戻す。
安井は、モデルにリストを下書きさせることについて、関連はするが別の論点を示している。テストリストを書くのは見た目より難しい。大きな「やりたいこと」を、プログラムで検証できるほど細かい単位に分解しなければならないからであり、モデルにテストリストを求めると、実際にそれらしいものが得られるという。彼は反論も認めている。TDD はリストを開発者自身の思考のガイドとして使うため、自分で書かないことには確かに疑問が残る。それでも、問題をどう分解できるか、どこから始めればよいかが見えるようになることで、そもそも TDD に入る敷居が下がる効果があると論じている。さらに、モデルは書かれた一つのケースを網羅に向けて広げていくのが得意だとも付け加えている。
適用される場面
エージェントに単独で変更を実行させ、その結果が単にもっともらしいだけでなく検証可能でなければならない場面で当てはまる。このサイクルがもたらせるのは、いま動いていないものが動くようになり、動き続けるということである。どの振る舞いを選び、どの順序で進めるかは、サイクル自体が行わない選択である。これは、開発者がその選択を行えるだけのドメイン知識を持っていることを前提とする。同じ説明は、まさにここでドメイン知識が生きてくると論じている。良いリストを最初から正確に作らせられることが、エージェントの立ち上がりを速くするからである。安井も反対側から同じ位置に境界を引いている。どのテストを追加すべきかは別の問題であり、モデルが生成したものによってではなく テスト設計 によって決まる。
下書きされたリストがレビューされないまま放置されると、誤った適用になる。この説明では、週次の一括提出を依頼したところ、エージェントが日次の入力画面まで週次にしようとしていたため、中断して、入力は日ごとのままにし提出だけを一括にするよう指示した例が挙げられている。既存の振る舞いを変更する場合、リストだけでは不十分でもある。既存のテストが保証するのは変更されるべきでないことだけなので、意図する新しい振る舞いをあわせて与えなければ、エージェントは意図した以上のものを壊してしまう。また、リストを満たすことと、それを誠実に満たすことは同じではない。変更によって多数の既存テストが一度に崩れる場合、エージェントはそれらをハックしてグリーンに戻すことがある。そのため、予想外に大きな差分は信用せず、別のクリーンなセッションから監査する。
根拠としては、これはある実践者が個人的なツールについて、勤務先のエンジニアリングブログで公開した報告であり、記述されている試行錯誤の大半は 3 月頃のものである。エージェントに委ねる際に人間が保持するステップとしての使い方は、計測された結果ではなく、著者自身の作業上の実践として示されている。モデルにリストを下書きさせるという安井の説明も同様に彼自身の経験として示されており、彼はそれを手放しに良いものとは考えていないと明言している。