ソフトウェアファクトリーとは、StrongDM の AI チームが自分たちの作業体制を初めて公に説明した際にこの用語に与えた意味では、仕様とシナリオがエージェントを駆動し、エージェントがコードを書き、ハーネスを実行し、人間のレビューなしに収束させる非対話型の開発である。彼らはこの用語を業界一般のカテゴリーとしてではなく自分たちの実践を指すものとして使っているが、自分たちの造語として提示しているわけではない。出典は彼らを、Dan Shapiro が Dark Factory と呼んだとされる AI 導入のレベルを実践しているチームとして紹介している。彼ら自身のものといえるのは、この定義と、それとともに述べられた二つの禁止事項である。すなわち、コードは人間が書いてはならず、コードは人間がレビューしてはならない。これらには三つ目の実践的な言明が添えられている。人間のエンジニア 1 人あたり 1 日に少なくとも 1,000 ドルをトークンに費やしていないなら、そのチームのソフトウェアファクトリーにはまだ改善の余地がある、というものである。
用法
この実践の残りの部分は、レビューの禁止を持ちこたえられるものにするために存在している。紹介している著者は、チームが直面した問題を当然のものとして描いている。何も手で書かれないのなら、どうやってコードが動くことを保証するのか。そして、エージェントにテストを書かせることは、エージェントがずるをしない場合にしか役に立たないと指摘している。彼らの答えには、名前の付いた三つの部分がある。シナリオは、彼らが転用したと言う言葉であり（出典は彼らの答えがシナリオテストに着想を得たものだと説明している）、多くの場合コードベースの外に保持されるとされるエンドツーエンドのユーザーストーリーである。彼らが比較対象に挙げるのはモデル訓練におけるホールドアウトセットであり、そうすることで、コードを書くエージェントがそれを判定するものを読めないようにしている。各シナリオは直感的に理解でき、厳密にアサートされるのではなく LLM によって柔軟に検証されることを意図している。満足度は、グリーンのテストスイートに代わる尺度である。彼らが育てるソフトウェアの多くはそれ自体がエージェント的な要素を持つため、彼らは成功を確率的に、すべてのシナリオにわたって観測されたすべての軌跡のうち、ユーザーを満足させる可能性が高いものの割合として表す。そして、サードパーティの依存先をエージェントが構築したクローンからなる デジタルツイン・ユニバース が、それらのシナリオを大量に実行できる場を提供する。
チームはまた、自分たちの技法ページで、同じ実践の一部として三つの技法の名前を挙げている。gene transfusion、semports、pyramid summaries である。紹介している著者はこれらをそれぞれ、エージェントに既存のシステムからパターンを抽出させて別の場所で再利用させること、ある言語から別の言語へコードを直接移植すること、そしてエージェントが短い要約を列挙し必要に応じて詳細へ掘り下げられるよう、複数の詳細度の要約を用意すること、と言い換えている。それらのページは彼らのものであり、ここで確認できるのは、そうしたページが存在することと、一行の説明だけである。
適用される場面
チーム自身の説明によれば、この実践はある特定の時点で実現可能になった。彼らはそのきっかけを 2024 年後半に観察された転換に求め、Claude 3.5 の第 2 版によって、長期にわたるエージェント型コーディングのワークフローがエラーではなく正しさを積み重ねるようになったと述べている。チームは 2025 年 7 月に、手書きのソフトウェアを作らないというルールのもとで結成された。したがって、この実践が前提としているのは、長期にわたって任せておけるほど信頼できるモデル世代と、禁止事項を安全なものにする前にチームが構築しなければならなかった二つのもの、すなわちエージェントから見えない検証と、その検証を安価かつ破壊的に実行できる環境である。
最もはっきりした限界は、述べられているコストである。エンジニア 1 人 1 日あたり少なくとも 1,000 ドルのトークンというのはチーム自身の基準であり、StrongDM の AI チームはコードを見ることすらせずに本格的なソフトウェアをどう構築しているか はこの数字を、この体制がそもそも一般化できるかどうかを決める条件として扱い、エンジニア 1 人あたり月におよそ 20,000 ドルになると見積もったうえで、その水準ではこれらのパターンはビジネスモデルの問題になると論じている。この実践が防ごうとしている失敗モードは、エージェントがユーザーを満足させることなく自分自身のテストを満たしてしまうことであり、そのために検証の成果物は、実装するエージェントの手が届かない場所に意図的に置かれている。
どれほど確立されたものかについて言えば、これは一つのチームの自己記述であり、彼ら自身によって公開され、その出所を明示したうえで紹介されたものであって、測定された結果でも、複数の独立した実践者を持つ慣行でもない。それが何を達成するかという主張は彼らのものである。問題のソフトウェアが接続されたサービス全体にわたるユーザー権限を管理していたこと、そしてセキュリティソフトウェアこそ、レビューされていないエージェントのコードで作られるとは最も考えにくいものであることは、紹介している著者が参加したデモについての彼の報告である。開発組織を工場として扱うという広い考え方はこのチームだけのものではなく（出典自体が、彼らが実践している導入レベルの命名者として Dan Shapiro を挙げている）、ファクトリーモデル で扱われている。この用語は、一つのチームによる、より狭い、名前の付いた実践を指す。
関連用語
ファクトリーモデル、デジタルツイン・ユニバース、レビューのボトルネック、エージェント型コードレビュー、仕様駆動開発、出力の検証可能性