StrongDM 软件工厂
内容
我们建立了一个软件工厂：非交互式开发，规格和场景驱动代理编写代码、运行测试框架，并在没有人工审查的情况下收敛。
以下是叙事形式的内容。如果您更愿意从第一原则开始，我提供了一些约束和指南，这些约束和指南通过迭代应用，将加速任何团队走向相同的直觉、信念1和最终拥有自己的工厂2。以公案或咒语的形式：
- 我为什么要做这件事？（意味着：模型应该做这件事）
以规则形式：
- 代码不能由人类编写
- 代码不能由人类审查
最后，以实用形式：
- 如果您每天没有为每个人类工程师花费至少 1,000 美元的令牌，那么您的软件工厂还有改进的空间
StrongDM AI 故事
2025 年 7 月 14 日，Jay Taylor 和 Navan Chauhan 加入我（Justin McCarthy，联合创始人，CTO）共同创立了 StrongDM AI 团队。
催化剂是 2024 年末观察到的转变：随着 Claude 3.5 的第二个修订版（2024 年 10 月），长视野的代理编码工作流开始复合正确性而不是错误。
复合正确性与复合错误
到 2024 年 12 月，模型的长视野编码性能通过 Cursor 的 YOLO 模式变得无可置疑。
在此模型改进之前，迭代地将大型语言模型（LLMs）应用于编码任务将会积累各种错误（误解、幻觉、语法、DRY 违规、库不兼容等）。应用程序或产品将会衰退并最终“崩溃”：死于千刀之伤等。
与 YOLO 模式一起，来自 Anthropic 的更新模型为我们提供了现在内部称为非交互式开发或生长软件的第一丝曙光。
找到旋钮，转到 11
“这些旋钮可以转到 11”
在我们 AI 团队的第一个小时，我们建立了一个章程，这使我们走上了发现的道路（我们称之为“解锁”）。回顾过去，章程文件中最重要的一行是：
放手！
最初这只是一个直觉。一个实验。我们可以走多远，不需要手动编写任何代码？
没走多远！至少：没走多远，直到我们添加了测试。然而，代理被眼前任务所困扰，很快开始走捷径：返回 true 是通过狭义测试的好方法，但可能不会推广到您想要的软件。
测试是不够的。怎么样集成测试？回归测试？端到端测试？行为测试？
从测试到场景和满意度
代理时刻的一个反复出现的主题：我们需要新的语言。例如，“测试”这个词已经被证明是不够和模糊的。存储在代码库中的测试可以被懒惰地重写以匹配代码。代码可以被重写以轻松通过测试。
我们重新使用了场景这个词来表示端到端的“用户故事”，通常存储在代码库之外（类似于模型训练中的“holdout”集），可以被大型语言模型直观地理解和灵活地验证。
合成场景策划和塑形界面
因为我们生长的软件中有很大一部分具有代理组件，我们从布尔定义的成功（“测试套件是绿色的”）转变为概率和经验定义。我们使用满意度这个术语来量化这种验证：在所有观察到的轨迹中，通过所有场景，有什么比例可能满足用户？
在数字孪生宇宙中验证场景
在以前的政权中，团队可能依赖集成测试、回归测试、UI 自动化来回答“它是否有效？”
我们注意到以前可靠的技术有两个局限性：
- 测试太僵化 —— 我们正在使用代理编码，但我们也正在使用大型语言模型和代理循环作为设计原语；评估成功通常需要大型语言模型作为法官
- 测试可以被奖励黑客攻击 —— 我们需要一种不容易被模型欺骗的验证
数字孪生宇宙（Digital Twin Universe，DTU）是我们的答案：我们依赖的第三方服务的行为克隆。我们为 Okta、Jira、Slack、Google Docs、Google Drive 和 Google Sheets 构建了孪生体，复制了它们的 API、边缘情况和可观察行为。
使用 DTU，我们可以以远超生产限制的体积和速率进行验证。我们可以测试对实时服务来说危险或不可能的故障模式。我们可以在不触发速率限制、触发滥用检测或积累 API 成本的情况下每小时运行数千个场景。 数字孪生宇宙：Okta、Jira、Google Docs、Slack、Drive 和 Sheets 的行为克隆（点击放大）
非传统经济学
我们在 DTU 上的成功说明了代理时刻如何深刻地改变了软件的经济学。创建一个重要的 SaaS 应用的高保真克隆一直是可能的，但从来没有经济上可行。几代工程师可能想要一个完整的内存中 CRM 副本来测试，但他们自我审查了提议的构建。他们甚至没有把它带给他们的经理，因为他们知道答案会是不会。
我们这些建立软件工厂的人必须练习故意的天真：找到并删除软件 1.0 的习惯、惯例和约束Software 1.0。DTU 是我们的证明：六个月前不可思议的事情现在已经成为常规。
下一步阅读
感谢您的阅读。我们祝您在构建自己的软件工厂中好运。