夜雨聆风一个 5 人团队 + 100 个 AI 编程 Agent 并行工作，每天产生 500 次提交、200 次推送、100 个 PR。Uber 那套几千个微服务的架构，当年看着极端，现在可能是标配。
引言
上周和一个创业者聊天，他说他们团队只有 5 个工程师，所以是"小团队"。
我笑了笑没接话。因为他用 Cursor + Claude Code 这些 AI 编程工具，Git 仓库里跑着至少 20 个 AI Agent 在并行改代码。这哪是小团队？这是在用 10 倍的并行度干活——软件工程的效率逻辑已经彻底变了。
Jacob Gold 最近写了一篇短文，抛出一个让人没法忽视的观点：AI 时代没有真正的"小团队"了。 不是因为小团队不存在，而是因为——有了 AI Agent 之后，"小"和"大"的边界已经彻底被打破了。
从 50 次提交到 500 次——发生了什么？
Uber 的几千个微服务曾经被当作过度工程的典型案例。为什么搞这么多？因为几百个工程师都想自己安排部署、自己拥有代码的所有权，而不是在一个巨大的合并队列里排队等待。
以前，5 到 10 个人一起写代码根本不需要考虑这些。一个普通工作日的代码量大概是：50 次提交、20 次推送、10 个 PR。
但现在呢？同样这几个人，跑着 20-100 个 AI Agent 并行干活。产出变成了：500 次提交、200 次推送、100 个 PR。 工作量级直接翻了 10 倍。
一个开发者，从"单线程"写代码（一次改一个文件），变成了"多线程"写代码（和几十个 Agent 同时推进不同功能）。这不是量变，是质变。
代码模块化决定你最多能并行到什么程度
这不是简单的"多雇几个 AI 工具干活"的问题。背后有一个硬约束：代码的模块化程度决定了你能跑多少个 Agent。
如果你是一个巨型单体仓库，每次改动都要小心翼翼协调，两个并行的工作大概率会互相踩脚。结果就是天天解 merge conflict、重构代码、折腾部署——工作效率可能反而是负数。
而如果你像 Uber 那样把系统拆成几千个微服务，你就拥有了一种"尴尬的并行"能力——每个微服务相对独立，扔一个 Agent 进去说"帮我优化性能"，它就能自己跑起来，不需要和人打交道。
100 个 Agent 并行跑，前提是它们得能独立工作。如果它们整天花时间解决合并冲突、修复 broken build、搞出部署灾难，那你就真的创造了负生产力。
模块化的成本，已经被 AI 打下来了
过去把系统拆分是一件非常奢侈的事情。每多一个服务，就多一堆 boilerplate 代码、多一条管道配置、多一套 CI/CD 流水线。
现在呢？这些通通可以让 Agent 写。Agent 帮你生成模板代码、配 CI、写文档。拆分服务的边际成本断崖式下跌。
还有一个关键点：Agent 的上下文窗口非常有限。 一个足够小、能塞进 Context Window 的模块，对 Agent 来说表现会大幅提升。大块代码放进去，Agent 很容易"迷失"。
所以一个结论很清晰：你代码库的模块化程度，决定了你能并行跑多少 Coding Agent。 既然拆分的成本已经降下来了，那从一开始就为"高模块化"设计，就不再是过度设计，而是合理规划。
总结
Jacob Gold 这篇文章的核心洞见其实很简单，但很有冲击力：
不要再用"小团队"来自我安慰了。 你手上的工具变了，你实际上能调动的"人力资源"已经不是那 5 个人的大脑了，而是 5 个人 × N 个 AI Agent 的并行算力。
Uber 那套当初被嘲笑的架构思路，现在可能变成标准答案。面向 Agent 编程的时代，代码架构的首要目标不再是"让人看懂"，而是"让 Agent 能独立干活"。
准备开始拆吧。
原文链接：There's no such thing as a small software team anymore
觉得这篇文章有价值？点个 赞 和 在看，让更多开发者看到！
欢迎在评论区分享你的想法——你的团队现在同时在跑多少个 AI Agent？
欢迎 转发 给身边的朋友，一起聊聊 AI 时代的工程架构。
收藏这篇文章，下次重构架构时拿出来看看。
#AI编程 #软件架构 #微服务 #并行编程 #AI时代 #AI工具
