エージェント型コーディングに関するメモ：ガラパゴス諸島から

私は昨年11月からAIをかなりヘビーに使ってきましたが、全体として面白い経験です。 エージェントが何かを行うのですが、もし人間がそれをしたら、あなたはすぐにその人を解雇するでしょう。 私の反応はもちろん、これを素晴らしいことだと考え、何千ものエージェントを起動して、さらに多くのことをやらせることです。 昨年の半ば、GPT（おそらく5.0または5.1）にバグの原因を見つけさせようとしました。 当然ながら、このコードにはテストがなく、git bisectも機能しませんでした。そして、テストを書く資格すら私にはあまりないUIインタラクションのバグでした。 そのため、Codexに日付XとYの間でコミットを二分探索して、このバグを導入したコミットを見つけるように依頼しました。 Codexはすぐに、その日付範囲の後にあるはずのない、明らかに間違ったコミットを指摘しました。 Codexにそれが間違っていると伝えると、それは一度か二度、明らかに間違ったコミットを指摘しました。 それらが間違っていると伝えると、最終的に妥当に見えるコミットを犯人のコミットとして指摘しました。 その理論を証明または反証するように求めたところ、テストを書いて、その alleged commit が壊れたコミットであることを確認したと述べました。 次に、通常のブラウザテスト環境で、完全な開発者のエンドツーエンドスタックを持つビデオを作成するように依頼しました。 それは、それを行う権限がない（それは嘘でした）と主張しましたが、適切なテストコードとともにPlaywrightでコミットの前後の repro の実行ビデオを作成できると述べました。 そのビデオは説得力があり、コミット前に機能が正常に動作し、コミット後に機能しなくなったことを示していました。 このことの何かが正しくないと感じたので、手動でコミットの前後に問題を再現しようとしました。 そして、すべてが捏造であったことを発見しました。 ビデオは、Codexがバグを再現したかのように見せかけましたが、それは実際の環境ではなく、偽の repro を作成するように設計された人工的なブラウザ環境でした。 言ったように、これは非難されるべきことではなく、非常に素晴らしい経験だったので、私はすぐに「どうすればもっとこれを手に入れられるだろうか？」と考えました。 そして、昨年の半ばから後半にかけて、コーディングエージェントをヘビーに使うようになるまで、エージェントをますます多用し始めました。 この投稿は比較的ばらばらのトピックを扱っているので、簡単な概要を以下に示します。 テストの背景 テストに関する詳細 ケイブマンモード 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件未満の重大なユーザーが見えるバグを出荷しており、レビューは、誰かが特にトリッキーだと考えたものに、追加の目が必要な場合に必要に応じて行われていました。 AIコーディングワークフローでは、1人が人間または10人の人間が手でレビューできる以上のコードを簡単に生成できます。 人々は異なるバイアスを持っています。