写代码快了十倍,工程团队卡住的却是脑子

一个工程师一天能写出多少行"能上生产环境"的代码?

Simon Willison上周在Talking Postgres播客里,和主持人Claire Giordano聊"AI如何改变软件开发"，给了个具体答案:日常水平50到60行,状态好能到200行,这已经算相当不错的一天。他接着抛出一个假设——如果coding agent能让你稳定产出1000行以上调试过、可维护的代码,那才算真正的进步。前提写得很清楚:质量不能打折,该测的测,该维护的能维护。

这是他反复打磨过的一个论点。大家平时都说"代码行数没法衡量生产力",他反着说:正因为好代码的产出有硬上限,一旦这个上限被agent顶开,行数的变化才有意义。这几个数字是他在访谈里的个人估算,不是行业统计,但足够说明一件事——判断agent到底有没有用,不能只看代码量,得看这行代码有没有经得住测试和维护的检验。

数字松动的前提是什么

这张表的关键不在最后一格的数字大,而在"前提条件"那一列。行数暴涨的假设成立,靠的是大量经验和判断力——这恰恰是资深工程师的价值所在,不是随手一条prompt能替代的。

对技术负责人来说,这意味着评估agent的产出不能只看它写了多少行,得看这些代码有没有经过和人工代码同等的测试与维护标准。看起来快,和真的有效,是两件事。

团队没有消失,只是负载被重新分配

行数上限被顶开之后,会碰到一个常见疑问:一个工程师顶过去几倍的产出,公司为什么还需要一整个团队?

Willison提到了显而易见的那条理由——bus factor,一个人的团队本身就是设计缺陷,知识全压在一个人身上,风险很高。但他更看重的是另一个原因:认知容量。代码能写快一百倍,人脑的处理速度没跟着涨一百倍。团队存在的意义,变成了把这份认知负荷分摊下去。

对工程师来说,这句话的潜台词是:单人产出跳涨不代表可以单干。对技术负责人来说,招人的逻辑也在变——更看重谁能审查代码、接手别人写的东西,而不是纯手速。

温彻斯特神秘屋:功能变便宜之后,谁来说"不"

Willison引用了《人月神话》里的"概念完整性"——好软件应该没有意外,边界清楚,各部分严丝合缝。这个概念提出于四十多年前,不是新鲜事。但coding agent让它更难维持:有个功能想法,写一条prompt,五分钟后功能就出来了,软件慢慢长出一些跟主体不相干的凸起。

Claire在对谈里拿温彻斯特神秘屋作类比:那栋房子有140多个房间,传说屋主听信通灵师的话,以为不停加建才能躲过丈夫发明的枪械带来的诅咒,于是造了四十年。这段"通灵师和亡灵"的说法本身在史料上存疑,权当一个流传已久的类比,不必当真实历史。但类比抓住的问题是真的:加一个房间的成本越低,越没有理由不加。

以前拖住乱加功能的,是"来不及"这个客观限制。一个疯狂的功能想法,想到"这得花一周",大概率就放弃了。现在一小时能出原型,理由太容易找了。这道旧刹车靠的是开发时间,时间被agent省掉之后,能不能收住,全靠人自己判断。

对技术负责人来说,这条判断能落到一个具体动作:靠"没时间"自动挡掉的需求,现在得靠人工设卡——功能准入审查、强制代码review、测试覆盖率门槛,把旧刹车的作用用制度补回来。对工程师来说,判断力和取舍能力正在变成核心技能,写代码的速度不再是差异化优势。

接下来值得观察的,是有多少团队真的把这类准入机制建起来,而不是继续靠agent一路加房间加到系统失控——这才是agent时代软件质量的分水岭,不在工具本身。

老子说"少则得,多则惑"。加房间总比拆房间容易,这才是agent时代真正的考验。