摘要：当代码变得廉价，真正的瓶颈浮出水面——不是写代码的速度，而是人与人之间的共识。
最近，结构化生成领域的创业公司 .txt（dottxt）的CEO Rémi Louf 写了一篇博客，标题叫《The bottleneck was never the code》。这篇文章在技术圈引发了不小的讨论，因为它说了一个很多人隐约感觉到、但不太愿意承认的事实：
编程Agent让个人写代码快了10倍，但软件行业并没有因此快10倍。
这个矛盾困扰了他好几个月。他的结论是：代码从来就不是真正的瓶颈。
一个真实的故事
Louf 讲了一个自己的经历。他们团队有一个实验，拖了一年多没做——不是因为技术难，而是因为总有更紧急的事。上个月，他花了半小时把方法论讲给 Codex（OpenAI的编程Agent），几个小时后就拿到了一个能跑的第一版。
就这么简单。
但问题来了：如果写代码这么容易，为什么整个行业没有因此飞速前进？
50年前就有人说过的道理
1975年，Fred Brooks 在《人月神话》里就写过：往一个延期的项目里加人，只会让它更延期。1971年，Gerald Weinberg 在《程序开发心理学》里也说过类似的话。
软件，本质上是一群人谈判完之后留下的残留物。
代码当然重要，但它是更难的那部分工作的副产品，而不是工作本身。
过去50年，这个"残留物"足够贵，贵到我们所有注意力都放在它上面——打字速度、语言设计、框架选择、IDE插件、代码审查工具，全都是为了降低"残留物"的成本。
现在编程Agent把这个成本打到了地板价。于是我们终于看到了底下藏着的东西：人们试图达成共识。
而达成共识，和50年前一样难。
路线图才是真正的限制
当Agent接管了实现层，团队的瓶颈变成了什么？
变成了"写出足够精确的规格说明，让Agent能拿起来就跑"。
路线图，写下来。验收标准，写下来。“我们到底想要什么”，逼成精确的文字——无论是测试用例、工单，还是设计文档。
Louf 说，他认识的很多管理者现在被这件事压垮了。功能以前所未有的速度被实现，工程师不再等其他工程师了。他们在等下一个写得足够好的需求。
瓶颈从写代码的人，转移到了决定该写什么代码的人。也就是说：管理层。
杰文斯悖论：便宜了反而用得更多
经济学里有个概念叫杰文斯悖论：当某样东西变便宜了，你不会用得更少，而是用得更多。
当代码变得10倍便宜，我们不会只花原来10%的精力做同样的事。我们会把同样的精力花在以前"不值得做"的事情上。
三个月前"不值得花时间"的原型，现在一下午就能搞出来。解决了"没人真正有这个问题"的内部工具，被造出来然后被遗忘。
Louf 引用了乔布斯1997年的话：专注就是学会说不。 那一年苹果砍掉了70%的产品线，活下来的是那个学会了做减法的公司。
他说了一句很扎心的话：
每一个用Vibe Coding搞出来的、带12个功能的产品，离伟大只差砍掉11个功能。
Agent时代，做减法的纪律变得更难了——谁不喜欢"又发了一个新功能"的感觉呢？
上下文才是黄金
所有的协作都运行在一种人类很少主动思考的东西上：共享上下文（shared context）。
上下文是一个组织运转的基础原料。它是"我们在造什么、为什么重要、试过什么、谁决定了什么、什么是承重墙什么是装饰品"的共同理解。
人类团队通过"渗透"来积累上下文——在同一个房间里、读同一个Slack频道、凌晨两点一起调同一个故障。大部分上下文从来没有被写下来。当一个资深工程师review PR时说"这会搞坏迁移"，他调用的是没有任何文档记录的上下文。
Agent不会渗透。
它们不会因为"在房间里"而获得上下文，不会因为半听到了规划讨论而获得上下文，不会因为记得上次事故而获得上下文。你没有塞进prompt、文件树、工具或明确指令里的东西，它们就是没有。
没有上下文，Agent会对一个"略微偏了的问题版本"给出一个"看起来合理的答案"。
所以当 Louf 为自己团队的Agent做出了有用的东西而兴奋时，他的诚实复盘是：是我们做了上下文的工作。 下一个加入的工程师不会默认拥有这个画面。他们只有在团队认真把它写下来的情况下才会拥有。
一个有意思的解法
好消息是：Agent虽然不会渗透，但它们极其擅长穷举式阅读。
一个Agent会读完每一条PR评论、每一个关闭的issue、每一条commit message、每一份过时的设计文档、每一段Slack存档，然后提取出没人费心写下来的模式——因为以前没人会去读。
Louf 说他们已经在 .txt 开始做这件事了：让Agent爬遍代码库、issue、PR、讨论线程，生成一个知识库——记录那些隐含的决策、惯例、“我们为什么这么做”。不只是"这个模块存在"，而是"这个模块很奇怪，因为迁移时必须保留旧行为"，或者"这个benchmark很重要，因为之前的优化悄悄改变了分布"。
生产上下文的Agent + 消费上下文的Agent = 一个组织从来不会自己产出的书面基底。
当然，这个循环只能产出部分画面。正如哲学家 Michael Polanyi 说的：我们知道的比我们能说出来的多。有些承重上下文之所以存在，恰恰是因为它从未被文字化。
但"有用的起点"和"完全恢复"之间，前者可能就够了。
真正的护城河是组织能力
Louf 的最终结论：
未来十年赢的公司，不一定是模型最好的或Agent基础设施最好的。而是那些50人、200人、2000人的团队，能在产出更多的同时，保持对越来越少的核心决策的对齐。
这是文化和管理问题。一直都是。
每一代工具——IDE、版本控制、CI、微服务、DevOps——都承诺通过更好的工具解决协作问题。每一代最终都只是放大了组织本身已有的协调能力。小团队天然有一致性，所以放大器对它们总是正面的——这也是为什么最响亮的Agent布道者往往是小团队，而且他们对自己的情况说得基本没错。
但过了一定规模，一致性必须被主动生产和维护。放大器在两个方向上都变得更尖锐：好的组织变得更好，差的组织更快地把事情搞砸。
Agent是比之前所有工具都大得多的放大器。信号在两个方向上都会更响。
我的看法
读完这篇文章，我觉得 Louf 说到了一个很多技术人不愿意面对的点：
我们花了太多时间讨论"Agent能不能写出好代码"，花了太少时间讨论"我们能不能告诉Agent该写什么代码"。
前者是技术问题，后者是组织问题。而组织问题，从来都比技术问题难。
对于个人开发者来说，编程Agent确实是革命性的。但对于一个200人的工程团队来说，Agent更像是一面照妖镜——它会无情地暴露你的需求文档有多模糊、你的架构决策有多少是口口相传、你的团队共识有多脆弱。
代码变便宜了，但共识没有。
这可能是2025-2026年最值得所有技术管理者认真思考的一句话。
参考来源：Rémi Louf, “The bottleneck was never the code”, thetypicalset.com, 2026年5月