月間2,500件のPull Request (PR) を本番環境にマージした、という話を聞いて、正気かと思った人も多いだろう。
単なる与太話か、あるいは劣悪なコードのスパム爆撃ではないかと疑うのも無理はない。しかし、Cursor（現SpaceXAI）のSoftware Engineerであるpoteto氏が達成したこの異常な数字は、AIエージェントを無秩序に暴れさせた結果ではなく、極めて緻密に設計された「環境」と「検証プロセス」の賜物である。昨今、AIによる開発自動化を指してSoftware Factoryという言葉がバズワード化しているが、彼女とMatt Pocock（TypeScriptの第一人者であり、grill-me skillの提唱者）のpodcast対談を紐解くと、そこにあるのは無機質な工場展開というよりも、狂気的なまでに洗練された厨房のオーケストレーションであることがわかる。
本稿では、単なるAIツールの紹介やプロンプトの小手先テクニックといった低次元な話は無視し、彼女らがどのようにしてエージェントへの「Trust Ladder（信頼の階段）」を登り、最終的に自らが眠っている間にエージェントが自らPRをマージする「Dark Factory」を構築するに至ったのか、そのアーキテクチャと背後にある設計思想に焦点を当てる。
Michelin Kitchen：Software Factoryメタファーの限界
AIエージェントをスケールさせることについて語る際、poteto氏はSoftware Factoryという言葉を好まない。その代わりに彼女が用いるのが「Michelin Kitchen（ミシュランの厨房）」というメタファーである。工場という言葉には、品質やクラフトマンシップが欠如しているというネガティブなニュアンスが付き纏うが、彼女らが目指しているのは「ただ動くコード」を大量生産することではなく、極めて高品質なソフトウェアをスケーラブルに生み出すことだからだ。
この厨房の比喩は、エージェントとの協業プロセスを見事に言い表している。我々がAIを使い始めた当初は、いわば「一人の家庭料理人（Home Cook）」である。野菜を切り、火加減を見ながら、後片付けまで全て自分で行う。そこへ突如として多数のAIエージェント（見知らぬ手伝い）が厨房に入ってきたらどうなるか。道具の場所も手順も共有されていない状況では、単なる混乱しか生まれない。
だからこそ「Trust Ladder」という概念が重要になる。poteto氏自身も、当初は1つのエージェントをマイクロマネジメントすることに膨大な時間を費やし、自分がAIとChrome DevToolsの間に挟まる「Meat Proxy（肉でできた中継機）」になっていることに絶望したという。そこから彼女は、自らのワークフローを抽出し、エージェントにスキルとして授けるプロセスを開始した。シェフが自ら全ての料理を作るのではなく、Sous-Chef（副料理長）たちにタスクを委譲し、厨房全体を管理するExecutive Chefへと自身のロールを昇華させていったのである。
ここで興味深いのは、AIが進化すれば人間のドメイン知識は不要になるという世間の凡庸な予測を、彼女らが真っ向から否定している点だ。AIモデル（Opus 5.5や最新のFrontier Models）の推論能力が劇的に向上した現在、真のボトルネックはAIの知能ではなく「人間の意図（Intent）やビジョンをいかに正確に言語化し、エージェントに転送できるか」へと移行している。深いドメイン知識を持つ者だけが、解像度の高い指示を出し、出力されたものの真贋を見極めることができる。
Verification：エージェントに「目」と「手」を与える
AI開発において最も重要なスキルは何かと問われれば、poteto氏は迷わず「Verification（検証）」を挙げる。
どんなに優秀なLLMであっても、最終的な成果物を見る「目」と、コードを実行する「手」を持たなければ、ループは回らない。出力されたコードが実際に動くかどうかを人間がいちいちブラウザで確認し、エラーログをコピペしてAIに戻しているうちは、スケーラビリティなど夢のまた夢である。
poteto氏が構築したVerificationプロセスは、エージェント自身にPlaywrightやChrome DevToolsのプロトコルを操作させ、実際にアプリケーションを立ち上げ、人間のようにクリックし、パフォーマンスのトレースやヒープスナップショットを取得させるというものだ。これにより、エージェントは自らの成果物を自己評価し、自律的に改善を繰り返す（Hill Climbing）ことが可能になる。
ここで彼女が実践している特筆すべきアプローチが、「決定論的（Deterministic）な処理の切り出し」である。
AIエージェントの非決定性と環境の決定性 AIの本質的な価値は、文脈を理解し判断を下す非決定的な推論能力にある。一方で、抽象構文木 (AST) を解析してコードを変換するCode Modや、特定のテストスクリプトを走らせるといった作業は、毎回AIに考えさせる必要のない決定論的なタスクだ。poteto氏はこれらの機械的な処理をCLIツールとして抽出し、スキルの内部に隠蔽している。これによりContext windowの浪費を防ぎ、エージェントには純粋な「判断」のみにリソースを割かせているのである。
Environment as a Constraint：TypeScript的環境構築論
2,500ものPRを捌く基盤として欠かせないのが、エージェントが活動する「環境（Environment）」の構築である。
優れたCodebaseとは何か。それは「破壊することなく、容易に変更を加えられるCodebase」である。poteto氏もMatt Pocock氏もTypeScriptの深い知見を持つエンジニアだが、彼女らの環境設計論はTypeScriptのType Narrowing（型の絞り込み）の思想に酷似している。広大な可能性（Any）の中から、ガードレールと制約を設けることで、不正な状態を物理的に表現できなくするアプローチだ。
彼女らの内部フレームワーク（Duneと呼ばれるElectronアプリ用の内部Next.js的フレームワーク）は、極めて厳格なLintルールと規約（Convention）で縛られている。「機能を追加するならこのディレクトリに配置するしかない」というレベルでルートが限定されており、エージェントが「悪いコード」を書くこと自体が困難なように設計されている。
エージェントがミスを犯したとき、三流のエンジニアはプロンプトをいじってその場しのぎの修正を行う。しかし一流のエンジニアは、そのミスを観察し、「なぜこの環境はそのミスを許容してしまったのか」を問い、新たなLintルールや規約としてCodebaseそのものに制約（Constraint）を埋め込む。エージェントの記憶力やシステムプロンプトの長さに依存するのではなく、環境そのものにルールを語らせるのだ。
Outer LoopとInner Loopの自動化による異次元のスケール
では、具体的にどのようにして月間2,500件ものPRを生み出しているのか。当然ながら、人間が手動で2,500回のチャットセッションを立ち上げているわけではない。ここには2つのループの結合が存在する。
1つ目は「Outer Loop」だ。Slack、X、Linear、メールといった外部システムから飛び込んでくるバグレポートや機能要望などのコンテキストを収集するループである。poteto氏はGrok Botなどを用い、特定のSlackチャンネルを監視させ、バグ報告が上がるたびに自動的にトリガーを引く仕組みを構築している。
2つ目は「Inner Loop」である。これはCursor Projects（クラウド上で稼働するCoordinatorエージェント）が担う。Outer Loopから「デスクトップアプリのパフォーマンス低下に関する30件のバグレポート」というコンテキストが投げ込まれると、Chief of Staff（参謀）として機能するCoordinatorエージェントがそれらを分析する。そして、個別のタスクに分割し、それぞれにSub-Agentをスポーン（生成）させて実際の修正作業に当たらせるのだ。
人間が各エージェントのMeat Proxyとしてコンテキストを運搬するのではなく、エージェント自身がSlackを購読し、ユーザーのバグ報告を読み、自ら環境を立ち上げてバグを再現（Verification）し、修正コードを書く。このエンドツーエンドの自律性こそが、桁違いの生産性の正体である。
Dark Factoryとサンプリングの哲学
この極限の自動化が行き着く先が「Dark Factory」である。夜、poteto氏が眠りについた後も、10体以上のChief of Staffエージェントたちが24時間体制で稼働し、Verifierエージェントと協力してファジング（Fuzzing）テストを行い、問題を自己解決し、翌朝には自らPRをマージしているという。
「2,500件のPRをどうやってレビューしているのか？」という当然の疑問に対する彼女の答えは、「全件レビューはしない。サンプリングする」である。
工場の品質管理責任者と同じように、マージされた後のコミット履歴を眺め、ランダムに成果物を抽出してコードの品質を検証する。もしそこで特定のAIが同じようなショートカットやバッドパターンを用いているのを発見したら、個別のPRを修正するのではなく、前述した「環境の改善（Lintルールの追加、スキルの調整）」にリソースを投じるのだ。
このアプローチは、ソフトウェア工学のように「プログラム的に検証可能（Verifiable）」なドメインだからこそ成立する力技とも言える。データ欠損を引き起こすような不可逆な変更（One-way doors）が多い金融や医療のシステムにおいて、直ちに同じことができるわけではない。しかし、Bendのような証明（Proofs）とプログラミングを統合する新たなパラダイムが普及すれば、コンパイルが通ること＝数学的に正しいことが証明されたことと同義になり、より多くのドメインで自動マージが許容される未来が来るだろう。
スキルとはワークフローのエンコードである
最後に、彼女らが提供しているpstackやgrill-meといったプロンプトフレームワークの扱い方について触れておく。
巷には「どのプロンプトが最強か」といった不毛な議論が溢れているが、スキルというものの本質はただのMarkdownで記述された英語テキストであり、魔法ではない。それは彼女らが過去のエージェントとのチャット履歴（Transcript）から、人間が介入せざるを得なかったポイントを抽出し、自らの思考プロセスとワークフローを言語化（エンコード）した結果に過ぎない。
彼女ら自身が推奨しているのは、誰かのスキルを盲信することではなく、自身の過去のチャット履歴をAIに分析させ、「自分がどのようなパターンで修正を指示しているか」をマイニングし、独自のカスタムスキルやLintルールを構築することだ。最新のモデルになればなるほど、具体的なコマンドの手順（How）を指示する必要は薄れ、純粋なプロセスの流れ（Workflow）だけを記述すれば済むようになる。
AIへの依存度を高めることは、決して人間のエンジニアリング能力の放棄を意味しない。むしろ、自身が持つ最高のワークフローを言語化し、それに沿って稼働する強固な環境を設計するという、一段上のメタ・エンジニアリングが求められている。暗闇の工場（Dark Factory）で高品質なプロダクトを生み出し続けるためには、その工場を設計し、刃を研ぎ澄ますアーキテクトの存在が必要不可欠なのだ。我々は今、コードを書く仕事から、コードを書く環境を設計する仕事へと、歴史的なパラダイムシフトの只中にいる。