ソフトウェアファクトリーとは、ハーネス化されたループを大規模に実行することです。ループは人間を中に入れて実行することもできます（明るいファクトリー）。これは、判断力と集中力を速度と破損と引き換えにするものです。あるいは、人間を無視して（暗闇のファクトリー）、誰も詳細を実際に読むことなく、エージェントにコードのスコープ定義、構築、出荷を任せることもできます。しかし、人々が読むのをやめれば、ソフトウェアを理解するのもやめてしまいます。今、あなたの最も難しい仕事は、どのチェックを構築し、どの程度の自律性を委任するかを見極めることです。
ソフトウェアファクトリーというアイデアは、1968 年に発表された Bob Bemer 氏の 論文「The economics of program production」にまで遡ります。半世紀の間、多くの人がソフトウェアを（工場で自動車部品を打ち抜くように）再現可能で計測可能な生産プロセスにすることを夢見てきました。これは、個人の孤立した職人技とは対照的なものです。歴史的に、この夢は（普遍的にではないにせよ）概して失敗に終わってきました。その理由の一部は、アイデアを打ち抜くことの難しさにあります。
しかし、この 2 年で状況は劇的に変わり、今こそ古い夢を新たな視点で見直す価値があります。そして、いくつかの微妙な点は簡単に見落とされがちなため、何が本当に新しく、何が異なっているのか、そして何が新たな機会を装った繰り返しの罠なのかを、ある程度正確に定義することには価値があります。
@dexhorthy（HumanLayer の共同創業者）は、最近 AI Engineer World's Fair で素晴らしい講演 [「ハーネスエンジニアリングだけでは不十分：ソフトウェアファクトリーが失敗する理由」](https://youtu.be/htM02KMNZnk?t=27219) を行いました。このテーマについての貴重な内容です。
ループが原子であり、ファクトリーはそれを大規模化したもの
構造こそがすべてであり、そのすべては小さな単位から始まります。スタック全体は、実際には 3 つの概念が積み重なったものです。ループ、ハーネス、そしてファクトリーです。
ループとは、1 つのエージェントが 1 つのジョブを繰り返し実行することです。コンテキストを収集し、アクションを起こし、結果を確認し、特定の条件が満たされるまで再度実行します。これはエージェントワークの最小単位であり、それより上のものはすべて、ループの上に積み重ねられたループにすぎません。
ループエンジニアリング の要点は、エージェントにターンごとにプロンプトを与えるのをやめ、代わりにエージェントにプロンプトを与える小さなシステムを設計することです。
ハーネスとは、ループの周りの壁のようなものです。ループが実行されるサンドボックス、アクセス可能なツール、実行間で維持されるメモリ、そして「完了」を決定するゲートです。ループは動作であり、ハーネスはその動作が実行される環境です。
ハーネスのない生のモデルを手渡すと、それは喜んで無限に回転し続けます。ハーネスは、それを有用かつ安全に実行するための周りのすべてです。
ソフトウェアファクトリーとは、多数のハーネス化されたループが同時に実行され、作業キューから供給され、レビューゲートを通過して本番環境にデプロイされ、人間が全体を上から管理するものです。これはより大きなエージェントではなく、ループで構成された組織図です。
最終的なパラダイムシフトは、コードを書くことから、そのコードを書くファクトリー を構築し実行することへの移行です。作業の単位は、個々のコード差分ではなく、ループ、ハーネス、そしてそれらの間のフローへと、1 つ上のレベルにシフトします。
ループ → ハーネス → ファクトリー。ファクトリーは、より賢いエージェントではありません。1 つのレビューゲートに供給される多数のハーネス化されたループであり、人間がアウターループを所有しています。描かれたファクトリー
Dex が最も時間をかけた中央のスライドは素晴らしかったです。なぜなら、それは他の方法ではわかりにくいループを明確にする配線図だからです。私の解釈は次のとおりです。
ファクトリーは閉じたループです。インテントと本番環境からのシグナルがキューに供給され、ハーネスが構築し、自動チェックとレビューゲートが通過させ、デプロイが出荷し、モニタリングが本番環境のシグナルをループの開始に戻します。インテントは、エンジニアリングリーダーシップのビジョン、そしてエンジニアから直接、実行すべきことのキューに流れ込みます。インシデントやユーザーリクエストによって駆動されるシグナルも、同じキューを駆動します。
ハーネスは、キューからアイテムを取得し、その変更を構築するものにすぎません。ハーネスの先には、本番環境にリリースしても安全な変更にするために必要なすべての自動チェックを見ることができます。これらの自動チェックは、CI、テスト、静的解析、そしてあらゆる種類のスキャンのおかげで、エンジニアの意識的な関与なしに、同時に、そして楽に実行されます。ここでの唯一の決定ポイントはレビューゲートです。承認後、変更は本番環境にデプロイされ監視され、モニタリングデータはループを動かし始めたシグナルにフィードバックされます。
概して、この図のすべてのボックスはほぼゼロコストです。生成、テスト、スキャン。それらはすべて、無視できるコストで大規模に実行されます。スケーリングに頑固に抵抗する、高価なボックスが 1 つだけあります。それがレビューゲートです。その輝く琥珀色のボックスは「判断」であり、開発をより高速かつ頻繁にできるかどうかという議論の核心が存在する場所です。
なぜ「暗闇」（ダーク）と呼ぶのか
暗闇のファクトリー（ダークファクトリー）は、物理的に照明を消して稼働します。なぜなら、フロアにあるのは機械だけであり、機械は見るために光を必要としないからです。暗闇のソフトウェアファクトリーも同じ動きをします。人間が読んだことのないコードが出荷され、他の機械によってのみ検証されます。
このイメージは製造業から借りてきたものです。その起源は物理的であり、デジタルではありません。照明が消され、作業がロボットによって行われる施設に根ざしています。日本の FANUC は、2001 年からこの種の無人運転ファクトリーを稼働させてきました。Xiaomi は、2024 年に独自の高度に自動化されたダークファクトリーを開設しました。これらに共通しているのは、人間がその内容を一切読むことなく製品が組み立てられ、出荷されることです。この「読む」という行為がプロセスから取り除かれたときに、「暗闇」が生まれます。
私はこのコンセプトを、その雰囲気や侮辱として借りているわけではありません。不気味なバズワードではありますが、ここでの「暗闇」は単純な物理的な主張です。つまり、元の工場のフロアから光を取り除いたものです。ソフトウェアにおいて、フロアとは差分（diff）です。差分を書いた者、レビューした者、出荷した者、それらの人間はいなくなり、残るのはそれを構築した機械によってのみ検証された差分です。
これは驚くほど簡単なことです。少なくとも最初は。簡単なのは、その欠落したレビューステップがすべての邪魔になるからです。それが存在しないと、チームの垂直スループットに対する認識が突然、そして劇的に高まったように感じられます。あたかも音の壁を破ったかのようです。一見簡単そうに見えますが、埋もれたコストを抱えた暗闇のワークフローを生き残ることは、見た目よりも困難です。
ハーネスエンジニアリングだけでは不十分
オーケストレーション、サンドボックス化されたプロトタイピング、そしてモデルが世界や互いに相互作用する際のツール呼び出しのハーネスは、ますます強力かつ効果的になるでしょう。しかし、長期的な視点と追加的な変更を通じてコードベースの品質を維持しようとすることには、モデル内在的な失敗があります。そして、モデルだけが最終的に理解債務 との戦いに敗れると信じるに足る十分な理由があると思います。
理解債務（Comprehension debt）とは、存在するコードの量と、人間がまだ理解しているコードの量との間に広がるギャップのことです。暗闇のファクトリーはそれを返済しません。テストがすべてグリーンのまま、可能な限り迅速にそれを負債として受け入れます。
これは重要な区別です。なぜなら、モデルはいくつかのタスクではうまく機能するからです。しかし、コードベースの小さな部分への即時的な変更ではないもの、特に複雑なブラウンフィールドシステムにおいては、モデルだけの自動コーディングは克服できない障害に直面します。グリーンフィールドアプリ、週末のおもちゃ、サイドプロジェクトは、数ヶ月の開発サイクルで通常は動作する状態、あるいはそれに十分近い状態に到達できるという点で似ています。
しかし、10 年以上にわたって開発が続けられているエンタープライズシステムは、別の獣です。専門的な環境で、専門的なペースで維持されなければなりません。プロジェクト開始から 3 〜6 ヶ月も経てば、あなたはすでに読まれていないコードに溺れています。そのような環境、特に本番コードによって強制される制約は、強力なエージェントでさえも苦戦させるでしょう。これはすべて、週末のおもちゃに取り組む開発者が享受するバイブコーディングとは対照的です。
Dex は経験から、これが大きな失敗であると報告しています。あまりにも大きいため、特定するには入念な手動デバッグが必要でした。これは、約 4 ヶ月間、完全に自動化されたコードファクトリーを実行したことによるものです。その間、人間は書かれたコードを一切見ませんでした。この経験の根底には、2 つの相反する指標の間のトレードオフがあります。1 つは、現在私たちが進歩として扱っている指標であるトークン使用率の最大化です。もう 1 つは、それが静かに最小化するもので、人間の参加者が任意の時点でまだ理解しているシステムの量です。
暗闇のファクトリーが真に輝くのは、テストがグリーンのまま、未読のコードを消費し尽くす能力です。最終的な決算が訪れるとき、それは劇的な「すべてがおかしくなる」瞬間ではありません。それは静かに、そして遅れてやってきます。
暗闇と明るいは、照明が異なる場所にある同じパイプラインです。明るいバージョンは、単にレビューを最後に追加し直すだけではありません。人間の判断を上流の設計とアーキテクチャにも移します。ボトルネックは決して生成ではなかった
ソフトウェアファクトリーにおける根本的な制約は、どれだけのコードを生み出せるかではありません。どれだけ迅速にそれを検証できるかです。
バックプレッシャーとは、ループに与えられる自律性は、安価かつ確実に検証できる範囲に限られるというルールであり、それ以上ではありません。ファクトリーにおける真の制約は生成ではなく、検証です。
無制限の生成能力は、有限でスケーリングしない人間の注意力と常に緊張関係にあるため、核心的な問題は、安価な生成と限られたレビューの間のギャップです。漏斗を見てください。検証を表す首の部分が広がらない限り、詰まりが生じます。Dex が指摘するように、量だけが問題ではありません。私たちが実際に苦しんでいるのは、質の低い PR の過剰供給です。信頼できるゲートなしに大量の量がある場合、製造された欠陥は避けられません。これは再びバックプレッシャーです。自律性は、安価かつ確実に検証できる範囲を超えて拡大することはできません。
二次的な問題は、なぜモデルを改善しても、モデルが生成できるものと検証できるものとの間のギャップが自動的に埋まらないのかということです。適切に設計されたシステムでトレーニングすることは、単純なテストに合格することよりも、おそらくはるかに難しい命題です。アーキテクチャの優秀性を測定するコスト関数は、秒単位や分単位ではなく、月単位や年単位で測定されることを忘れてはなりません。きれいな勾配を計算することは事実上不可能であるため、複雑な設計上の決定を即座に評価することを期待するシステムは、良い例でトレーニングされることはありません。
生成は広い口であり、検証は狭い首です。口を速くしても、首のところに山ができるだけです。
明かりを再び灯す
明るいファクトリー（リットファクトリー）は、判断が存在する場所に照明を残した同じパイプラインです。エージェントは依然としてほとんどの構築を行いますが、人間は出荷前に出力を読み、間違った判断が高くつく場所では照明がついたままになります。
明るいバージョンは、レビューを最後に追加するのではなく、人間の判断のポイントを上流、つまりエージェントがループを開始する前のプロダクト、設計、アーキテクチャに移します。
その事前の 1 時間の素晴らしい点は、実装時間が短縮されることです。長くてイライラするコードレビューが、200 行の計画をざっと読むだけのものに変わります。決定が構築される前にレビューできるため、後になって生成された 2,000 行のコードを追いかけて、決定が何であったかを調べる必要がありません。コストが複利で膨らむ前に、早い段階で人を参加させたいと思うほど、コストが高く、長期間にわたる決定もあります。もちろん、事前に時間を費やしたとしても、差分を確認する必要がある場合もあります。
これらすべては、あまり魅力的に聞こえないかもしれません。その通りです。セーフティネットは、私たちが常に知っていながらほとんど無視してきた、ごく普通のアーキテクチャプラクティスで構成されています。適切な型とメソッドシグネチャ（本番環境ではなくコンパイラがエラーをキャッチできるようにする）、動作を固定して変更を観察可能にするテストシーム、コードのレイアウト（次の読者（人間またはモデル）が関心のあるものをどこで見つければよいかを知っている状態）、コールスタックを短く読みやすく保つこと、コンポーネントの境界を適切に定義して変更の爆発半径を小さくすること、依存性注入（ある部分を別の部分と交換できるようにする）。これらは何も新しいものではありません。私たちは常に優れたアーキテクチャを気にかけていると言ってきました。しかし、現在自動コーディングエージェントを使用しているため、そのアーキテクチャはついに、エージェントが犯すミスに対する安価で偽造が難しいセーフティネットとしての第二の役割を果たしています。
そのセーフティネットはモデルの外部に存在しなければなりません。なぜなら、モデルはそれを提供しないからです。最も有能に感じられるコーディングエージェント（Claude Code や Codex など）は、自身のハーネスとツールに対して強化学習されています。つまり、業界のすべてのツールとイディオムには精通していますが、長期的な保守性などには精通していません。私たちが常に話してきた意図的なアーキテクチャこそが、その負債を捉えるツールであり、私たちがそれに行う投資は、自律性を買い戻すことです。
これを安全なインフラストラクチャと組み合わせると、無人で実行できる、タイトでリスクの低いループがいくつか存在します。Horthy は最近の投稿でその一つを説明しています。それは、夜間の GitHub Actions の cron ジョブで、1 つのアンチパターン（lint 違反や不要なオプションの props など）だけを修正し、コミットし、1 つの小さなプルリクエストを自動的に開くものです。これにより、チームは朝、少し改善されたコードベースと、読むのに十分短い差分を目にすることができます。しかし、リスクが高いループの場合、認証システム、請求エンジン、公開 API コントラクトが壊れた状態で目覚めるリスクを負いたくはないでしょう。そこでは照明を点けたままにし、判断力とシステムに関する実際の実務知識を持つ人間がエラーをキャッチしてくれると信頼しましょう。
何がループに暗闇を獲得させるのか
このルールは、それをバックプレッシャーと呼ぶか、検証と呼ぶか、照明のスイッチと呼ぶかにかかわらず適用されます。
ループが完全自動化ステータスを獲得できるのは、チェックが安価で、高頻度で実行され、簡単に偽装できないものに依存している場合のみです。グリーン・オア・レッドのオラクル、型ゲート、プロパティベーステスト、そして実際のルーブリックと組み合わせたレビューエージェントは、すべてこれに該当します。また、オラクルが即座に回答し、時間の経過とともに変化しないことも必要です。「完了」をあなただけでなく機械が証明できる場合、自動化に到達しています。
短いループは、長いループよりも検証が容易です。Dex の経験則 としては、エージェントは 3 〜10 ステップまでは持ちこたえますが、20 を超えると迷い始めます。理由はコンテキストの蓄積です。エージェントが引きずるものが多ければ多いほど、脱線する可能性が高くなります。ループが短い場合、検証は安価です。広大なループは、隅っこにエラーを隠します。これはつまり、それらが決して無人運転（lights-out）ステータスを獲得しなかったということです。
照明を点けたままにすることは、その逆のケースです。間違った答えが高くつき、それをキャッチできるのは人間だけである場合、ループはレビューされる必要があります。テストでキャッチできない微妙な本番バグ、大きな爆発半径、そして 1 年以上の仕事を形作ることになる決定は、すべて該当します。そのような場合、あなたの注意こそが実際のプロダクト であり、コストがかかり、不可欠なものです。
危険は、各スイッチを切り替えることを忘れて、すべてのスイッチを同じモードに設定してしまうことです。すべて暗闇にすると、4 ヶ月後にすべてを解体することになります。すべて明るくすると、誰も時間通りにレビューを完了できず、巨大なボトルネックに行き詰まります。難しいスキルを要する仕事は、各スイッチをどこに配置するかを決定することです。
ループ、グラフ、それともステートマシン？
@DavidKPiano による「2 分でわかるステートマシン」を読むことをお勧めします。
エージェントにタスクを渡すとき、おそらくその周りにグラフを構築することになるでしょう。そのグラフを有限ステートマシンと呼ぶか、条件付きでリンクされたサービスコールのセットと呼ぶかにかかわらずです。これは、ソフトウェアが単にいくつかの抽象的なルールに従うのではなく、構造化されたワークフローに従うという枠組みです。すべてのノードは明示的なステップであり、ノード間のすべてのエッジは明示的な条件です。
それは多くの構造に聞こえますが、そのほとんどはすでにあらゆるソフトウェアに存在しています。なぜなら、どんなコードも制御フローグラフとして表現できるからです。したがって、唯一の真の目新しさは、自律性を主張するエージェントが実際には特定のグラフを歩き回っているだけで、その自由はノードの内部に制限されているということです。そして、人々が忘れがちな部分があります。それは、Dex が 1 年前に書き留めた ことです。ソフトウェアは常にその構造を持つことになっていたのです。私たちがかつてフローチャートとしてプログラムを描いていたのには理由があります。
真に新しい動きは、図を捨てようとすることでした。モデルがツールコールごとにパスを選択し、自分自身で完了を宣言するまで続けるループに依存することです。それは解放のように感じられました。10 年物のコードベースに遭遇するまでは。そして、現在誰もが再発見している規律、つまり制御フローを所有することは、実際にはループの周りにグラフを戻すことにすぎません。したがって、ループからグラフに戻すべきかどうかという問題は、私たちがずっとフローチャートを必要としていたことを認めるようなものです。
実際の様子は次のとおりです。修正すべきバグを例に取ります。純粋なループとして、あなたは座って考えます。何が問題かを把握し、コードを変更し、テストを実行し、何が起こるかを見て、そのラウンドで実行が終了しなければ、ループバックして最初からやり直します。全体の道のりは、その場その場で決定されます。どの問題を追うか、どのコードを正確に変更するか、どのテストをどの順序で実行するか、テストを実行するかどうか、そして再試行するか勝利を宣言するかです。
グラフとして、最初に行うことは、何が起こるべきかをマッピングすることです。バグを再現するか、さらに情報を求め、原因を見つけ、修正を試み、テストを実行し、失敗した実行は修正にルートバックし、通過した実行はレビューに進み、承認のみが完了に達するようにします。エージェントは各ボックスの中では依然として賢いですが、あなたが許可したパスから迷い出ることはできません。Santi は、この違いを明確にする図を示しました。
もちろん、そのグラフの本当の魅力は、それが図として描かれたバックプレッシャーであることです。エージェントの自由の一部を放棄する代わりに、必須のチェックと判読可能な障害点を手に入れます。そのため、実行が停止したときに、それを殺したノードを指し示すことができます。これは、ほとんどのいわゆるエージェントは実際にはほとんどエージェント的ではなく、「ほとんどが決定論的なコードであり、LLM のステップが適切なポイントに散りばめられている」という Dex の率直な言葉の背後にあるのと同じ本能です。そして、これは単に人々がたまたま現在構築している方法の産物ではありません。このパターンは、LangGraph や LlamaIndex Workflows、Jerry Liu のハイブリッドワークフローグラフ・オーバー・エージェント（実行中にグラフの一部を成長させるアウターループを持つ）、そして David Khourshid の、これは実際にはステートマシンとアクターモデルが新しい服を着て現れているにすぎないという指摘の中に見ることができます。
1 つ明確にしておきます。この用語はひどく過負荷になっているためです。私がこれをグラフと呼び続けるとき、知識グラフを意味しているのではありません。作業がどのように流れるべきか、条件付きエッジもすべて含めた、事前に定義された有向グラフを意味しており、ループに実際に信頼できる形状を与えるものです。
人間は実際にどこへ行くのか
人間は決して工場を離れていないことに注目してください。ただ、その役割が変わったのです。
エンジニアは、[アウターループを自分で管理する](https://addyosmani.com/blog/own-the-outer-loop/) ことをますます必要としていると思います。 エージェントはバグを調査し、診断結果を書き、修正を実装し、テストを実行し、レポートを作成できます。これがインナーループの実行であり、エージェントは誰よりも効率的にそれを行うことができます。しかし、それが仕事だったわけではありません。あなたが所有する部分は、私がアウターループと呼ぶものです。問題に取り組む方法が正しいかどうかを判断し、診断と実装が適切であることを検証し、変更を承認し、間違っていた場合の結果を受け入れることです。2 つのループの境界は、証拠、差分、テスト、ログ、そしてそれらを結び付ける簡単な説明です。型、シーム、ルーブリックにより、すべての変更に多大な作業を費やすことなく、これらすべてを監督することが可能になります。
このように言うとわかりやすいでしょう。あなたはもはや現場で変更を書いているのではなく、生産ラインの終端でそれを設計し、ゲートを守っているのです。モデルをより良くし、ハーネスをより有能にするためにできることはたくさんありますが、長期的に高くつく問題を特定することは、通常、自動化できるものではないと私は観察しています。依然として仕事の中核をなすのは、紙やコンピューティングパワーの流れよりも優れた人間の判断力を行使することです。
ロボットは暗闇で動作しても問題ありませんが、人間は自分たちが何をしているのかを見る必要があります。工場のフロアのすべてが暗闇で、何も見えず、照明のスイッチさえ見つけられないなら、そこに危険があります。
Pangram は、[この記事を 100% 人間が書いたものとスコアリング](https://www.pangram.com/history/d151077c-b4ca-4277-a2fe-75e6cb282f06) しました。
