ソフトウェアファクトリーが失敗する理由（または：ハーネスエンジニアリングだけでは不十分）

ソフトウェアファクトリーが失敗する理由、または：ハーネスエンジニアリングだけでは不十分 注：私は人間/エージェントのコラボレーション分野でツールを構築する会社（HumanLayer）を経営しているので、以下に述べることは少し偏っているかもしれません。それにもかかわらず、このテーマが役に立つ、あるいは少なくとも私が興味を持っているのと同じくらい興味深いと思っていただければ幸いです。 - Dex 私たちはループを回しているのかもしれません 私たちは皆、AIコーディングを本番環境に投入するために競い合っています。ループエンジニアリングについては多くのことが語られており、一般的な考え方は、おそらくもっと多くのループを書くべきだということです。 StrongDMは、人間がコードを読まず、人間がコードを書かない、ライトオフ（lights-off）ソフトウェアファクトリーについて書いています。その物語は概ね以下のようになります。あなたはボトルネックです。モデルは十分に優れています。コードは無料です。もっと多くのものを出荷するだけです。OpenAIのRyan Lopopolo氏は2月にこれについて書き、4月にはOpenAIのソフトウェアファクトリー、Symphonyに関する講演を行いました。これらの人々は皆非常に賢く、私は彼らに多大な敬意を払っています。しかし、ここで最も皮肉な見方は、これをVCマネーをさらにスロップキャノン（slop cannon）に注ぎ込むための、もう一つの言い訳と呼ぶことでしょう。 それは...進んでいます。 私たちの友人MarioはAI Engineer Europeで、遅くするように懇願しました。なぜなら、コーディングエージェントのミスによって障害を起こすはずのない会社が、障害を起こしているからです。Matt Pocock氏が述べたように、コードベースはこれまで以上に速く崩壊しています。私はStrongDMから、あのダークファクトリー全体がどうなったのかについて、決定的なデータ/発見を掘り起こすことができませんでした。天気予報には、今年の2月から6月までの間に数件のまばらなアップデートがあります。Faros AIの人々はレポートを出しました。私たちが皆、今年の1月と2月にこれらのAIコーディングツールを使い始めて以来、プルリクエストレビューの質は大幅に低下しています。コメントが増え、コメントが長くなり、レビューなしでマージされるPRが大量に出ています。インシデントは大幅に増加しています。開発者あたりのバグ数も大幅に増加しています。このレポートは、検証可能な決定的な証拠というよりは相関信号であり、この投稿の全体的なポイントはスロップデータ（slop data）に注意することですが、私が見たものに基づいて方向性としては有効だと感じています。 「持ち方が間違っている」（間違っていない） 多くの人は、これがスキル不足だと言うでしょう。つまり、良い結果が得られないのはあなたのせいだと。しかし、あなたがどのように...えーと...持っているかに関わらず、トークン最大化（token-maxxing）がうまくいかないのはスキル不足だと言われていることは保証します。あなたはもっとトークンを使う必要があるだけです。コードを読むのをやめなさい。そして、もしあなたがちょうどそこに着いたばかりなら、それは進歩の一部だと約束します。私も去年の夏はそう思っていました。残念ながら私のエゴにとっては、私が「どうすればもっとうまく持てるか」について言ったくだらないことが記録され、今ではYouTubeで累計100万回再生されています。自慢したいわけではありません。私が長年コーディングエージェントを最大限に活用する方法について深く掘り下げてきたこと、そして多くの他の人々が実際に役立つと見つけたことを発見したことを示すためだけに共有しています。 高度なコンテキストエンジニアリング（Advanced Context Engineering） バイブス（Vibes）は許されない -- 複雑なコードベースにおける困難な問題の解決 RPIについて私たちが間違っていたことすべて とにかく、私たちが耐えなければならなかった、オンラインの「もっとトークンをハードに（just token harder）」というヤツの約束は、簡潔に言うとこうです。十分なハーネスエンジニアリングがあれば、両方の世界の最良の部分を得ることができます。10倍から100倍速く、高品質で、誰もが嫌いなコードレビューというものをやる必要がなくなります。私たちがしなければならないのは、リンターをもっと設定し、「敵対的レビュー（adversarial review）」のような魔法の言葉を十分なPRレビューボットに振りかけるだけで、私たちのソフトウェアは喜んでインシデントなしでビルドしてくれるでしょう。 これはスキル不足ではない 私が皆さんに納得させようとしているのは、どんな量のハーネスエンジニアリングやループ最大化（loopsmaxxing）も、根本的にモデルトレーニングの問題を解決することはできないということです。これに対処するために、コーディングモデルが実際にどのようにトレーニングされ、評価されているのかを掘り下げる必要がありました。RLHF（強化学習からの人間フィードバック）とベンチマークの両方に関してです。この投稿では、以下の点について説明します。 ソフトウェアファクトリーは1968年から存在しますが、どのように進化し、AIはそれをどう変えたのか モデルはベンチマーク（最新の「フロンティア」ベンチマークさえも）を楽々クリアするにもかかわらず、なぜ大量のスロップ（slop）を生成できるのか それにもかかわらず、コードベースを燃やすことなくかなり速く進むことができます 私は、毎日登場するスキルプラグインやAIサイコーシス・トークン最大化アドバイスのパンデミックの誇大広告を切り抜け、特定のスキルやフレームワークを参照せずに機能するものの種類について、一般的な言葉で話そうとします。 ビデオ版：この投稿は、AI Engineer World's Fair 2026での私の基調講演に基づいています（そしてそれを拡張しています）。この投稿へのフィードバックを提供してくれた@addyosmani、@CyrusNewDay、@HamelHusain、@zeeg、@dillon_mulroy、@nayshins、@jeffreyhuberに感謝します。 余談：これはバイブコーディングとは関係ありません。 Addy Osmaniは、強調する価値のあるこのことを解きほぐしました。数十人が実行するだけのサイドプロジェクトをバイブコーディングしている開発者と、10年間稼働しているエンタープライズシステムをさらに四半期生き延びさせるチームは、名前を挙げるに値する制約をほとんど共有していません。そして、流通しているアドバイスのほとんどは、実際にはそのうちの一方の人がもう一方にどう生きるべきかを伝えているのです。もしあなたがバイブコーディングを愛しているなら、どうぞ、バイブし続けてください。私は今でも多くのことをバイブコーディングしていますが、本番ソフトウェアもたくさん維持しています（そしてHumanLayerを通じて、他の何千人ものエンジニアが同じことをするのを助けています）。そのため、残りは複雑なコードベースで困難な問題を解決している人たちを対象としています。 私は、この分割を説明するために「ブラウンフィールド（brownfield）」という言葉をよく聞きます。歴史的にはそれは10年前のJavaの何かを意味していましたが、私たちが今出荷できるペースでは、エージェントが構築したコードベースは、おそらく3〜6ヶ月後に苦労し始めると感じます。速度が低下し、新しいものを追加する方法を変える必要があります。 ソフトウェアファクトリーの簡単な歴史 私はキャリア全体でソフトウェアファクトリーを構築し、研究してきましたが、最近知ったことです。この用語は、1968年のNATO会議にまで遡ります。これは「ソフトウェアエンジニアリング」が生まれたのと同じ会議です。それ以降、私が非常に興味深いと思うもう一つの点は、米国国防総省が、DoDがJenkinsをより良く使う必要があるかどうかについて、31ページのPDFを書いたことです。 2022年のソフトウェアファクトリー AIが登場する直前の2022年頃を中心に、「ソフトウェアファクトリー」の定義を整理しましょう。典型的なソフトウェアファクトリーでは： 人々が何を作るかを決定する -- エンジニア、PM、ビジョンを推進するリーダーシップ トラッカーに入る -- Linear、Jira、その他：何が起こる必要があるかのステートマシン 誰かがチケットをつかんでビルドする -- おそらく、その過程で手動/自動テストを行う プルリクエスト -- 自動チェック、誰かがコードをレビューする、誰かがそれをダウンロードしてテストする 何か問題があるか？「誰かがそれをビルドする」に戻る 本番環境にデプロイ -- そしてユーザーと接触する 監視を追加する -- 何かが壊れたときにエンジニアに午前3時にページングすることに特化した産業全体がある ユーザーが苦情を言う -- 要求をしたり、バグを見つけたり、機能リクエストを提出したりする → チームに戻ってトラッカーに追加する wsff-boxes-2x.mp4 そして、オン・アンド・オン。 私たちはまだAIに触れていませんが、この図にはすでにいくつかのループがあります。 アライメント（alignment）のフロントローディング チームが数十年前に気づいたこと：ビルドには数時間または数日かかり、レビューにも同様です。そのため、私たちは作業をフロントロードします。計画、アーキテクチャ提案、スプリント計画など、チームとして一緒に行います。これは意味します： 手戻りが少ない、なぜならコードを書く前に合意したから すべての行を読む時間が少ない。長くてよくできたPRを読んだことがあるなら、ほぼ完璧な場合のレビューがいかに速いかを知っているでしょう。 後でこれに戻ります。エージェンティックコーディングを導入した場合に何が起こるかを見てみましょう。 エージェンティックソフトウェアファクトリー 今や、すべての会社が、この1年近くを、自分たちがコードの75%を船積みするエージェントファクトリーをどのように構築したかを説明することに費やしています。エージェントファクトリーは、概ね「誰かがそれをビルドする」→「エージェントがそれをビルドする」と置き換えるものです。ここには、オーケストレーション、ハーネス、サンドボックス、モデル、コンピューティングなどのいくつかの要素があります。