作者：Wes McKinney
译者：Carl Cui
作者 Wes McKinney 是专注于分析计算领域的工程师和创业者，
pandas的创始人，《Python for Data Analysis》的作者。曾创立 Voltron Data 和 Ursa Labs，现任 Posit 首席架构师。作者的这篇文章从《人月神话》的核心观点出发，讨论了 AI Agent 给软件工程所带来的影响。
和很多人一样，我发现 AI 严重影响了我的睡眠。以前我会在凌晨四点或四点半短暂醒来喝口水或上个厕所，现在却很难再次入睡。以前我每晚能睡七八个小时，现在能睡六个小时就不错了。我基本上已经不再抗争了：现在当我在早上 5:07 辗转反侧，脑子里全是喂给 AI coding agent 的想法时，我就直接起床开始新的一天。
在我的工程师和数据科学家朋友圈里，大家都在讨论我们作为人类的竞争优势还能持续多久。当 agent 开始自己产生更好的想法时，拥有好想法（而且要多）还重要吗？现在感觉，人类专家的参与是从 agent 那里获得良好结果的必要条件。那这种状态，直到某个想法在我们睡觉时可以被 agent 转化为能运行、有品味的软件之前，还能持续多久？这是否会是一种温和淘汰，让我们愉快地交出控制权，还是别的什么？
目前，我感觉自己还是被需要的。我不把自己现在这种工作方式描述为“vibe coding”，因为这听起来像是以一种贬义的“轻松搞定”的方式来构建 AI 垃圾软件项目。我一直在构建像 roborev 这样的工具，为我的并行 agent 会话带来严格性和持续监督，并对 agent 的工作进行严格审查。这种全新的工作方式让人不得不思考软件工程的未来。
我职业生涯中引用最多的书大概是 Fred Brooks 的《人月神话》，其中著名的 Brooks 定律认为“向一个已经延期的软件项目增加人手只会让它更晚”。最近我发现自己在思考这本书的教训是否适用于这个 agentic 开发的新时代。一个才华横溢的开发者指挥一群 AI agents，能否更快更好地构建复杂软件？短期的生产力提升是否会带来长期的项目成功？还是我们会遇到同样的问题？范围蔓延 scope creep、架构漂移 architectural drift 和沟通成本 coordination overhead，这些已经困扰软件团队几十年的问题。
1. 重读《人月神话》
Brooks 的核心论点之一是：少数精英组成的小团队胜过大量普通人组成的大团队。这能使得系统设计具有高度的概念完整性，就好像“一个人设计了它，即使是很多人参与了构建”。
Agentic 工程似乎放大了这些问题，因为其所构建软件的质量仅取决于参与其中的人类的水平：他们负责策划和完善 spec、对功能说“是或否”，以及控制不必要的代码和架构复杂性。《人月神话》中的一个比喻是“泥潭”：“每个人都能看到野兽在里面挣扎，看起来任何一只都能轻易逃脱，但泥潭把它们都困住了。”现在，我们有了一个新的“泥潭”，“agentic 泥潭”，我们的并行 Claude Code 会话和 git worktree 需要应付虚拟同事导致的代码膨胀和偶然复杂性。你可以系统地重构，但 agentic 代码库不可避免地会比任何人工构建的更大、更臃肿。这是前所未有的技术债务，以机器的速度累积。
在《人月神话》中，Brooks 观察到一个可运行的程序大概只完成了编程产品的九分之一，后者还需要必要的测试、文档、对边缘情况的加固，以及能被作者以外的人维护。Agent 现在让“可运行程序”（或者更准确地说，“看起来能运行的程序”）变得更加触手可及，许多新晋的 AI vibe coder 显然低估了从原型到生产所需的工作量。
当考虑到与此密切相关的 Conway 定律 时，这些问题会进一步复杂化。Conway 定律断言软件系统的架构往往反映组织的团队或沟通结构。当应用于一个没有持久记忆、对所构建系统也没有共同理解的虚拟 agent “团队”时，这会是什么样子？
《人月神话》中另一个让人印象深刻的观点是团队规模扩大时的 n(n-1)/2 协调问题。在 agentic 工程中，涉及的人类更少，所以协调问题并没有消失，而是改变了形态。不同的 agent 会话可能会产生相互矛盾的方案，需要人类来协调。我把这个 agent 编排问题留到另一篇文章再讨论。
2. 没有银弹
“无论是在技术上还是在管理技术上，都不存在单一的发展，能在十年内将生产力、可靠性或简洁性提高一个数量级。” —— 《没有银弹》（1986）
Brooks 写了一篇《人月神话》的后续文章，从本质复杂度和偶然复杂度的角度审视软件设计。本质复杂度是达成你目标的基础：如果你把系统再简化一点，它就达不到它的功能要求了。偶然复杂度是工具和流程强加给我们的其他一切：编程语言、工具，以及为了让工程师能看懂系统而加的设计和文档那层东西。
Coding agent 可能是有史以来为解决偶然复杂度而创造的最强大工具。想想看：我基本上不再手写代码了，现在却在用一门我从未用过的语言（Go）写了大量代码。现在很多人在讨论，再过一两年，IDE（集成开发环境）是否还有存在的必要，也许我们只需要一个文本编辑器来查看代码差异就行了。生产力的提升是巨大的，说这话，是因为我每个月在 Claude、Codex 和 Gemini 这几个平台上，会“烧掉”超过 100 亿 token。
但 Brooks “没有银弹”的论点恰恰预测了我在 agentic 工程中遇到的问题：偶然复杂度不再是问题，剩下的是本质复杂度，这一直是最难的部分。Agent 无法可靠地区分两者。LLM 是极其出色的模式匹配器，它们在人类所有开源软件上接受了训练，所以在处理偶然复杂性（重构代码、编写测试、清理屎山）方面非常出色，但在处理更微妙、更本质的设计问题上却很吃力，这些问题通常没有可以用来模式匹配的先例。它们还经常倾向于引入不必要的复杂性，生成大量在实际使用中很少需要的防御性样板代码。
换句话说，agent 太擅长处理偶然复杂度了，以至于它们会生成新的偶然复杂度，这反而妨碍了你试图构建的本质结构。在我的几个新项目 roborev 和 msgvault 中，我已经开始遇到这个问题。当项目开始接近 100K 行代码大关时，我观察到 agent 开始自行矛盾，被它们自己生成的臃肿代码库撑爆上下文。超过那个点之后（再往后的 100K 行，或者 200K 行），事情开始崩溃：每一个新的变更都必须穿过先前 agent 创建的代码丛林。我们称之为 “brownfield barrier”。在 Posit，我们看到 agent 在 Positron（一个 VSCode fork）这样超过百万行的代码库中挣扎得更厉害。这似乎验证了 Brooks 的复杂度扩展论点。
我不敢打赌现在是上限还是瓶颈期。模型显然正在迅速改进，我描述的这些问题在两年后可能看起来会显得天真可笑。但 Brooks 关于本质复杂度和偶然复杂度的讨论给了我一些信心，让我认为这不单单是当前的技术局限性。弄清楚该构建什么，在我们有 LLM 之前很久就是最难的部分，我看不出未来完美的 coding agent 如何改变这一点。
3. Agentic 范围蔓延
当生成代码的成本为零，知道何时说“不”是你最后的防线。
随着生成代码的成本现在趋近于零，几乎没有什么能阻止 agent 和它们的人类主人追求所有以前因成本或时间而无法实现的事情。整天让你不断提示“现在你能……吗？”的诱惑是难以抵挡的。但是，任何新生成的功能或子系统，虽然创建起来很便宜，但在未来维护、测试、调试和思考它们时并不是没有成本的。现在看起来免费的东西，对未来的 agent 会话会带来上下文负担，每一个新的功能或特性都可能成为新脆弱点或错误来源，进而影响到用户。
从这个角度来看，构建优秀软件项目也许从来就不是关于你能多快产出代码。我们用 agent 打代码的速度比以前快了 10 倍，也许 100 倍。但我们仍然要做出好的设计决策，对大多数想法说不，保持概念上的完整性，并知道什么时候某件事算是“完成了”。Agent 在加速“容易的部分”，同时可能矛盾地让“困难的部分”变得更加困难。
Agentic 范围蔓延似乎正在破坏开源软件世界。现在贡献者跳进来提供帮助的门槛比以往任何时候都低，项目正在被 3000 行“有帮助的” PR 洪流淹没，这些 PR 添加了新功能。随着开发者越来越脱离设计和规划过程，agent 的范围蔓延可能很快就会失控。当提交 pull request 的人没有写过或完整读过所提交的代码时，很可能没有任何人真正对设计决策负责。
我在自己的 roborev 和 msgvault 工作中看到，当一个简单的解决方案就足够好时，agent 会提出过度设计的方案。知道何时介入以及如何让 agent 保持克制，需要判断力。
4. 设计与品味是我们最后的立足点
Brooks 的论点是：设计才能和好品味是最稀缺的资源。现在有 agent 承担了所有的编码劳动，我认为这些稀缺资源比以往任何时候都更重要。瓶颈从来不是手放在键盘上。现在有了新的“神话般的 Agent 月”，我们可以合理地得出结论：设计、产品范围界定和品味仍然是交付高质量软件的实际约束。
在这个新的、强调主动性的时代里，能取得成功的开发者不会是那些运行最多并行会话或烧掉最多 token 的人。而是那些能够将项目的概念模型牢记于心的人，他们精明地知道该构建什么、该舍弃什么，并且能在庞大的产出量面前，运用自己的品味进行判断。
《人月神话》出版于 1975 年，距今已经过去五十多年了。在这段时间里，发生了很多事：硬件性能有了巨大的进步，编程语言、开发环境、云计算，现在还有大型语言模型。工具变了，但约束还是一样的。
也许我只是在为自己的持续价值找借口，但现实比这要复杂得多。不是所有软件都是平等的：CRUD 业务生产力应用和数据库及其他关键系统软件不一样。我认为普通的软件咨询公司已经完全完蛋了。不过我的论点更多是关于分布在尾部那 1% 的开发工作：这些问题对于大多数工程师来说是无法解决的。这将继续需要专家的介入，即使他们不再做太多或任何手动编码。作为一个最近的相关例子，我在 OpenAI 的朋友 Alex Lupsasca 和他的世界级物理学家合作者，能够在 AI 的帮助下对一个困难的物理问题进行建模并找到解决方案。如果没有这样的专家介入，LLM 是否能够既提出问题又找到解决方案，那就不好说了。
目前来说，我可能还得继续在早上五点起床，照顾和训练我的 agent，这还得持续一段时间。现在写代码容易多了，也确实更有趣，我可以把时间花在思考要做什么，而不是跟工程过程里的工具和系统较劲。
感谢 Martin Blais、Josh Bloom、Phillip Cloud、Jacques Nadeau 和 Dan Shapiro 对本文草稿提出的反馈。