この記事は、StrongDM の AI チームが自分たちの働き方について初めて公に説明したものを紹介し、それに反応したものである。著者はその数か月前にデモを見ていた。チームが ソフトウェアファクトリー と呼ぶこの体制は、チーム自身のルールを引用する形で要約されており、著者はそのうちの 1 つを群を抜いて興味深いものとして取り上げる。それは、コードは人間がレビューしてはならないというルールである。著者が立てる問いは、LLM が人間ならしないような誤りをどれほど犯しやすいかを考えれば、それがいったいどうして理にかなった戦略になりうるのか、というものである。
記事の大部分はその問いへの答えであり、著者はそれをソフトウェア開発全般にとって重大な問いとして扱う。すなわち、実装とテストの両方をコーディングエージェントが書いてくれるとき、ソフトウェアが動作することをどう証明できるのか。エージェントにテストを書かせることは、エージェントがズルをしない限りにおいてしか役に立たない。その答えは、情報源がシナリオテストに着想を得たと説明するものであり、チームは「シナリオ」という語を独自に転用して、しばしばコードベースの外部に置かれるエンドツーエンドのユーザーストーリーを指すものとしている。著者はチームと同じく、これをモデル訓練におけるホールドアウトセットになぞらえている。そして成功をブール値として捉える考え方を、チームが「満足度（satisfaction）」と呼ぶ確率的な考え方に置き換える。著者はホールドアウトとしてのシナリオというアイデアを魅力的だと評し、それを外部の QA チームによる徹底的なテストを模倣するものと読んでいる。
著者が最も感銘を受けたのは デジタルツイン・ユニバース である。これはソフトウェアが依存するサードパーティのサービスを、エージェントが振る舞いのレベルで複製したクローンであり、チームはこれによってレート制限や API コストなしに 1 時間あたり数千のシナリオを実行できる。著者は、この方法で構築されているソフトウェアが、接続された複数のサービスにわたってユーザーのパーミッションを管理するものであることに触れている。それはセキュリティソフトウェアであり、レビューされていない LLM のコードから構築されるとは最も予想しにくいものだと著者は言う。記事は、当初は軽く流していた数字で締めくくられる。エンジニア 1 人あたり 1 日に少なくとも 1,000 ドル分のトークンという、チームが掲げる基準である。著者はそれを、このすべてが一般化できるかどうかを決める項として扱い、エンジニア 1 人あたり月におよそ 20,000 ドルとなれば、これらのパターンはエンジニアリングの問題ではなくビジネスモデルの問題になると述べ、はるかに少ない費用で実践に移せるようになることを望むとしている。
要点
- チームが掲げるルールは 3 つの形で引用されている。1 つの問い（「なぜ自分がこれをやっているのか？」、つまり代わりにモデルがやるべきだという含意）、2 つの禁止事項（コードは人間が書いてはならない、コードは人間がレビューしてはならない）、そして人間のエンジニア 1 人あたり 1 日に少なくとも 1,000 ドル分のトークンという支出の基準である。
- 著者はそのうち「コードは人間がレビューしてはならない」を、LLM が人間ならしないような誤りをどれほど犯しやすいかを考えると、最も興味深く、かつ最も受け入れがたいものとしている。
- 記事が現在のソフトウェア開発において最も重大だとする問いは、実装とテストの両方をエージェントが書くとき、ソフトウェアが動作することをどう証明するかである。エージェントが書いたテストは、エージェントがズルをしない限りにおいてしか役に立たないからである。
- チームは、創設のきっかけを 2024 年後半に観察された転換にさかのぼらせている。Claude 3.5 の第 2 版によって、長期にわたるエージェント型コーディングのワークフローが誤りではなく正しさを積み上げ始めたと述べている。これはチーム自身による自らの歴史の説明であり、記事はそれを引用している。
- チームは 2025 年 7 月に、手書きのソフトウェアを作らないというルールのもとで創設された。著者はこれをその時期としては過激なものと評する一方で、2026 年 1 月ごろには経験豊富な開発者がかなりの数でそれを採用し始めたと報告している。
- 著者はこれとは別に、2025 年 11 月に広く認められた転換点があったことにも触れている。Claude Opus 4.5 と GPT 5.2 によって、コーディングエージェントがどれだけ確実に指示に従い、複雑なタスクを引き受けられるかという点で潮目が変わったように見えたというものである。これは著者自身の捉え方であり、チームの言う 2024 年のきっかけとは別のものである。
- チームの用法における「シナリオ」とは、しばしばコードベースの外部に保存されるエンドツーエンドのユーザーストーリーであり、LLM が直感的に理解し柔軟に検証できるものである。それをコードベースの外に置くことでコーディングエージェントから見えない場所に置くことになる、というのは紹介する側の著者による解釈であり、チームが述べた理由ではない。
- 「満足度」は、検証を確率的に測る尺度を指すチームの用語である。すべてのシナリオを通じて観察されたすべての軌跡のうち、ユーザーを満足させる可能性が高いものの割合を表す。チームが育てているソフトウェアの多くにはエージェント的な要素があるため、ブール値の成功は形として合わないという理由で採用された。
- 著者は、エージェントが読めない場所にシナリオを置くことを、外部の QA チームによる徹底的なテストを模倣するものとして提示している。これは従来のソフトウェアにおいて、高価ではあるが非常に効果的な品質確保の仕組みである。
- デジタルツイン・ユニバースは、チームによってサードパーティの依存先を振る舞いのレベルで複製したクローンと説明されている。API、エッジケース、観察可能な振る舞いを再現するものであり、Okta、Jira、Slack、Google Docs、Google Drive、Google Sheets のツインが構築されている。
- チームがツインを作る理由として挙げるのは、本番環境の上限をはるかに超える量と頻度での検証、実際のサービスに対して行うと危険または不可能な障害モードのテスト、そしてレート制限、不正利用の検知、API コストなしに 1 時間あたり数千のシナリオを実行できることである。
- 著者の理解によれば、ツインはあるサービスの公開 API ドキュメント全体をチームのエージェントハーネスに投入し、自己完結した Go バイナリとして模倣品を生成させることで構築され、その上に簡略化された UI が生成される。
- 記事に追記された更新では、ツインの作成者が再現可能な忠実度の戦略を述べていることが伝えられている。それは、そのサービスで広く使われている公開リファレンス SDK のクライアントライブラリを、ツインを構築する際の互換性の目標として扱い、常に完全な互換性を目指すというものである。
- チームは、重要な SaaS アプリケーションの高忠実度なクローンはこれまでも常に可能ではあったが、経済的に見合うことはなかったと主張する。そして、それを欲しいと思ったエンジニアは、歴史的にその構築の提案を自己検閲してきたという。
- この体制のもとで構築されているソフトウェアは、接続された一連のサービスにわたってユーザーのパーミッションを管理するものである。著者はこれを注目すべき点として挙げる。セキュリティソフトウェアは、レビューされていない LLM のコードから構築されるとは最も予想しにくいものだからである。
- この記事にあわせて 2 つのリリースが行われた。リポジトリにコードをまったく含まない Attractor と、約 16,000 行の Rust、9,500 行の Go、6,700 行の TypeScript からなる従来型のリリースである cxdb である。
- チーム自身のテクニック紹介ページから、名前の付いた手法がさらに 3 つ紹介されている。エージェントに既存システムからパターンを抽出させて他の場所で再利用させる gene transfusion、言語間でコードを直接移植する semports、そしてエージェントが安価に走査したうえで詳細に踏み込める階層的な要約である pyramid summaries である。これらのページの詳細はチームによるものであり、ここで確立されたものではない。
- コストに関する著者の判断は明確である。これらのパターンがエンジニア 1 人あたり月におよそ 20,000 ドルを上乗せするのであれば、著者にとってははるかに興味の薄いものとなり、プロダクトラインがそのオーバーヘッドを負担できるかどうかの問題になるという。
- 著者は同じ能力がもたらす第 2 の帰結にも触れている。どの競合も数時間のコーディングエージェントの作業で新機能を複製できるようになると、持続可能なソフトウェアビジネスのあり方は違って見えてくるというものである。
- 著者は、月額 200 ドルのサブスクリプションでエージェントのパターンを試す余地は得られているが、シミュレートされた QA テスターの群れを常時動かしているわけではないと報告している。
背景
この記事は、公開の数か月前に著者が参加したデモへの直接の反応と、チーム自身による初の公開の説明とを組み合わせたものであり、その二重の足場について率直である。デジタルツインの仕組みは「私が理解した限りでは」として示されており、チームのきっかけや成果に関する引用された主張は、検証されたものではなく伝えられたものである。著者の姿勢は、確信しているというより関心を持っているというものである。著者はこの体制を、エンジニアがコードを構築する立場から、コードを構築するシステムを構築し半ば監視する立場へと移る、ありうる未来の 1 つの垣間見と呼ぶ。そして、自分が最も関心を寄せていると言うもの、すなわち人間がすべての行を読むことなくエージェントに自らのコードが動作することを証明させるには何が必要か、という点に 2 度立ち戻る。また、当初はトークンの支出を軽く扱っていたが、それを真剣に取り上げるよう記事を改訂したことも記録している。開発組織をファクトリーとして捉えるより広い枠組みは、それ自体が別の主題として扱われており（ファクトリーモデル を参照）、記事が軸とするレビューの問題は レビューのボトルネック と エージェント型コードレビュー の主題である。