我们构建了一个软件工厂：非交互式开发，其中规格+场景驱动代理编写代码、运行测试套件，并在无需人工审核的情况下收敛。

叙事形式如下。如果你希望从基础原理出发，我提供一些约束与指南，通过迭代应用，将加速任何团队形成相同的直觉、信念，最终建立属于你自己的软件工厂。

以禅宗公案或咒语的形式表达：

• • 我为什么要这样做？（言下之意：模型应该代替我做这件事）

以规则的形式表达：

• • 代码不得由人类编写
• • 代码不得由人类审查

以实际操作的形式表达：

• • 如果您今天每位工程师在代币上的花费不足 1000 美元，那么您的软件工厂还有改进空间。

StrongDM AI 的故事

2025 年 7 月 14 日，杰伊·泰勒和纳万·乔汉加入了我和（联合创始人、首席技术官贾斯汀·麦卡锡）共同创立了 StrongDM AI 团队。

催化剂是 2024 年末观察到的一个转变：随着 Claude 3.5 的第二次修订（2024 年 10 月），长时程代理式编码工作流程开始累积正确性而不是错误。

到 2024 年 12 月，通过 Cursor 的 YOLO 模式，模型的长时程编码性能显而易见。

在此模型改进之前，将 LLMs 迭代应用于编码任务会累积各种可想象的错误（误解、幻觉、语法错误、版本 DRY 违规、库不兼容等）。应用程序或产品会逐渐衰败并最终“崩溃”：千疮百孔，等等。

与 YOLO 模式一起，Anthropic 提供的更新模型首次展现了我们现在内部称之为非交互式开发自生长软件的曙光。

找到旋钮，调到最大

在我们 AI 团队成立的第一天，第一个小时，我们制定了一份章程，它为我们指明了通往一系列发现（我们称之为“解锁”）的道路。回顾起来，章程文件中最重要的一行是以下这句话：

最初这只是一个直觉。一个实验。在不手动编写任何代码的情况下，我们能走多远？

不远！至少：在添加测试之前不远。然而，代理程序沉迷于立即的任务，很快就开始走捷径：return true 是通过狭窄编写的测试的好方法，但可能不会推广到你想要的软件。

测试还不够充分。那么集成测试呢？回归测试呢？端到端测试呢？行为测试呢？

从测试到场景和满意度

代理时刻的一个反复出现的主题：我们需要新的语言。例如，"测试"这个词已被证明是不充分且模糊的。存储在代码库中的测试可以被懒惰地重写以匹配代码。代码可以被重写以轻易地通过测试。

我们将"scenario"这个词重新定义为表示一个端到端的"用户故事"，通常存储在代码库之外（类似于模型训练中的"holdout"集），并且可以被 LLM 直观地理解和灵活地验证。

由于我们开发的大部分软件本身就包含代理组件，我们已从成功的布尔定义（"测试套件是绿色的"）过渡到概率性和经验性的定义。我们使用满意度一词来量化这种验证：在所有场景中观察到的所有轨迹中，有多少比例可能满足用户？

在数字孪生宇宙中验证场景

在之前的体系中，一个团队可能依赖集成测试、回归测试、UI 自动化来回答"它是否在运行？"

我们注意到先前可靠技术的两个局限性：

• • 测试过于僵化——我们曾用代理进行编码，但现在我们也在使用 LLMs 和代理循环作为设计基础；评估成功通常需要将 LLM 作为裁判
• • 测试可能被奖励黑客攻击——我们需要一种对模型作弊的验证方式，这种方式不太容易受到漏洞的影响

数字孪生宇宙是我们的答案：我们软件所依赖的第三方服务的可行为克隆。我们创建了 Okta、Jira、Slack、Google Docs、Google Drive 和 Google Sheets 的孪生体，复制了它们的 API、边缘案例和可观察行为。

借助 DTU，我们可以在超出生产极限的规模和速率下进行验证。我们可以测试对实际服务来说危险或不可能的故障模式。我们可以在每小时运行数千个场景，而不会触发速率限制、滥用检测或累积 API 成本。

非传统经济学

DTU 的成功案例说明了代理时刻如何深刻改变了软件的经济性。创建一个高保真度的 SaaS 应用克隆一直可能，但从未具有经济可行性。几代工程师可能都希望有一个完整的内存中 CRM 副本用于测试，但他们自我审查了建设它的提议。他们甚至没有向经理提出，因为他们知道答案会是“不行”。

我们这些构建软件工厂的人必须实践一种有意的天真：寻找并消除软件 1.0 的习惯、惯例和限制。DTU 就是我们的证明，六个月前还不可想象的事情，如今已成为常规。

https://factory.strongdm.ai/