Agent 时代软件工厂范式的重新定义
分析 AI agent 对软件工厂和开发流程的深层影响,探讨 agent 驱动的工程范式演进方向。
分析 AI agent 对软件工厂和开发流程的深层影响,探讨 agent 驱动的工程范式演进方向。
我们构建了一个软件工厂:非交互式开发,其中规范和场景驱动代理编写代码、运行测试套件,并在无需人工审查的情况下收敛。
下面提供了叙述形式。如果你更喜欢从第一原理出发,我提供一些约束条件和指南,通过迭代应用,将任何团队加速推向相同的直觉、信念,最终拥有自己的工厂。以公案或咒语的形式:
为什么我要做这件事?(隐含意思:模型应该代替我做这件事)
代码不应该由人类编写
代码不应该由人类审查
最后,以实践形式:
如果你今天还没有为每个人类工程师花费至少 1,000 美元的 token,你的软件工厂还有改进的空间
2025 年 7 月 14 日,Jay Taylor 和 Navan Chauhan 与我(Justin McCarthy,联合创始人兼 CTO)共同创立了 StrongDM AI 团队。
催化剂是在 2024 年末观察到的一个转变:随着 Claude 3.5 的第二个修订版(2024 年 10 月),长时域代理编码工作流开始累积正确性而不是错误。
到 2024 年 12 月,通过 Cursor 的 YOLO 模式,该模型的长时域编码性能是无可否认的。
在模型改进之前,迭代应用 LLM 到编码任务会积累各种可想象的错误(误解、幻觉、语法、DRY 违规、库兼容性等)。应用或产品会衰退并最终"崩溃":千刀万剐之死等。
与 YOLO 模式一起,Anthropic 更新的模型提供了我们内部称为非交互式开发或成长型软件的第一线曙光。
在我们 AI 团队第一天的第一个小时,我们制定了一份章程,为我们指引了一系列发现的道路(我们称之为"解锁")。回过头来看,章程文件中最重要的一行是以下内容:
最初,这只是一个直觉。一个实验。在不手工编写任何代码的情况下,我们能走多远?
不会很远!至少:不会很远,直到我们添加了测试。然而,专注于当前任务的代理很快开始采取捷径:返回 true 是通过狭隘编写的测试的好方法,但可能不会推广到你想要的软件。
测试还不够。那集成测试呢?回归测试?端到端测试?行为测试?
代理时刻的一个反复出现的主题:我们需要新的语言。例如,"测试"这个词已被证明是不充分和模糊的。存储在代码库中的测试可以懒惰地重写以匹配代码。代码可以重写为轻松通过测试。
我们重新利用"场景"一词来代表端到端的"用户故事",通常存储在代码库之外(类似于模型训练中的"holdout"集),可以由 LLM 直观理解和灵活验证。
因为我们开发的大部分软件本身都有代理组件,我们从布尔定义的成功("测试套件是绿色的")过渡到概率和经验性的定义。我们使用"满意度"一词来量化这个验证:在所有场景中观察到的所有轨迹中,其中有多大比例可能满足用户?
在以前的时代,团队可能会依靠集成测试、回归测试、UI 自动化来回答"它是否在工作?"
我们注意到以前可靠技术的两个局限:
数字孪生宇宙是我们的答案:我们软件依赖的第三方服务的行为克隆。我们构建了 Okta、Jira、Slack、Google Docs、Google Drive 和 Google Sheets 的孪生体,复制了它们的 API、边界情况和可观察行为。
借助 DTU,我们可以以远远超过生产限制的体积和速率进行验证。我们可以测试针对实时服务来说危险或不可能的故障模式。我们可以每小时运行数千个场景,而不会触及速率限制、触发滥用检测或累积 API 成本。
我们在 DTU 上的成功说明了代理时刻在众多方面深刻改变了软件经济学的其中之一。创建一个重要 SaaS 应用的高保真克隆一直都是可能的,但从经济上来讲从不可行的。几代工程师可能都想要一个完整的内存 CRM 副本来测试,但自我审查了构建它的提议。他们甚至没有把它带给他们的经理,因为他们知道答案会是否定的。
我们这些构建软件工厂的人必须实践一种刻意的天真:发现和消除软件 1.0 的习惯、惯例和约束。DTU 是我们的证明,六个月前不可想象的东西现在已成为日常。
感谢你的阅读。祝你在构建自己的软件工厂时好运。
¹ 在这些信念上我们并不孤单。另请参见:Luke PM 的《软件工厂》、Sam Schillace 的《我见证了复合团队》和 Dan Shapiro 的《从 Spicy 自动完成到软件工厂的五个级别》。
² 其他人也在构建工厂:Devin、8090、Factory、Superconductor 和 Jesse Vincent 的 Superpowers。