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

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