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