Poge
私たちはソフトウェアファクトリーを構築しました。仕様とシナリオがAIエージェントを駆動し、コードを書き、テストを実行し、人間のレビューなしに収束する——非対話型開発の実現です。
以下にその物語を記します。第一原理から考えたい方のために、繰り返し適用することで同じ直感、確信1、そして最終的にはあなた自身のファクトリー2へと加速させる制約とガイドラインを提示します。公案あるいはマントラの形式で：
ルールの形式で：
実践的な形式で：
2025年7月、私たちはPogeチームを立ち上げました。
きっかけは2024年後半に観察された転換点でした。Claude 3.5の第二リビジョン（2024年10月）により、長期的なエージェント型コーディングワークフローが、エラーではなく正しさを複利的に積み上げるようになったのです。
2024年12月までに、モデルの長期的コーディング性能はCursorのYOLOモードを通じて明白になりました。
このモデル改善以前は、LLMをコーディングタスクに反復適用すると、あらゆる種類のエラー（誤解、ハルシネーション、構文エラー、DRY違反、ライブラリ非互換など）が蓄積していきました。アプリやプロダクトは劣化し、最終的には「崩壊」する——千の切り傷による死、といった具合です。
YOLOモードとAnthropicの更新されたモデルにより、私たちが内部で非対話型開発あるいは育成されたソフトウェアと呼ぶものの最初の兆しが見えました。
AIチーム初日の最初の1時間で、私たちは一連の発見（内部では「アンロック」と呼んでいます）への道を定める憲章を制定しました。振り返ってみると、その憲章文書で最も重要な一行は次のものでした：
手で書くな！
最初はただの勘でした。実験です。手でコードを一切書かずに、どこまで行けるか？
あまり遠くまでは行けませんでした！少なくとも、テストを追加するまでは。しかし、目の前のタスクに執着するエージェントは、すぐにショートカットを取り始めました：return trueは狭く書かれたテストをパスする素晴らしい方法ですが、あなたが望むソフトウェアには汎化しないでしょう。
テストだけでは不十分でした。インテグレーションテストは？リグレッションテストは？E2Eテストは？ビヘイビアテストは？
エージェントの時代に繰り返し現れるテーマ：新しい言葉が必要です。例えば、「テスト」という言葉は不十分で曖昧であることが証明されました。コードベースに保存されたテストは、コードに合わせて怠惰に書き換えられる可能性があります。コードもテストを簡単にパスするように書き換えられる可能性があります。
私たちはシナリオという言葉を再定義し、エンドツーエンドの「ユーザーストーリー」を表すために使用しました。これはコードベースの外部に保存されることが多く（モデル学習の「ホールドアウト」セットに似ています）、LLMによって直感的に理解され、柔軟に検証できるものです。
私たちが育成するソフトウェアの多くは、それ自体がエージェント的なコンポーネントを持っているため、成功のブール型定義（「テストスイートがグリーン」）から確率的・経験的なものへと移行しました。この検証を定量化するために満足度という用語を使用しています：すべてのシナリオを通過するすべての観測された軌跡のうち、ユーザーを満足させる可能性のある割合はどれくらいか？
以前のレジームでは、チームはインテグレーションテスト、リグレッションテスト、UIオートメーションに頼って「動いているか？」に答えていたかもしれません。
私たちは以前は信頼できたテクニックの2つの限界に気づきました：
1. テストは硬直的すぎる - 私たちはエージェントでコーディングしていますが、LLMとエージェントループを設計プリミティブとして構築もしています；成功の評価にはしばしばLLM-as-judgeが必要でした
2. テストはリワードハックされうる - モデルのチートに対してより脆弱でない検証が必要でした
デジタルツイン・ユニバースが私たちの答えです：ソフトウェアが依存するサードパーティサービスの行動クローンです。私たちはOkta、Jira、Slack、Google Docs、Google Drive、Google Sheetsのツインを構築し、それらのAPI、エッジケース、観測可能な動作を複製しました。
DTUにより、本番環境の制限をはるかに超えるボリュームとレートで検証できます。ライブサービスに対しては危険または不可能な障害モードをテストできます。レート制限に達することなく、不正利用検知をトリガーすることなく、APIコストを蓄積することなく、1時間に数千のシナリオを実行できます。
DTUでの成功は、エージェントの時代がソフトウェアの経済学を根本的に変えた多くの方法の1つを示しています。重要なSaaSアプリケーションの高忠実度クローンを作成することは常に可能でしたが、経済的に実現可能ではありませんでした。何世代ものエンジニアがCRMの完全なインメモリレプリカをテスト用に欲しかったかもしれませんが、構築提案を自己検閲していました。答えがノーになることを知っていたので、マネージャーに持っていくことさえしなかったのです。
ソフトウェアファクトリーを構築する私たちは、意図的なナイーブさを実践しなければなりません：Software 1.0の習慣、慣習、制約を見つけて取り除くことです。DTUは、6ヶ月前には考えられなかったことが今やルーチンであることの私たちの証明です。
お読みいただきありがとうございます。あなた自身のソフトウェアファクトリー構築の幸運をお祈りします。
1 この確信を持っているのは私たちだけではありません。参照：Luke PMの"The Software Factory"、Sam Schillaceの"I Have Seen the Compounding Teams"、Dan Shapiroの"Five Levels from Spicy Autocomplete to the Software Factory"
2 他にもファクトリーを構築している人々がいます：Devin、8090、Factory、Superconductorなど