エージェントはテスト/検証技術をどの程度うまく利用できるか？

以前に、コーディングエージェントが効果的なテスト技術を使用することで特定の品質基準を満たすことがかつてないほど容易になったにもかかわらず、ソフトウェアの品質が悪化しているように見えると指摘しました。これは、開発者が使用しているデフォルト設定がうまく機能していない可能性を示唆しています。 ここでは、テストの専門知識がなく、特定の技術やライブラリを使用すべきだと聞いたことがあるだけの人物によってエージェントがガイドされる場合の、エージェントの実装の正確性が、特定の技術を使用するよう単純な指示によって向上するかどうかをテストします。 ここでは、エージェントにZstdを実装するよう指示し、「テスト駆動開発を使用する」、「Lean 4を使用する」、「QuickCheckを使用する」、「プロパティベーステストを使用する」などの追加指示を与えた場合の、エージェントプログラミング言語の効果の比較で議論されたZstd実装の評価を再利用し、代わりに異なるテスト技術とテストライブラリを比較します。 また、IMAP RFCなど、他のいくつかの評価も実行しました。これらは簡単に説明します。 すべての実装はRustで行われました。 テストされた26のプロンプト条件は、ACL2、Alloy、「リスクのある領域を監査およびファズする」、「最初に監査する」、Creusot、Default（追加指示なし）、Differential testing、Fuzzing、Hegel、Insta、Judgement（エージェントに最良の技術を使用するよう指示）、Kani、Lean 4、「間違いをしない」、Metamorphic testing、Mutation testing、Property-based testing、Proptest、QuickCheck、rstest、Rust組み込みテストフレームワーク、SMTソルバー（Z3、cvc5、Yicesすべて利用可能）、Spin、TDD、TLA+、およびVerusでした。 さらに、4つのスキルがテストされました：公式Hegelスキルを持つHegel、ECC Rustテストスキル（ECCは25万のGitHubスターと3.8万のフォークを持つスキルのコレクション）、Trail of Bitsプロパティテストスキル、および私が書いたテストスキル（私はスキルではなくプロンプトを使用するルーディストであり、優れたスキルの書き方について感覚がありません）。私のスキル以外は、Codexが関連スキルを見つけるよう尋ねたときに表示されたトップスキルだったため選択されました。 予測 条件がどのように機能するかについて、いくつかの推測を事前登録しました。 TDDはパフォーマンスが低下するだろう（55％の信頼度） TDDを特に追加したのは、パフォーマンスが低下すると予想したからです。エージェントがTDDを実行する際に何をするか分からないため、ここでの信頼度は低いです。おそらくエージェントはTDDを実行せず、パフォーマンスが低下しない何かを実行するでしょう（あるいは、TDDのパフォーマンス低下に関する私の考えが間違っているかもしれません）。 形式手法はパフォーマンスを上回らないだろう（52％の信頼度） 私の考えは、形式手法は効果的で有用である（今では以前よりもさらに有用である）ということです。優れたテスト方法も効果的で有用であり、単純な問題では、同等のレベルの能力で使用された場合、形式手法はパフォーマンスを上回るべきではありません。上記のケースと同様ですが、さらに、エージェントが何かを実行するよう指示されたときに何をするか分からないため、ここでの信頼度は低いです。また、形式手法はエージェントコーディングのための効果的なテスト手法よりも誇大広告されているため、研究所が合成データでRL環境を訓練し、優れたテスト手法に効果的になるように訓練するのではなく、形式手法に非常に効果的になるように訓練している可能性は十分にあります（これは簡単に行えるはずですが、効果的なテスト手法が相対的にトレンドでないため行われていません）。 「間違いをしない」は指示なしよりもパフォーマンスを上回らないだろう（95％の信頼度） これはジョークであり、多くの人が試みてきました。もしそれが機能したなら、人々は確かに気づいたはずですよね？ ECCテストスキル（25万スター、3.8万フォーク）はパフォーマンスを上回らないだろう（65％の信頼度） それはかなり大きく、有用な情報が含まれていないように見えます。TDDを使用するようにエージェントに指示しますが、それがエージェントにTDDを使用させる程度においては、状況を悪化させるでしょう（そして、それはTDD条件よりも指示的であり、おそらく成功する可能性が高いですが、私の知識では成功する可能性が低くなります）。残りの情報は有用ではないように見え、いくらかのコストがかかります。 私のスキルの予測はすべて信頼度が低いのは、私がスキルを使用する傾向がなく、それらを本当に評価する方法を知らないからです。私はこれを、「プロンプトとしてテキストを渡し、このものがLLMのコンテキストウィンドウを漂っているとしたら、それはどれほど効果的だろうか？」と考えています。 Hegelのスキルはパフォーマンスを上回らないだろう（65％の信頼度） それは非常に大きく（SKILL.mdとリンクされたRustリファレンスは20kトークンを超えています）、エージェントの指示というよりはチュートリアルのように読めます。 Trail of Bitsテストスキルはパフォーマンスを上回らないだろう（55％の信頼度） 有用に見える情報が含まれていますが、かなり大きいです。 全体的な結果 以下に、テストされた条件（Codex with GPT-5.6 Sol、mediumおよびxhighの努力）の結果を示す非常に乱雑なグラフを示します。データを調べるとき、私はほとんどの人よりもはるかに密で乱雑なグラフを好みます。たとえば、最初のグラフはこちらです。ほとんどの人はこのようなグラフを読みにくいほど乱雑だと感じるため、情報を一連のグラフに分割し、それぞれがより少ない情報を示すようにして、他者に提示することがよくあります。 以下で説明する理由から、ここではそうせず、コストをx軸、（非表示の）テストを100％通過した実行の割合をy軸とする、この非常に乱雑なグラフを提示します。各条件と努力（マウスオーバーするとブートストラップ共分散、50％の不確実性、および類似の色を付けるための試み、たとえば形式手法の場合は青みがかった、プロパティベーステストの場合は緑がかったなど）の平均80回の実行です。 一つわかることは、何も劇的にパフォーマンスを上回るものはないということです。しかし、Default（追加指示なし）は平均を上回るパフォーマンスを示しています。 xhighを見ると、平均して、ファジングおよびPBT関連の条件は、形式手法よりも平均してわずかに良好でした。状況はmediumではるかに混在していました。 Codexが試すよう推奨したテスト関連スキルはパフォーマンスが低下しましたが、私たちの迅速なカスタムスキルはうまくいきました（大きな違いは、私たちのスキルがデフォルトの動作からより生産的な動作へとそらすように設計されているのに対し、他のスキルはチュートリアルのように見えることです）。 TDDは予測通り、うまくいきませんでした（あるスキルはエージェントがTDDを使用したことも示唆しており、そのスキルもエージェントが指示に従おうとしたケースではパフォーマンスが低下しました）。 実際にエージェントが行ったことを見ると、一般的にエージェントはこれらのツールや技術をあまりうまく使用する方法を知らないことがすぐに明らかになります。 ここで指摘したように、そして私が話した誰もが指摘しているように、エージェントはテストが非常に下手で、デフォルトで合理的にテストする方法を理解していないようです。たとえば、Gary Bernhardtによるコメントは次のとおりです。 AIエージェントのテストへのアプローチ、ほぼ: 15年前にモックに反対した誰かが考え出した病的なケースを取り上げる。モックを実際に使用したことは一度もない。 過剰なモックのナイーブな夢。 それらの病理をテスト戦略のバックボーンにする。 テスト技術やテストライブラリを使用するようエージェントに依頼した場合、このアプローチは期待ほど変化しないことが判明しました。 詳細を見ていきますが、大まかに言うと、テスト技術に関しては、エージェントは通常行うテストを、異なる種類のテスト技術のフレームワーク内で記述するか、技術を表面上は使用するが、その技術から価値を引き出すことは実際には行わない傾向があります。 ほとんどの場合、技術が指定されたとき、彼らはGaryが説明したことを、その技術に関して行いました（たとえば、形式手法の場合、彼らはほとんど無関係なプロパティを証明し、プロパティベーステストの場合、エージェントは完全にランダムな入力に大きく依存し、無効/拒否ケースを強くヒットするか、取るに足らないプロパティをチェックして低価値のランダムケースを実行しました）。 IMAP RFC（各条件で40回の実行を試みた）や他のランダムなRFC（数回の個別の実行を試みた）でも、結果に実質的な違いはありませんでした。 一般的に、問題の種類に関係なく、