工厂模型：编码智能体如何改变软件工程
摘要
软件工程不再是编写代码。而是构建生产你的软件的工厂。
最近智能体工程发生了一些变化，"感觉"像是抽象层次再次改变了。这不是工具变得稍微好一点、工作流程逐渐演进的那种常见转变，而是一次阶跃变化。那些编写软件几十年的开发者都在用同样的方式描述它：这门手艺的重心发生了转移。
现在你能做的最有用的事情是同时保持两个想法的张力。编码已经发生了巨大变化。但软件工程的核心并没有改变。这两者之间的差距就是有趣故事的所在，清楚地理解它是那些在这个时代蓬勃发展的工程师和那些被时代抛在后面的工程师之间的区别。
我读了 Michael Truell（Cursor 的）关于这个话题的想法，想对此进行扩展。
抽象的弧线
软件工程的历史就是提升抽象的历史。我们从比特到指令，从指令到函数，从函数到对象，从对象到服务，从服务到分布式系统。堆栈中的每一次跳跃都让单个开发者更有生产力，并扩大了能够参与构建软件的总人口。
汇编语言让位于 C 语言。C 语言让位于托管语言和垃圾回收。托管语言让位于框架、包生态系统和云基础设施。每次转变在当时都感觉具有颠覆性。事后看来，每一次都只是漫长而一致的弧线中的下一步。
我们现在正在经历的是同一弧线中的另一步。我们正在从编写代码转向编排编写代码的系统。
这个框架由 Grady Booch 阐述，他将其称为软件的第三个时代——一个由不断提升的抽象定义的新黄金时代，开发者的工作从编写指令转向定义意图。
这个框架很重要，因为它告诉你应该坚持什么、放弃什么。
精确描述这个进程很有帮助，因为混淆各代会导致低估实际发生的变化程度。
第一代是加速的自动补全。预测下一行、填充样板代码、在重复模式上节省按键的工具。有用。确实节省时间。但工作流程与以往完全相同：你驾驶，工具辅助。反馈循环是：编写代码、运行它、调试、重复。AI 只是减少了这个循环内的摩擦。
第二代引入了同步智能体。你用自然语言描述一个任务。模型生成代码。你审查它、纠正它、迭代到一个可行的结果。这进一步向上移动了堆栈。更少的打字，更多的描述意图。但你仍然在每一步都在场。智能体是一个协作者，而不是自主工作者。你持有上下文，指导下一步行动，并实时捕获错误。
第三代引入了自主智能体。这些智能体可以接受一个规范并运行三十分钟、一小时、几小时，甚至越来越多地运行几天。它们设置环境、安装依赖、编写测试、遇到失败、在线研究解决方案、修复失败、编写实现、再次测试、设置服务，并生成你可以审查的工件。你交给它们一个任务，转向其他事情，然后回来查看日志、预览和拉取请求。你不再逐行交互。你在定义结果并审查成果。这就是智能体群甚至自我改进智能体发挥作用的地方。
这以一种难以完全传达的方式改变了工作节奏，除非你亲身体验。三个月前还是周末项目的任务，现在是你启动后三十分钟再检查的事情。
工厂心智模型
这个新范式最有用的心智模型是，你不再只是编写代码。你在构建生产你的软件的工厂。
这个工厂由智能体舰队组成。每个智能体都有一个任务、一个工具箱（仓库、测试运行器、部署脚本、文档）、上下文（规范、架构决策、先前的约束）和一个反馈循环。你不再手把手地引导单个智能体完成单个任务，而是并行启动许多智能体。一个处理后端重构。另一个实现一个功能。另一个编写集成测试。另一个更新文档。你审查输出、给出反馈、完善规范并重新部署。
这个类比比最初看起来更深刻。工厂有质量控制。工厂有流程文档。工厂有需要精确指定的输入，否则输出就会出错。当环境不可靠时，工厂会停滞。所有这些属性都直接映射到智能体软件开发上，认真对待这个类比会指引你进行真正重要的投资。
在积极采用这种模型的团队内部，现在有相当一部分合并的拉取请求来自在云环境中自主运行的智能体。这不再是理论。对于越来越多的工程组织来说，这是生产现实。
Cursor 关于"开发者的工作正在变成构建生产软件的系统、工厂，而不仅仅是产品"和"审查想法比审查代码有趣得多"（视频）的观点与这些要点产生了共鸣。
这里有一个入职培训的平行
智能体实际行为中最引人注目的模式之一是，它们的工作循环与新工程师入职培训的相似程度。
你交给它们一个规范。它们将其分解为子任务。它们探索代码库以了解情况。当它们遇到困难时，它们搜索提交历史。它们运行 git blame 来找出谁最后接触了一个子系统。它们通过 Slack 或类似的通信渠道向适当的人类升级以获取领域知识，然后继续。它们迭代直到输出满足验收标准。
这个循环很熟悉，因为这就是人们的工作方式。其含义是重要的。Slack 和电子邮件正在成为人类和智能体之间的接口，而不仅仅是人类和人类之间的接口。Git 历史正在演变成智能体导航以理解架构决策的知识图谱。文档正在成为自主执行的培训材料。
如果你想清楚地思考现在应该在代码库中进行什么投资，问问自己：一个新工程师，仅凭可用的文档和提交历史，能否理解代码为什么以这种方式构建？如果答案是否定的，智能体也会在那里挣扎，你本可以获得的杠杆作用将受到限制。
你的规范就是杠杆
这是重塑你如何思考自己作为工程师价值的洞察。
如果你能编排二十、三十、五十个并行运行的智能体，平庸输出和卓越输出之间的差异几乎完全取决于你的规范质量。在这种规模下，模糊的思考不仅会拖慢你的速度。它会倍增。模糊的需求通过数十个并行自主运行传播，每个都以略微不同的方向略微出错。前期做出的糟糕架构决策不会影响一个实现。它们会在整个舰队中传播。
除非你深刻理解架构、集成边界、边缘情况、失败模式以及永远不能打破的不变量，否则你无法编写一个在该环境中存活的规范。规范不再是一个提示。规范是明确表达的产品思维。
这就是为什么强大的软件工程师从这些工具中获得的杠杆作用比弱者更多，而不是更少。输入代码的机械工作正在被自动化。理解系统的认知工作正在被放大。你现在花在发展真正的架构理解和系统思维上的每一个小时，都会在整个自主工作者舰队中产生红利，而不仅仅是你自己的输出。
什么没有真正改变
在这里精确一点是值得的，因为围绕 AI 编码的炒作可能会给人一种传统软件工程技能已被弃用的印象。
它们没有。考虑智能体开发仍然需要你做什么：
清晰的需求。如果你无法以可评估的方式阐明成功是什么样子，再多的自主执行也无法产生它。智能体无法澄清它们从未被给予的需求。它们会用假设填补空白，而这些假设会复合。
强大的抽象。给定一个设计良好的系统，具有清晰的模块边界、连贯的接口和良好的关注点分离，智能体将产生比给定一个纠缠的代码库（其中一切都依赖于其他一切）更好的结果。当智能体进行实现时，干净的架构不会变得不那么有价值。它变得更有价值，因为智能体放大了它们所工作系统的属性。
可靠的测试。这值得单独一节。
谨慎的权衡。智能体针对既定目标进行优化。它们不会自然地平衡竞争关注点、预测二阶效应或标记技术上正确的解决方案何时是错误的产品决策。这种判断仍然在你身上。
人工监督。智能体做出令人印象深刻的工作。它们也会犯自信的错误。输出质量足够高，可以通过随意审查，这意味着你的审查技能的标准实际上提高了，而不是降低了。
为什么测试比以往任何时候都重要
良好的测试和测试驱动开发（TDD）已经是良好的实践。在智能体工作流程中，它们变成了接近强制性的东西。
这个想法足够精确，值得清楚地陈述。红/绿 TDD 意味着你在编写实现之前编写测试。你确认测试失败（红色阶段）。然后你迭代实现，直到测试通过（绿色阶段）。这个序列不是可选的仪式。它是让你确信实现实际上在做你认为它在做的事情的机制。
对于编写代码的单个开发者，跳过测试优先开发的缺点是，你可能会编写一个无论你的实现是否正确都会通过的测试，或者错过后来作为回归被捕获的边缘情况。这些是真实的成本。它们是可管理的。
对于跨数十个并行任务生成代码的智能体舰队，成本会严重复合。为通过测试而优化的智能体会找到通过它们的方法。如果测试是在实现之后编写的，它们很可能在测试实现碰巧做什么，而不是它应该做什么。你现在有一个大面积的代码，其测试套件确认了错误的东西。全面的、测试优先的套件是你确保自主输出实际上正确并在代码库增长时保护现有功能的最有效杠杆。
"红/绿 TDD"是每个好模型都理解的简写。它捕获了一个特定的纪律：首先编写测试，在实现之前确认它们失败，通过正确的实现而不是通过玩弄测试来使它们通过。告诉智能体使用红/绿 TDD 是你在任务开始时可以给出的最高杠杆指令之一。
未解决的问题是验证，而不是生成
生成不再是瓶颈。验证才是。
智能体可以产生令人印象深刻的输出。挑战在于有信心地知道该输出是否正确。几个因素使这比最初看起来更难。
在更改之前通过的测试并不意味着它们会捕获更改引入的回归。智能体可以编写技术上有效但错过重要情况的测试。UI 验证仍然很脆弱，视觉和行为回归会溜过去，因为自动化工具还不够可靠，无法全部捕获它们。上下文窗口限制意味着在大型代码库上工作的智能体可能会错过存在于它们当前推理窗口之外的重要约束或模式。不稳定的环境，单个开发者遇到它作为一个烦人的边缘情况并解决它，当你有四十个智能体同时遇到同样的不稳定测试时，就会成为系统性阻塞。工厂停滞。
需要存在以大规模支持这种模型的基础设施包括更好的自动化回归检测、超越差异更改行的工件级验证、可靠和快速的环境配置，以及在并行工作负载下保持的护栏。这些是活跃的投资领域。它们还没有解决。
在验证赶上生成之前，人工审查不是可选的开销。它是安全系统。对令人印象深刻的智能体输出的适当响应不是因为它看起来不错就信任它。而是拥有架构理解和测试纪律来严格评估它。
高杠杆工程的新形态
在这个时代将产生最大影响的工程师不会因为他们打字有多快或他们记住语法有多好而与众不同。他们将因一组不同的能力而与众不同。
系统思维。在脑海中保持复杂架构、理解组件如何交互以及预测一个地方的更改如何影响其他地方行为的能力。这比打字速度更难发展，当你管理一个输出必须集成的智能体舰队时，它要有价值得多。
问题分解。知道如何将一个大的、模糊的目标分解为智能体可以可靠执行的范围明确的子任务。太大的任务往往会偏离轨道。范围不明确的任务会被错误解释。很好地分解问题，然后验证分解是否正确的技能是一门真正的手艺。
架构判断。理解为什么系统以这种方式设计、它正在优化什么属性以及做出了什么权衡。智能体可以实现。它们无法判断它们正在实现的是否是正确的设计。
规范清晰度。编写明确、相对于重要边缘情况完整且以使评估简单的方式构建的需求的能力。模糊的规范产生模糊的结果。精确的规范倍增为精确的实现。
输出评估。识别某些东西看起来正确但不正确、实现解决了既定问题但创建了新问题、解决方案的架构不适合系统其余部分的架构的品味。这种判断是不可自动化的。
编排技能。管理多个并行工作流、对智能体输出给出有效反馈、识别智能体何时需要重定向而不是重新分配任务，以及在自主工作者舰队中保持连贯性的实际能力。
这些都不完全是新技能。好的工程师一直需要它们。改变的是它们的相对重要性。软件开发的机械部分正在越来越多地由机器处理。认知部分正在被放大。
更大的图景是什么？
新网站创建同比增长 40%。新 iOS 应用增长近 50%。美国的 GitHub 代码推送跳升 35%。所有这些指标在 2024 年底之前多年持平。这些图表看起来像曲棍球棒。从未编写过一行代码的人正在构建和启动软件。
请记住，我们可以而且应该注意到，更多的数量不一定意味着更好的质量。但事实仍然是，创建软件的障碍已经大幅下降，这是软件工程格局的根本转变。
创建软件的障碍确实下降了。这不是炒作。对专业工程师来说，这意味着不是他们的技能不那么有价值，而是重要的技能已经向上移动了堆栈，就像在每次先前的转变中一样。
从汇编到 C 语言转变后蓬勃发展的开发者不是那些能编写最聪明汇编的人。他们是那些理解机器需要做什么并能在更高级语言中清楚地表达该意图的人。转向托管语言和框架后蓬勃发展的开发者不是那些最抵制垃圾回收的人。他们是那些将释放的认知能力视为解决更难问题的机会的人。
在智能体时代将蓬勃发展的开发者是那些将此理解为同一弧线中的另一步并相应投资的人。不是抵制工具。不是无批判地服从它们。而是发展判断力、清晰度和系统思维，使工具最大限度地有效。
这意味着编写更好的规范。投资测试基础设施。发展真正的架构理解而不是表面熟悉。建立严格评估输出的品味。练习问题分解，直到它成为第二天性。
编程主要作为按键活动的时代已经结束。编程主要作为思考和判断活动的时代已经加速了几十年，刚刚进入了更高的档位。
工厂模型不是关于失去对软件控制的隐喻。它是关于建立杠杆的隐喻。理解这一点的工程师将构建下一个十年最有趣的东西。