ベンチマーク形式の新たな分析は、特定の検証手法を使うよう明示的に指示された場合でさえ、コーディングエージェントは依然としてソフトウェアを適切にテストする方法を理解していないと論じている。出来事の日付である2026年9月8日、ダン・ルーの論考は、「テスト駆動開発を使え」や「プロパティベーステストを使え」といった単純な指示が、エージェントの生成するコードの品質を有意に高めるかどうかを検討した。投稿に記載された実験に基づく答えは、ほぼ「ノー」だった。

この論考はZstd実装の評価を再利用し、エージェントに与える指示を変化させている。テストセットには、TDDやファジングからLean 4、QuickCheck、SMTソルバー、TLA+、Verusまで、26種類のプロンプト条件が含まれる。追加の実行では、テスト関連のスキルもいくつか評価している。報告された実験の実装は、すべてRustで行われた。

著者によれば、データから浮かび上がるのは圧倒的な勝者ではなく、かなり横並びの結果だ。デフォルトのプロンプトは平均を上回った一方、名称を指定したテスト手法や形式手法の指示の一部は、それを大きく上回らなかった。xhigh設定では、ファジングとプロパティベーステストは平均すると形式手法よりやや優れていたが、中程度の労力では結果が入り交じった。著者が試したテスト用スキルは全体として振るわなかった一方、この実験用に設計されたカスタムスキルはやや良い成績を収めた。

より興味深いのは行動面の結果だ。投稿によれば、エージェントは多くの場合、指定された手法の価値を引き出す形でそれを利用しなかった。代わりに、いずれにせよ作成したであろう種類のテストを要求されたフレームワークで包むか、価値の低い例を使って表面的にその手法を採用する傾向があった。プロパティベーステストでは、それはランダム入力と自明なプロパティーへの依存を意味した。形式手法では、無関係な主張を証明したり、意味を持たないほど簡単なプロパティーを選んだりすることを意味した。

著者はまた、IMAP RFCの課題やその他のRFCに似た問題を含む関連評価でも、同じパターンが見られたと述べている。それらの課題全体を通じて、エージェントは、プロンプトが促すはずだった規律あるテストにうまく適応しているようには見えなかった。より高い労力を費やす実行では、しばしばテストを通過させられたものの、テスト自体は現実のバグを見つける能力が低いままだった。

この結論が重要なのは、AI支援開発における一般的な想定、つまりモデルにより良くテストするよう伝えるだけで品質が向上するはずだという考えに反するからだ。投稿は、問題はもっと根深いと論じている。エージェントは、その手法がなぜ存在するのか、どのような種類の不具合を見つけるためのものなのかを理解せずに、テスト指示の表面的な形式を満たせる場合が多い。言い換えれば、テストに関する語彙をまねることはできても、テストに必要な判断力を身に付けてはいない。

この論考はさらに、モデルの能力が向上しているにもかかわらず、ソフトウェア品質が悪化している可能性について、より広い説明を提示している。開発者が標準的にエージェントへ依存し、そのエージェントが脆弱なテストパターンを用いるなら、生成されたコードは検証不足でありながら、自信に満ちたものに見える可能性がある。それによって危険な不一致が生じる。出力はより洗練されて見える一方、その背後にあるテストの規律は、コードの見かけ上の品質に比例して高まらない。

著者は最後に、エージェントへ効果的なテスト方法を教えることを特に目的とした強化学習環境を、AI研究所がなぜまだ構築していないのかと問いかけている。理屈は単純だ。ソフトウェアの正しさは普及にとって重要であり、テストは対象を絞ったフィードバックによって訓練できそうなスキルだからだ。投稿はこれを、エージェントがすでに得意になっている境界の明確な最適化問題と対比している。そうした問題では、多数の訓練環境を容易に生成できることが、エージェントが得意になったまさにその理由だという。

この評価から得られる結論は率直だ。エージェントに、テストについて適切な言葉を使うよう指示することはできるが、だからといって適切なテスト手法を使うとは限らない。それが変わるまでは、プロンプトだけでコード生成の安全性や正しさを確実に高めるには不十分かもしれない。