または：ハーネスだけでは不十分
更新 - この記事のトーク版は YouTube で公開中です：https://www.youtube.com/watch?v=Ib5GBkD555M
どうやらループをやるらしい
私たちは皆、AI コーディングを本番環境に投入する競争をしています。ループエンジニアリングについては多くのことが語られており、現在の一般的な見解では、もっと多くのループを書くべきだと言われています。
StrongDM は無人ソフトウェアファクトリーについて 書いています。そこでは、人間はコードを読まず、人間はコードを書きません。
そのストーリーはだいたいこんな感じです：
- あなたがボトルネックになっている。
- モデルは十分に優れている。
- コードは無料だ。
- とにかくもっと出荷しよう。
OpenAI の Ryan Lopopolo 氏は、2月にこれについて 書き、4月には OpenAI のソフトウェアファクトリー、Symphony についてトークを 行いました。
これらの人々は皆非常に賢く、私は彼らを大いに尊敬しています。しかし、ここで最も皮肉な見方をすれば、これは単に VC 資金をゴミ生産機にさらに注ぎ込むための別の言い訳に過ぎません。
まあ、動いてはいるんだが...
私たちの友人 Mario は AI Engineer Europe で立ち上がり、私たちに減速するよう懇願しました。なぜなら、コーディングエージェントの事故でダウンタイムが発生するはずのない企業が、実際に コーディングエージェントの事故によるダウンタイムを経験している からです。
Matt Pocock 氏が言うように、コードベースはかつてないほど急速に崩壊している のです。
StrongDM のあのダークファクトリー全体がどうなったかについて、確固たるデータや調査結果を見つけることはできませんでした。 天気予報 には、今年の2月から6月の間に数件のまばらな更新があります。 編集 - 7月23日にハッカーニュースでチームとの会話がありました - どうやら近いうちにもっと正式なアップデートがあるかもしれません！
Faros AI の人々 はレポートを発表しました：私たち2 が1月と2月にこれらの AI コーディングツールを全て使い始めて以来、プルリクエストのレビュー品質は大幅に低下しています。
- コメントが増え、コメントが長くなり、レビューなしでマージされる PR が大量に発生。
- インシデントが大幅に増加。
- 開発者あたりのバグ数が大幅に増加。
このレポートは、検証可能な決定的証拠というよりも、相関を示すシグナルです（そう、この言葉は意図的に選びました。Claude の散文について語り始めると止まらないので）。この記事の目的は、質の低いデータに警戒することですが、私が見てきたものに基づくと、方向性としては妥当に 感じられます。
「あなたの使い方が悪いんです」（違います）
多くの人が、これはスキルの問題だと言うでしょう。良い結果が出ていないのは、あなたのせいだと。
しかし、どのように...まあ...使っているにせよ、私は保証します。トークンを最大化する方法があなたに合わないなら、それはスキルの問題だと言われているはずです。もっとトークンを使う必要があるだけだ、と。コードを読むのをやめなさい、と。そして、もしあなたがそこにたどり着いたばかりなら、それは進歩の一部だと約束します。私も去年の夏はそう思っていました。
残念なことに、私のエゴにとっては、「より良い使い方」について私が話した愚かなことが記録され、現在 YouTube で合計約100万回再生されています。自慢したいわけではなく、私はコーディングエージェントの最善の使い方について 長い間 深く研究してきて、多くの人が 本当に役立つ と感じたいくつかのことを発見したことを示すためにこれを共有しています。
とにかく、私たちが我慢させられてきたこのオンライン上の「もっとトークンを使え」という話の 約束 は、簡潔に言えば次の通りです：十分なハーネスエンジニアリングがあれば、両方の良いところを手に入れられる：
- 10倍から100倍速く、
- 高品質で、
- 誰も私たち全員が嫌うコードレビューをする必要がなくなる
必要なのは、より多くのリンターを設定し、「敵対的レビュー」のような魔法の言葉を十分な数の PR レビューボットに振りかけることで、私たちのソフトウェアは喜んでインシデントなく自己構築するでしょう。
これはスキルの問題ではない
私が皆さんに納得していただきたいのは、どんな量のハーネスエンジニアリングやループ最大化でも、根本的にはモデルトレーニングの問題であるものを解決できないということです。
これに対処するために、私はコーディングモデルが実際にどのようにトレーニングされ、評価されるのかを、RLVR とベンチマークの両方の側面から掘り下げる必要がありました。
この記事では、次のことを説明します：
- ソフトウェアファクトリーは1968年に遡るが、どのように進化し、AI はそれをどう変えたか
- モデルがベンチマーク（新しい「フロンティア」ベンチマークですら）で優秀な成績を収めているのに、なぜ膨大な量の質の低いコードを生成できるのか
- それにもかかわらず、コードベースを燃やさずにかなり速く進める方法
私は、毎日登場するスキルプラグインや AI 精神症トークン最大化アドバイスのパンデミックの誇大広告を打ち破り、特定のスキルやフレームワークに言及せずに、機能する種類のもの について一般的な用語で話そうと思います。
動画版： この記事は、AI Engineer World's Fair 2026 での私の基調講演 に基づいており、それを拡張したものです。
この記事へのフィードバックを提供してくれた [@addyosmani](https://x.com/addyosmani), @CyrusNewDay, [@HamelHusain](https://x.com/HamelHusain), @zeeg, [@dillon_mulroy](https://x.com/dillon_mulroy), @nayshins, [@jeffreyhuber](https://x.com/jeffreyhuber) に感謝します。*
余談：これはバイブコーディングとは関係ない
Addy Osmani 氏が、この強調すべき点を整理しました：
十数人しか使わないサイドプロジェクトをバイブコーディングする開発者と、10年物のエンタープライズシステムをあと四半期動かし続けるチームは、名前を挙げる価値のある制約をほとんど共有しておらず、流通しているアドバイスのほとんどは、実際にはそのうちの一人がもう一人に生き方を教えているようなものだ。
もしバイブコーディングが好きなら、どうぞバイブし続けてください。私も多くのことはバイブコーディングしますが、同時に 多くのプロダクションソフトウェアを維持管理しており（そして HumanLayer を通じて、何千人もの他のエンジニアが同じことをするのを支援しています）、この後の内容は、複雑なコードベースで難しい問題を解決している人々を対象としています。
この分割について説明するために、ブラウンフィールド という言葉をよく耳にします。歴史的には、それは10年物の Java の何かを意味していましたが、今私たちが出荷できるペースでは、エージェントが構築したコードベースはおそらく 3 ～ 6 ヶ月 後には苦労し始めるように感じられます。速度が低下し始め、新しいものを追加する方法を変える必要があります。
ソフトウェアファクトリーの簡単な歴史
私はキャリアを通じてソフトウェアファクトリーを構築し研究してきましたが、最近知ったことです：この用語は、1968年の NATO 会議 まで遡ります。これは「ソフトウェアエンジニアリング」という用語を生み出したのと同じ会議です。
それ以降で非常に興味深いと思う唯一のことは、米国国防総省が31ページの PDF を書き、国防総省が Jenkins をより良く使う方法などについて 述べていることです。
2022年のソフトウェアファクトリー
AI が登場する直前の2022年頃の「ソフトウェアファクトリー」の定義を明確にしましょう。典型的なソフトウェアファクトリーでは：
- 何を構築するかは人が決める -- エンジニア、PM、リーダーシップがビジョンを推進
- それはトラッカーに入る -- Linear、Jira など：何をすべきかの状態機械
- 誰かがチケットを取得して構築する -- おそらくその過程で手動/自動テストを行う
- プルリクエスト -- 自動チェック、人間がコードをレビュー、誰かがテストのために pull するかもしれない
- 何か問題があるか？ 「誰かが構築する」にループバック
- 本番環境に出荷 -- そしてユーザーと接触する
- 監視を追加 -- 何かが壊れたときにエンジニアを午前3時に呼び出すための産業全体が存在する
- ユーザーが苦情を言う -- 機能を要求し、バグを見つけ、機能リクエストを提出 → チームに戻ってトラッカーに追加
そしてそれが続きます。まだ AI にすら到達していませんが、この図にはすでにいくつかのループがあります。
アライメントの事前負荷
チームが数十年前に発見したことがあります：構築には数時間から数日かかり、レビューにも同様に時間がかかります。
そこで、私たちは作業を事前に負荷します。つまり、計画、アーキテクチャ提案、スプリント計画などを、チームとして一緒に行います。これはつまり：
- 手戻りが減る、なぜなら誰もコードを書く前にアライメントを取ったから
- すべての行をレビューする時間が減る、長いけれどもよく書かれた PR を読んだことがあるなら、それが完璧に近い場合、レビューがどれだけ速く進むか知っているでしょう
これについては後で戻ってきます。次に、エージェンティックコーディングを導入すると何が起こるか見てみましょう。
エージェンティックソフトウェアファクトリー
今やあらゆる企業が --
この年の大半を、コードの約75% を出荷するエージェントファクトリーをどのように構築したかを説明することに費やしてきました。
エージェンティックファクトリーは、主に 「誰かが構築する」→「エージェントが構築する」 に置き換わるように見えます。ここには、オーケストレーション、ハーネス、サンドボックス、モデル、コンピューターユースなど、いくつかのものがあります。これらの詳細については深く掘り下げません。正直なところ、読むのにうんざりしているし、皆さんもそうだと思います。
エージェントが構築する場合：
- 構築は数時間または数日から、数分または数時間に短縮されます。
- レビューにはまだ数時間または数日かかります。人間はまだコードを読み、変更をテストする必要があります。そのため、レビューがボトルネックになります。
そこで、レビューも高速化します：
- エージェンティックコードレビューで、スタイル、バグ、セキュリティをキャッチ。
- エージェンティック回帰テストで、ブラウザやコンピューターユースを使って外部からテストし、完了したらかわいい小さなビデオを送ってくれるかもしれません。
レビューは速くなりましたが、おそらく依然としてボトルネックです。しかし、もっとループを増やすことができます。
次に、インシデントをファクトリーにルーティングするかもしれません。午前3時に誰かを呼び出す代わりに、おそらくすでに修正している PR を見て目を覚ますことになります。
ユーザーフィードバックをファクトリーにルーティングすることもできます。人々が何かを要求し、それが構築されます。
この時点で、仕事は2つの質問になります：キューにどれだけ詰め込めるか、そして出てくるものをどれだけ速くレビューしてテストできるか、です。
これで、無人ソフトウェアファクトリーの話になります。
無人ソフトウェアファクトリー
Dan Shapiro 氏がこの用語を作り、Simon Willison 氏が StrongDM の実装について 書きました。そこでは、私たちはもはやコードを読みません。
あなたは美しいソフトウェアファクトリーを見ています。あの厄介な小さなコードレビューのステップによって台無しにされています。そしてあなたは言います：あれだよ、人間がすべての変更を読むってやつ？ 結構です。
そこで、それをやめて、労力を他の場所に注ぎます：
- テストに投資し、エージェントに自身の作業をテストさせる
- サンドボックスとオーケストレーションに投資
- 自動レビューに投資
- 監視に投資
- ロールアウトに投資
- ユーザーからのフィードバックシグナルの収集に投資
そして今、仕事は本当に1つの質問だけになります：エージェントにどれだけのことを構築させるか？ 大海原をどれだけ沸騰させたいか？
これはうまくいくはずだ（うまくいかない）
私は、潜在的に物議を醸すかもしれないことを提唱します：無人ファクトリーは機能しません。
ソフトウェアファクトリーがなぜ失敗するのか、見ていきましょう。
私たちはこれを試した
2025年7月、私たちは完全に無人化しました。仕様とチケットだけを読み、中小規模のものはすべてバックグラウンドエージェントに任せ、全てを。
もしこれを数ヶ月真剣に試したことがあるなら、結果はすでに分かっているでしょう。少なくとも1つは、エージェントが解決できない厄介な問題に遭遇します。最も高度なプロンプトとワークフローを使ってもです。
- 深いコンテキストを認識した調査を行い、モデルが分析できるスマートゾーンに適切な部分をすべて集める
- エージェントに10通りの方法で再現を試みさせる
結局、あなたは観念して、3ヶ月前に読むのをやめたコードベースに潜り込み、何が壊れているのかを解明しなければなりません。
その間、こういうことになります：
- サイトはダウンしていた。
- ユーザーは怒っていた。
- そしてあなたは、もし私と同じなら、悲惨な気分だった。自分がシステムに紛れ込ませてしまったすべての質の低いコードを読むことになるのだから。
これが初めて起こったとき、私は気にしませんでした。Claude のスパゲッティコードを掘り起こすのにほぼ2週間を費やしたにもかかわらず、「ダウンサイドリスクは速度に見合う価値があった」のです。11月に3回目くらいの頃には、ゼロから書き直す方が簡単だと判断し、私の共同創業者は 丸2週間 を VS Code（Cursor ですらなく）で費やし、すべてのパターンを手で書き出しました。
モデルは時間の経過とともにコードベースの品質を低下させる
私が言いたいのはこれです：モデルには欠点があります。モデルは、コードベースの品質を長期間にわたって維持し改善することができません。かなりの量の人間による steering がなければ。4
私が保守性と言うとき、それはコードベースのある部分を変更することが、他の部分を壊さずには非常に難しくなる、特定の状況を指します。これは Martin Fowler のショットガン手術 です。
保守性についてはこれ以上多くを語りません。読める本がたくさんあります。
- John Ousterhout 著『A Philosophy of Software Design』
- Robert C. Martin 著『Clean Code』
- Martin Fowler 著『Refactoring』
では、なぜモデルはソフトウェアの保守性を できない のでしょうか？
「でも確かにモデルはそれ以来ずっと良くなっているはずだ」
この時点で、あなたはこう言いたくてたまらないかもしれません：でも Dex、確かにモデルは7月からずっと良くなっているはずだよ
確かに、いくつかの点では良くなっています。他の点では、ほとんど同じです。
- 一回限りの問題を解決したり、新しいマーケティングサイトをバイブコーディングしたりする？ はい。ずっと良くなっています。
- 長期間にわたってコードベースの品質を改善する？ 私の知る限り、あまり良くなっていません。
私はこれを証明できません。あなたも証明できません。モデルのコードベース品質維持能力に関する良いベンチマークは存在しません。（これがどこに向かっているかについては後ほど詳しく。）
モデルのコードベース品質維持能力に関する良いベンチマークは存在しない
しかし、もしあなたがコーディングエージェントをしばらく使ってきたなら（そして多くの人がまさにこれについて投稿しています）、おそらくすでに感覚はあるでしょう：彼らは時間の経過とともに物事を悪化させ、コードベースでの作業を困難にする傾向があります。
では、なぜこれが起こるのかを理解するために、最初の偉大なコーディングエージェントに視点を広げてみましょう。
Claude Code が勝ったのは、ハーネス内の強化学習のおかげ
Claude Code はゼロから約40億ドル（現在は約90億ドル）の収益を1年足らずで達成しました。
これは少し驚くべきことです。なぜなら、すでに優れた CLI エージェントが存在していたからです。aider、cline、codebuff -- これらはすべて Claude Code より前に存在し、本当に優れたコンテキストエンジニアリングが組み込まれており、Claude Code の特徴とされるのと同じツールセット（read、write、edit、grep、bash）を備えていました。私も使っていました。それらは良かったです。しかし同時に、ツールの使用は時々... 失敗していました。同じ編集を3回も試行錯誤するのを見て、あなたは自分のエディターを開き直して自分でやったものです。
2024年の SWE-Agent 論文 は、ツールの形状の小さな変更が顕著な違いを生むことを概説しています。例えば、ReadFile の結果に行番号を含めたり、Edit ツールを検索/置換から行範囲編集に変更したりすることです。
その後、Claude Code がローンチされ、急速に垂直に伸びました。これは流通のおかげだと片付けることもできますが、正統に受け入れられている説明は、Claude Code が勝ったのはより優れていたからであり、より優れていたのは Anthropic がモデルを ハーネス内で 強化学習したからだということです。これは、ラボがモデルを出荷する予定の正確なツールに対してトレーニングした初めてのケースでした。そして、エージェンティックループでそれらのツールを呼び出すことに 本当に、本当に 優れるようになりました。
ツールの定義と評価をいじって、モデルが最も好む形状を見つけることは一つのことです。私はさまざまなユースケースでこれに何週間も費やしたことがあります。重みを所有し、特定のツールセットに優れるように モデル自体を変更 できる場合は、また別のゲームです。
OpenAI チームは11月のトーク でこれを非常にうまく表現しました：ハーネスを構築しても、重みを所有しておらず、その内部でモデルを強化学習できないなら、両方を所有するチームに対して常に不利な立場に立つことになります。
60秒でわかるコーディングエージェントの強化学習
私はこのトピックについて多くの調査を行い、重要な部分を説明するための多くのビジュアライゼーションを作成しましたが、Calvin French-Owen 氏（Codex チームの MTS、Segment の創業者）が AI Council で行ったトークの方がはるかに優れていて明確だったので、彼のスライドに触発されたこのアニメーションをここに掲載します：
モデルをコーディングに優れさせるには、次のことを行います：
- 問題を解決するためのコーディングエージェントのトレースをいくつか生成する（例：テストを修正する）
- いくつかの基準に基づいてトレースをスコアリングする（検証器）
- 良いトレースがより可能性が高くなり、悪いトレースがより可能性が低くなるようにモデルの重みを更新する
そして、これを数週間から数ヶ月かけて何百万回も行います。
ただし、これらの「スコアリング」の部分は、気まぐれに一次元的になりがちです。
悪い設計に対するペナルティはない
SWE-bench Multilingual を例に挙げましょう。タスクは小さく、それぞれ約15分の作業量で、Redis、jq、Django などのオープンソースリポジトリから抽出されたものです。報酬は次の基準に基づいて1か0です：
- FAIL_TO_PASS - 依頼された問題を修正しましたか？
- PASS_TO_PASS - 他の何かを壊さずに修正しましたか？
以下は実際の例で、fastlane__fastlane-19304、fastlane から -- Ruby プロジェクトです。その zip アクションは2つのオプションパラメータを取得し、それらに対してすぐに .empty? を呼び出します。そのため、include と exclude を省略した瞬間に、エラーが発生します：
この特定のイシューをクローズした人間による修正は2行です（nil を空の配列にデフォルト設定）：
評価中、モデルは
- ベースコミット から開始します -- リポジトリがその修正が適用される直前の時点にチェックアウトされている
- バグレポート -- この場合 'zip_command': undefined method 'empty?' for nil:NilClass
エージェントはイシューに基づいてコードを書きに行きます。ゴールデンパッチや、採点者として機能する テストパッチ は見えません：
その後：
- 生成されたパッチは保持されますが、
- テストファイルに行った編集はすべて破棄されます（モデルが失敗するテストを静かにコメントアウトしたり、テストを無意味にするモックを挿入したりするのを捕捉しています）
- ベンチマークのテストパッチを上から適用し、
- スイート全体を実行します：既存の zip テスト（PASS_TO_PASS）と新しいテスト（FAIL_TO_PASS）の両方がパスするかどうかを確認します
余談 - ベンチマークは検証器ではありません。実際、相互に保持する必要があります（テストでトレーニングしてはいけない、など）。主に、これは「コーディングエージェントトレースの品質を判断する」ことの形状とその限界を伝えるためのものです。
モデルが正しい答えにどのように到達したかは重要ではありません。テストがパスすれば、私たちの勝ちですが、コードベースの保守性を損なうことに対するペナルティはありません。
コードベースの保守性を損なうことに対するペナルティはありません
それが、すべてを try catch で囲む方法です：
品質の検証は「テストが通ったか」よりも桁違いに難しい
テストを実行すると、クリーンな合格か不合格かが約 秒 で得られます。そのため、強化学習は各モデル世代を最適化するために何百万回ものループを実行できます。
しかし、悪いアーキテクチャのコスト関数は、週、月、場合によっては年単位で測定されます。それは、誰かが1行の変更のためにそのファイルを開き、1行で変更できないことに気づいた瞬間に発生します。誰かがこれを少しやりすぎて、今度は11箇所で同じ編集をしなければならず、3ファイル先で何かが静かに壊れないことを願うはめになります。
テストは数秒でフィードバックをくれますが、悪いアーキテクチャのコスト関数は週、月、場合によっては年単位で測定される
悪い設計は、今日のベンチマークが評価できない唯一のものです。そして、わかっています、わかっています、強化学習 != ベンチマークですが、もしこれが強化学習で解決されていたなら、ベンチマークの設計にも現れ始めるだろうと、私はかなり確信しています。
いずれにせよ、私は個人的には、今日のベンチマークでの改善を、モデルが突然あなたのコードベースを汚さないことに優れたことを示す指標として信頼していません。
フロンティアはゆっくりと良くなっている
もちろん、多くの賢い人々がこれに取り組んでいます。私の主張はそれができないということではなく、誇大広告が規律を追い越している ということです。
正しい方向を向いていると思ういくつかの取り組み：
- SWE-Marathon (Abundant AI)：単一の合格/不合格ビットではなく、複合報酬チャネルを持つ、約400時間のタスク（例：「Excel のすべての機能をクローンする」）
- DeepSWE (Datacurve)：実際の世界では決して構築されなかった OSS リポジトリ上の大規模タスク。そのため、構造上、トレーニングセットに既に存在することはあり得ません（汚染は解決しますが、品質は解決しません）
- Frontier Code (Cognition)：複数 PR のタスク、および品質を決定論的に評価する巧妙な方法。パッチ前のコードで失敗しないテストを書いた場合、モデルにペナルティを課します（ミューテーションテスティング について聞いたことがなければ、楽しい体験が待っています5）。また、コード品質ルールをチェックするために、差分に対して判定モデルを実行します。
しかし、品質を判断するモデルにも限界があります。
実際、モデルが良いコードと悪いコードを確実に見分けられるようになれば、そもそも最初から良いコードを書いたかもしれないと想像するのは難しくない。RL には高速で信頼性の高いオラクルが必要だが、保守性についてはまだそのようなオラクルは存在しない。
もしモデルが良いコードと悪いコードを確実に見分けられるなら、最初から良いバージョンを書いていたかもしれない。しかし保守性には高速なオラクルがなく、RL で報酬を与えることができない。
もちろん、レビューエージェントの増加やトークンの増加は役立つ。愚かなミスをキャッチし、下限を引き上げてくれる。
しかし、上限を引き上げることはできない。なぜなら、上限は RL でモデルに教え込んだものに過ぎず、優れた設計はまだ教え方がわからないものだからだ。
だから、私はまだどのコードベースもこれらに賭けるつもりはない。しかし、これらは私が見た中で初めて、pass/fail で止まらずに保守性をスコアリングしようとした評価方法だ。
余談 将来のモデルがこれを理解し、私たちが終わりにできるかもしれない。GPT-7 がリリースされるまで適当にプロンプトを投げて結果を見たいなら、ご自由にどうぞ。だが、苦い教訓はともかく、今解決すべき問題がある。私はその方法を説明しよう。
明かりを再び灯す
今日知ったんだけど、Twitter の記事には「メディア制限」があるらしく、残りの内容はパート II の投稿に回すことにする。お楽しみに。
