26種類のテスト指示はコーディングエージェントを安定して改善できず、テストを増やしても正解率は上がらない

エンジニアのDan Luu氏は、コーディングエージェントを対象とする一連のテスト実験を公開した。エージェントにRustでZstandardを実装させ、TDD、QuickCheck、Proptest、ファジング、差分テスト、ミューテーションテストのほか、Lean 4、Kani、TLA+、Verusなど、26種類の指示条件を個別に追加した。また、検証方法をまったく指定しないデフォルト群も設け、mediumとxhighの推論強度を比較した。主要な条件ごとに多数の反復実行を行い、単発の成功を手法の効果と取り違えないようにした。

結果が示すのは「形式手法は無効」ということではなく、エージェントが指定されたツールをたいてい効果的に使えないという点だ。QuickCheckを使った実行では、160回中63回が1つの性質しか検査していなかった。ファジングでは、多くの場合、完全にランダムなバイト列を入力し、同じ無効入力の拒否経路を繰り返し通っていた。構造を持つランダム入力を生成したのは160回中わずか10回だったが、その半数は実際にバグを発見した。このことは、ボトルネックがツール自体ではなく、テストデータの生成戦略に近いことを示している。LeanやVerusなどを使った場合も、エージェントは実装上のリスクと無関係な性質を証明することが多く、最終的には通常のRust単体テストに依存していた。

TDDを指定するとエージェントが作成するテストは約2倍になったが、正解率は向上しなかった。Rustの組み込みテストフレームワークを使うよう明示した場合にも、同様の傾向が見られた。典型的な失敗には、最も脆弱な挙動を見落とすこと、現在のプログラム出力から「正解」を逆算して作ること、回文の入力を選んだためにビット順序の反転バグが偶然テストを通過することなどがあった。デフォルト群の成績はむしろ平均を上回ったが、各群の差は厳密な順位付けを裏付けるには不十分だった。

エージェントのワークフローにとって、これは`もっとテストしてください`、`TDDを使ってください`と指示したり、チュートリアル型のskillを追加したりしても、テスト設計の代わりにはならないことを意味する。より信頼できる方法は、人間または独立した仕様があらかじめoracle、妥当な入力ジェネレーター、カバレッジ目標、フォールトインジェクションを定義し、その後でエージェントにテストケースを拡充させることだ。今回の研究対象は依然としてRust、圧縮形式、その他少数のタスクに限られており、査読論文でもない。次の段階では、複数のモデルや言語、リポジトリ規模のタスクを対象とし、事前登録された統計的比較を行う必要がある。