硅谷工程师Jacob Gold最近抛出一个说法：一个五到十人的小团队，只要接上二十到一百个并行编码agent，日常产出就能从50条commit、10个PR冲到500条commit、100个PR，规模逼近Uber当年为了让数百名工程师互不打扰而拆成数千个微服务时的产出。他的结论很干脆：代码库拆得越碎，能同时喂饱的agent就越多，"小团队"这个概念正在瓦解。
这个判断听着诱人，但只说对了一半。最新的实证研究显示，agent写出的PR里27.67%会撞上合并冲突，涉及超过33.6万个冲突区域，其中42%不是简单的代码重叠，而是更难处理的结构性冲突。commit数字涨十倍是真的，但这些代码能不能变成真正交付的东西，取决于一套原文几乎没展开的工作流能力。
模块化变便宜了，但省下的只是脚手架钱
Uber早年的教训是，几百个工程师同时改代码，排队合并会把人逼疯，于是拆成数千个微服务，各自独立发布。这套做法在当时被视为过度工程化，因为拆分意味着更多样板代码、更多CI配置、更多服务间胶水代码，成本很高。
现在这部分成本被agent吃掉了。脚手架、CI配置、接口文档，agent可以自动生成，拆分的边际成本骤降。agent自身的上下文窗口有限，反过来又逼着模块变小——小到能装进一次对话里，agent才干得利索。于是原本"没必要"的极端模块化，突然变得经济可行。
这也是Jacob Gold论断里唯一站得住的部分：模块化程度决定了能有效并行运行多少agent。但他自己也只是轻描淡写地提了一句"如果agent把时间都花在解决冲突、修复构建上，可能净负生产力"，没有展开，也没有数字支撑。
27.67%背后：生成速度不等于交付速度
这一句轻描淡写的风险提示，恰恰是最该展开的地方。
一项针对约3.3万个agent撰写PR的研究发现，被拒绝的PR普遍体量更大、涉及文件更多、CI失败率更高；相比之下，文档类和构建类的小改动更容易被合并，而性能优化、bug修复这类"看起来更有价值"的工作反而更容易卡在评审环节。另一个专门评估agent协作能力的基准测试CooperBench测过两个agent各自实现可能交互的功能，结论是当前的编码agent还缺乏作为自主队友所需的协调能力。
- 风险.GitHub的merge queue会在候选PR未通过检查或与目标分支状态冲突时把它踢出队列；GitLab的merge train文档也明确写了，两个各自通过检查的变更合并后仍可能把目标分支搞坏。这说明"每个agent各自跑通"不等于"合起来能跑通"。
微服务还是模块化单体，agent更认哪一种
Jacob Gold的论断隐含一个架构倾向：拆得越碎（往微服务方向走）越好。但这个方向对agent未必友好。
微服务把契约、部署版本、重试和幂等逻辑分散到不同服务里，agent很难在一次对话里看全这些跨服务的隐性约定，一个agent写出的本地正确代码，放到全局里可能根本对不上。相比之下，模块化单体——把边界拆清楚但仍放在同一个仓库里——往往能让agent在一次上下文里同时看到接口定义、实现、测试和调用方，出错率更低。
这个对比目前更多来自实践者的报告，而不是成熟的对比研究，"模块化单体永远赢"这种说法说得太满。但至少能提醒一句：把代码拆成一千个微服务，未必比拆成边界清楚的几十个模块更适合agent干活。
谁该操心这件事：从写代码到管agent
真正要落地"模块化决定并行度"这套说法，组织得先补几样东西：每个模块要有明确的所有权边界声明，让agent知道自己能改哪里；每个agent最好在隔离的工作树（git worktree能提供独立索引）里干活，减少互相踩脏共享状态；提交前过一遍merge queue或merge train这类工具，而不是靠人工肉眼查冲突；最后还得有人扮演integrator的角色，专门负责把并行产出的代码拼回一个能跑的整体。
- 结论.真正该盯的指标不是commit数和PR数，而是接受变更率、首次CI通过率、合并冲突率、人类评审耗时——这些才反映agent产出有没有真的变成交付的代码。
开发者社区里的抱怨也印证了这一点：一线工程师的角色正在从"写代码的人"变成任务拆解者、agent监督者、最后的把关人，管理清理合并、追陈旧分支、调试CI已经成了运行多个并行agent时最耗神的事，也是新一轮"监督式疲劳"的来源。省下的编码时间，很多时候原地还给了协调和集成。
生成的代码不是交付的代码，中间那道合并的坎从来没消失过。
对工程负责人来说，接下来该盯的不是"能不能跑更多agent"，而是随着agent数量上升，合并冲突率和CI延迟是不是也在同步往上走——如果是，模块化只是拿到了入场券，真正决定产出的，还是团队有没有配上验证、集成和人力监督的能力。