コーディングエージェントを多数並べても、それだけでは開発速度は上がらない。コード生成は計算資源を増やせば並列化できるが、人間が差分を理解し、製品として妥当かを判断できる量は簡単には増えないからだ。Firecrawl は、エージェントを取り囲む受付、隔離環境、道具、検証、マージ判断の仕組みを AI ソフトウェアファクトリと呼んでいる。
受付では、エージェントに着手させる価値がある仕事だけを選ぶ。実行環境は worktree、コンテナ、クラウド上の隔離環境の順に強くなり、並行作業のファイル、依存関係、ポート、データベースなどの衝突を防ぐ。道具の層では、テスト、監視情報、機能フラグ、外部の最新資料などへ接続する。検証では、整形、コンパイル、テストのような安価で決定的な確認を先に行い、その後に変更範囲の逸脱を評価するモデルや CI を置く。最後に、変更の影響範囲に応じて自動マージ、一人のレビュー、複数人のレビュー、領域の責任者による承認を使い分ける。
この構成はループエンジニアリングを組織規模へ広げたものと捉えられる。一回の実行を反復可能にするだけでなく、多数の実行から人間へ渡す結果を段階的に減らす。永続的なセッション記録を残しておけば、作業環境を使い捨てにしても、経緯と結果は失われない。
検証では、テスト合格をマージ可能性と同一視できない。記事が紹介する METR の調査では、自動評価を通過した AI 生成のプルリクエスト296件のうち、およそ半数を保守担当者がマージ不可と判断した。画面の崩れ、変更範囲の逸脱、保守性、製品上の判断は、コンパイルとテストだけでは十分に捉えられない。そのため、変更箇所に絞った画面確認や、別のモデルによる変更範囲の評価を、人間のレビューより前に置く。
モデル自身が申告する確信度も品質の代わりにはならない。記事が紹介する Faire の事例では、確信度による厳しい足切りでコメントの65%を捨てても、採用率は3%しか改善しなかった。変更の背景を多く与え、指摘すべき箇所を絞り、別のモデルに「人間が読む価値があるか」を評価させた方が採用率は上がった。これはプロジェクト固有の文脈を版管理する必要性ともつながる。
公開事例で特に成果が出ているのは、新製品の設計よりも、依存関係の更新、テスト移行、言語版の更新のような機械的で広範囲な保守作業である。Microsoft の dotnet/runtime では、エージェント作成のプルリクエストのマージ率は人間より低く、完全自律のものより人間が修正を加えたものの方が大幅に高かった。一方、マージ後の取り消し率には目立った悪化がなかった。人間の関与は不要になったのではなく、コードを書く工程から、着手条件、検証方法、マージ条件を設計する工程へ移っている。
Firecrawl の記事は自社の検索製品をこの仕組みに組み込む販売上の主張も含む。リポジトリ外にある最新版の移行案内や既知の不具合を取得する必要性は一般化できるが、その手段が Firecrawl でなければならないとは記事からは言えない。まず現在もっとも手戻りを生んでいる一箇所にゲートを置き、除外できた不適切な仕事、人間に届いた差分の精度、検証費用を測ってから広げるのが妥当である。