AIに実装を任せる前に、先に見るテストを一つ決める

AIに実装を頼むと、思っていたより早くコードが返ってきます。小さな関数なら、数分でそれらしい形になります。

その速さに助けられる一方で、受け取ったあとに困ることがあります。どの条件を満たしていれば十分なのか、どこからがAIの勝手な判断なのかが見えにくいまま、なんとなく動いた気分になります。

コードレビューや自分の確認で立ち止まるのは、実装そのものより、先に見るべきテストを決めていなかったときです。

この研究は、TDDの流れで人間だけ、人間と会話型LLMの協働、LLMによる全自動、agentic platformへの委任という複数の進め方を比べています。

論文が示しているのは、日常のAIコーディングで三行メモが効くという話ではありません。確認できるのは、agentic workflowが速く、機能正答率も高かった一方で、構造が複雑になり、テストで覆われない判断点が増えうるという範囲です。

そこから借りたい見方は、AIに任せる量を増やすほど、人間が握る場所を先に決めることです。全部を自分で書く必要はありません。ただ、最低ひとつのテスト観点は自分の手元に置いておきたいところです。

今日AIに小さな実装を頼む前に、テストの観点を一つだけ書きます。

形式は簡単で十分です。「入力」「期待する出力」「外したくない端」を一行ずつ置きます。テストコードにできるならそのまま書き、まだ難しければ自然言語の受け入れ条件で構いません。

例えば、文字列整形なら「短い文字」「幅ちょうど」「幅を超える文字」のように、AIが勝手に広げそうな場所を一つ選びます。実装を頼む文には、その確認を最初に通してほしいと添えます。

返ってきたコードを見るときは、まず先に決めたテスト観点から確認します。全部を完璧に読む前に、一番外したくない条件だけを見る順番です。

通っていれば、次にAIが追加した分岐や補助関数を見ます。必要な設計判断なのか、仕様にない親切なのかを分けます。不要なら削る前提で、AIにも「この分岐を支えるテストはあるか」と聞きます。

AIを使うほど、実装を速く出すことは楽になります。その分、人間は何を品質として受け取るのかを先に置く。今日の一つのテストが、未来の自分への小さな引き継ぎになります。