AI駆動開発のソフトウェアファクトリーはなぜ失敗するのか

AIを入れてからコードが出てくる速度は確かに上がったのに、リリースまでのリードタイムは思ったほど縮んでいない。

もしそういう感覚があるなら、それはチームの練度の問題ではないかもしれません。

この「速いのに速くならない」構造を、無人の開発ラインを実際に走らせて壊した人の記録と、2万2000人分の計測データから整理してみます。

3ヶ月で崩れた無人の開発ライン

ここで言うソフトウェアファクトリーは、製造業のスマートファクトリーの話ではありません。

AIコーディングエージェントがコードを書き、レビューし、デプロイまで回す開発パイプラインのことです。

HumanLayerのDex Horthyさんが、2025年7月から11月にかけて、人間が1行もコードを読まない完全自動の開発ラインを自社で走らせています。

AIが書いて、AIがレビューして、AIがデプロイする。

結果は本人が戒めとして残しているくらいで、3ヶ月ほどでコードベースが読めない状態まで劣化しました。

バグが1件出たときに、何ヶ月も見ていなかったコードに潜り直して数週間かけて手で追う羽目になり、その最中にサイト障害まで起きています。

この顛末をまとめた「Why Software Factories Fail」が、Hacker Newsで380点超、260件超のコメントを集めました。

advanced-context-engineering-for-coding-agents/wsff.md at main · humanlayer/advanced-context-engineering-for-coding-agents

Contribute to humanlayer/advanced-context-engineering-for-coding-agents development by creating an account on GitHub.

github.com

副題が「harness engineering is not enough」なんですよ。

エージェントの周りにルールと評価と安全策を敷く「ハーネスエンジニアリング」は日本語でも解説記事がかなり増えましたが、Horthyさんの主張は「それを全部やっても足りない」です。

速くなったのに壊れやすくなる 2万2000人分のデータ

Faros AIが2026年に出した調査があります。

4,000チーム・2万2000人の開発者の2年分のテレメトリを、同じ組織の中でAI利用が低い時期と高い時期で比べたものです。

速くはなっています。

開発者あたりのタスク完了数は33.7%増、エピック完了数は66.2%増。

問題はその裏側でした。

AI Impact on Engineering Productivity: 2026 Report Data

22K developers reveal AI's real impact: 66% throughput gains but incidents rising faster. Get the definitive data on what's working and breaking.

www.faros.ai

読み方に注意が要るのは、レビューなしのマージが「31.3%ある」ではなく「31.3%増えた」という点です。

とはいえ方向は変わらなくて、出力が増えた分だけ、後ろの工程が詰まっている。

自分のチームだけ回っていないのでは、と思っていたなら、そうではなさそうです。

保守性には速い採点者がいない

ここからはHorthyさんの見立てで、業界の共通見解ではありません。

ただ、構造の説明としてはかなり腹落ちします。

コーディングモデルは強化学習で鍛えられていて、その報酬はテストが通るかどうかです。

テストは数秒で白黒がつく。

一方で「この設計は3年後に保守できるか」を数秒で採点する仕組みは存在しません。

保守性には速い採点者がいないから、報酬に組み込めない、というのがHorthyさんの説明です。

具体例として挙げられているのがfastlaneの実際のIssueです。

nilが渡ってくる箇所が壊れていて、人間なら || [] を2行足して既定値を空配列にすれば終わる話でした。

モデルはテストを通す方向に最適化されているので、その場をしのぐ書き方に倒れる。

テストは緑になる。

設計は少しだけ歪む。

1回なら誤差なんですよ。

それが3ヶ月積み上がると、誰も読めないコードベースになる。

悪い設計のコストは数週間、数ヶ月、へたをすると数年という単位でしか現れない、というのが本人の言い方です。

この主張はまだ決着していない

Hacker Newsの260件超のコメントは、賛成一色ではありません。

むしろきれいに割れています。

どちらが正しいかは、正直まだ誰にも言えないと思ってて。

ただ判断する側としては、どちらの前提で今期の計画を引くかは決めないといけないんですよね。

コストを8分の1にした側も人の判断は外していない

材料をもう1枚。

工場化を一番攻めている側の動きも見ておく価値があります。

Cursorが2026年7月20日に出した実験では、賢いモデルの「プランナー」1体が仕事を分解し、安いモデルの「ワーカー」多数が実装する構成を試しています。

SQLiteをドキュメントだけ見てRustで書き直させるという課題で、Opus 4.8のプランナーとComposer 2.5のワーカーの組み合わせが約20万円。

すべてをGPT-5.5で回すと約160万円。

同じ結果に対して約8倍の開きです。

エージェントスウォームと新しいモデルの経済性 · Cursor

旧世代と新世代のエージェントスウォームがSQLiteをゼロから構築する様子を比較した結果、より優れた連携によって、コストを大幅に抑えながら同等の品質を実現できることがわかりました。

cursor.com

面白いのはここからで、Cursor自身が「単一のレンズで全部は捕まえられないが、相関のないレンズは重ねると効く」と書いています。

さらに「長時間動く多エージェントの系ではエラーが蓄積するので、小さなミスが土台になる前に自己修正する仕組みが要る」とも。

実験そのものも、人がコードと実行ログを見てズルや近道がないかを確認しています。

工場化に一番アクセルを踏んでいる側が、チェックの層を減らすのではなく増やす方向で設計している。

現実的な期待値は2倍から3倍

Horthyさんの結論は「10倍から100倍ではなく、2倍から3倍を安全に」です。

ここも独立した比較実験の数字ではなく、本人の経験則として読むべきところ。

ただ、期待値の置き方としては使えます。

判断する側が押さえるのは、この3点かなと。

1. 目標倍率を2倍から3倍に置き直す。10倍前提でロードマップを引くと、遅れの原因を現場の頑張り不足に帰着させてしまいます
2. レビューを工数として予算に載せる。レビュー待ちの時間が跳ねているデータがある以上、出力を増やすなら受ける側の枠も一緒に増やさないと詰まります
3. 前段の合意は大きい変更にだけ置く。Horthyさんの4段階（製品レビュー、システム設計、プログラム設計、垂直スライス）は全タスクに必要なものではなく、約4割は一発で通してよいと本人も書いています

同じ週に、Addy Osmaniさんが「ダークファクトリー」と「ライトファクトリー」という対比を出していました。

ダークは人が1行も読まないまま出荷される状態。

ライトは同じパイプラインのまま、判断を間違えると高くつく場所にだけ明かりを残す状態です。

問うべきは人を外せるかどうかではなく、人の判断をどこに置くか。

少なくとも今のところ、そこの設計はまだこちら側の仕事として残っています。