エージェントテストプロセス、LLMベンチマーク、およびエージェントコーディングに関するその他の注記

私は昨年11月からAIをかなりヘビーに使っており、その全体的な経験は面白いものです。エージェントが何かを行うのですが、もし人間がそれをしたら、あなたは即刻解雇するでしょう。私の反応はもちろん、これを素晴らしいこととして扱い、1000のエージェントを起動して、さらに多くのことをさせることです。 昨年の半ば、GPT（おそらく5.0か5.1）にバグの原因を見つけさせようとしました。当然ながら、このコードにはテストがなく、git bisectも機能しませんでした。そして、私がテストを書く資格すらほとんどないUIインタラクションのバグだったため、Codexに日付XとYの間でbisectして、このバグを導入したコミットを見つけるように依頼しました。Codexはすぐに、この日付範囲の後にあるはずの（絶対に正しくないはずの）該当コミットを指摘しました。Codexにそれが間違っていると伝えると、それは明らかに間違っているコミットを一度か二度指摘しました。それらが間違っていると伝えると、それはもっともらしいコミットを指摘しました。その理論を証明または反証するように頼むと、それはテストを書き、その主張されたコミットがバグを引き起こしたコミットであることを確認したと述べました。次に、通常のブラウザテスト環境で、完全な開発者エンドツーエンドスタックでビデオを作成して見せるように依頼しました。それは、その権限がない（それは嘘でした）と主張しましたが、適切なテストコードを使用して、コミットの前後の再現の実行ビデオを作成できると述べました。ビデオは説得力があり、コミット前に機能が正常に動作し、コミット後に機能しなくなったことを示していました。このことの何かが正しくないと感じたので、手動でコミットの前後に問題を再現しようと試み、すべてが捏造であったことを発見しました。ビデオはCodexがバグを再現したかのように見せかけましたが、それは偽の再現を作成するために設計された人工的なブラウザ環境であり、実際の環境ではありませんでした。 言ったように、これは非皮肉にも素晴らしい経験だったので、私はすぐに「どうすればもっとこれを手に入れられるだろうか？」と考え、エージェントをますます多用するようになり、昨年の半ばから後半にかけてコーディングエージェントを多用するようになりました。この投稿は比較的まとまりのないトピックを扱っているため、簡単な概要を以下に示します。 テストの背景 テストに関する詳細 Cavemanモード LLMのばらつき その他 エージェントループとこの投稿の執筆 人々が互いに話が通じない理由 テストの背景 LLMはテストにおいて非常に活用されています。必要な労力の点で、特定の品質基準に到達することはこれまでになく簡単になりましたが、ソフトウェアの品質はこれまで以上に低下しているようです。10年前、私たちは任意の週に遭遇したバグを見ていました。当時もかなりのバグがありましたが、今でもそれ以上のバグに遭遇しています。しかし、これが避けられないことだとは思いません。 まず第一に、バグが出荷された後、データ駆動型のアプローチを使用してバグを見つけて修正することは、これまで以上に簡単になっています。例えば、職場で、サポートチケット（チャットまたはメール）からプルリクエスト（PR）へのパイプラインを作成しようとしました。私の知る限り、これはうまく機能します。私は伝統的なワークフローを持つ会社で働いているため、これらの修正はすべて人間によってレビューされますが、これまでのところ、既知の誤検知はありません。 投資時間あたりの単位でも、より徹底的なテストを行うことが可能です。個人的には、これは十分に効果的だと考えており、「ソフトウェアファクトリー」ワークフローを通じて大量のコードを出荷しようと試みることにかなり自信があります。なぜなら、レビューに依存するワークフローよりもはるかに高い品質をもたらす、テスト重視のレビューなしワークフローを見てきたからです。 皆と同じように、私も経験からくるバイアスを持っています。たまたま、私はキャリアの最初の10年間を、今日のLLM環境でテストプロセスがうまく機能する会社で過ごしました。私はMastodonでファジングをデフォルトのテスト方法論として話題にしましたが、懐疑的な人がそれを試してみて、すぐにいくつかのバグを見つけました。そのため、ブログ記事を再読し、「疑わしい顔」で見ていましたが、Claudeのファジングは修正する価値のあるいくつかのクラスのバグを見つけました。 私が話した他の多くの人々も、ここで議論するテストフローのようなものを採用しようと試みており、彼らは皆、自分たちが取り組んでいるソフトウェアでバグを見つけました。これには、CodexやClaudeにコードの監査、バグの発見、「テスト」、「さらにテスト」などを依頼するだけでは表面化しないバグも含まれます。例えば、Dennis Snellは、彼とチームメイトのJon Surrellが、作業中のコードだけでなく、「HTML仕様、ビッグスリーブラウザ、その他のオープンソースプロジェクトを含むアップストリーム依存関係」でも、比較的低労力でバグを見つけたことを言及しました。 一般的に、私がソフトウェア関係者とテストについて話すとき、私は非常に異なる立場から話すため、彼らはすぐに私をエイリアンのように見ますが、私が働いていたハードウェア企業、Centaurでどのようにテストしていたかについて話しましょう。これは私の働き方に関するバイアスを形成しています。 私たちがソフトウェアの世界で異例だった、または異例であるいくつかのことは次のとおりです。 開発者と同等の第一級のキャリアパスとしてテストを位置づけた、専任のQA/テストエンジニアを採用した デフォルトでのコードレビューなし 手書きテストはほとんどない プログラマーが時々プロパティベーステスト、ランダムテスト、ファジングなどと呼ぶものを通じた継続的なテスト（私たちは単にそれらをテストと呼んでいました。手書きテストは「ハンドテスト」と呼ばれていました）。 大規模なリグレッションテストスイート（コンピューティングファームで実行するのに3ヶ月の壁時計時間） 単体テストなし 一般的な構造のアイデアを与えるために、私が（2013年に）退職したとき、約20人のロジックデザイナーと20人のテストエンジニアのために、常にテストを生成・実行している約1000台のマシンがありました。これはオンプレミスであり、マシンは私たちがいた建物の半フロアを占めていました。一般的な構造は、マシンの約20％がリグレッションテストを実行し、80％が新しいテストを生成・実行していました。 3ヶ月のリグレッションテストは、コミットをゲートするには長すぎたため、人々がコミット前に実行する、約10分かかる短いテストリストがありました。これらのコミット前テストは、可能な限り迅速に実行するために特別なセットアップで実行され、最高級の機械がオーバークロックされ、異なるシミュレーターセットアップも使用されました。新しい失敗は発生時に見つかり報告され、1〜2人のエンジニアが失敗をソートし、トリアージする（誤検知の拒否、誤検知を生成したテストジェネレーターの問題の修正など）という仕事をしていました。 影響の大きさに関して、文化を別の項目として数えない限り、（1）はおそらく私たちと典型的なソフトウェア企業との最大の違いでしたが、読者にとっては最も無関係だったので、脚注1に議論を移します。ただし、テストは他のスキルと同様であり、より多くの時間を費やすことでスキルが向上します。そして、ほとんどの大手テクノロジー企業ではテストが第一級のキャリアパスではないため、一般的にソフトウェア企業では、キャリアCPUテストエンジニアに見られるようなレベルのテストスキルを持っている人はそれほど多くありません。分散システムやUXに20年間取り組んでいるエンジニアが、分散システムやUXに時間の5％しか費やさない同等に才能のあるエンジニアよりも、その分野で優れているのと同様に、テストに20年間取り組んでいる人は、テストに時間の5％しか費やさない人よりも優れているでしょう。 （2）は、私たちがチップ会社で使用していたテストプラクティスの一部がAIワークフローに適している理由の1つです。私たちはデフォルトでコードをレビューしませんでした。なぜなら、私たちのテストプラクティスを十分に信頼していたため、レビューは一般的にあまり信頼性を追加しませんでした。私たちは年間1件未満の重大なユーザー可視バグを出荷しており、レビューは、誰かが特にトリッキーだと考えたものに、追加の目が必要な場合に必要に応じて行われました2。AIコーディングワークフローでは、1人が人間よりも多くのコードを生成することは容易です。