本文翻译自 The bottleneck was never the code，原载于 Hacker News。
写代码从来不是最难的环节
前阵子，我终于在 .txt 跑完了一个推迟了一年多的实验。
实验的目标是测试我们的结构化生成算法及其开源版本，用一种更接近真实问题的方式来验证——不只是简单的”这个字符串能不能接受”，而是”它是否产生了正确的 token 分布”。
这个实验反复出现在讨论中，又一再被搁置。上个月，我花了半小时向 Codex 解释了这个方法。几个小时后，它就产出了一个可用的初版。就这么简单。
Coding Agent 正在改变个人编写代码的方式。某种程度上，这种改变已经发生了。然而，我对人们常说的那个叙事始终持怀疑态度：个人的效率提升意味着整个软件行业会显著加速。几个月来，我一直卡在这个矛盾点上。
是时候重新读一读经典了。
协作才是关键
有影响力的软件，往往是由许多需要协作的人共同编写的。
关于 coding agent 的讨论几乎都聚焦在个人效率的提升上。但协作才是更有价值的分析单元。
这当然不是什么新想法。Fred Brooks 在 1975 年的《人月神话》中就写过，而且当时这也不是新概念了——Gerald Weinberg 在 1971 年的《计算机编程心理学》中就提出了这个观点：软件是一群人经过协商之后，关于”系统应该做什么”的最终共识的产物。 代码很重要，但它是更困难工作的副产品，而不是工作本身。
五十年来，这个副产品昂贵到足以让我们把注意力都放在它上面。打字速度、语言设计、框架选择、IDE 插件、代码审查工具，所有这些都是为了降低写代码的成本。而随着 coding agent 的出现，代码的成本已经降到了足够的程度，让我们终于看清了底下真正的挑战：人与人之间如何达成一致。
协商、达成共识、传达对”我们正在构建什么”的共同理解——这些才是真正的工作。而且它们和以前一样困难。
路线图才是上限
当 Agent 负责实现时，什么会拖慢团队？答案是——产出足够精确的规格说明。
团队需要将路线图写下来、验收标准写下来、把”我们到底想要什么”逼迫成精确的描述——无论是通过测试套件、工单还是设计文档。
情况因团队而异，但我认识的很多管理者已经被这种转变压得喘不过气。功能以惊人的速度被实现，工程师不再等待其他工程师——他们在等待下一个足够清晰的规格说明。瓶颈从写代码的人，转移到了决定代码应该存在的人。也就是说：管理层。
这对中国开发者来说并不陌生。很多快速迭代的互联网公司早就发现，当执行速度提升时，产品和技术的对齐成本反而成了最大的开销。
专注就是学会说不
而且，需要达成共识的边界还在不断扩大。这就是杰文斯悖论（Jevons Paradox）：当某样东西变得更便宜时，你会用得更多，而不是更少。
当写代码的成本降低了 10 倍，我们不会花十分之一的精力做同样的事情。我们会花同样的精力去做以前不值得做的事情。三个月前”不值得花时间”的原型，现在一个下午就能搭建出来。解决没人真正遇到的问题的内部工具被快速开发出来，然后被遗忘。
每个 vibe-coded 的产品有 12 个功能，就差 11 个功能才能变得优秀。
人们对功能的吸收速度是有限的，不管团队发布 10 个还是 50 个功能，这个速度大致相同。Steve Jobs 在 1997 年说过：专注就是学会说不。那一年，Apple 砍掉了大约 70% 的产品线，随后崛起的公司学会了做减法。有了 Agent 之后，这种自律变得更难了——毕竟，发布新功能的感觉太好了。
上下文才是黄金
所有的协商都建立在一个人类很少意识到的东西上：共享上下文（shared context）。
上下文是组织运转的基础。它是对”我们在构建什么、为什么重要、尝试过什么、谁做了什么决定、什么是核心的、什么是遗留的”的共同理解。团队成员通过潜移默化来积累上下文——在同一个房间里、读同一个 Slack 频道、凌晨两点一起调试线上故障。大部分上下文从来没有被写下来过。当一个高级工程师审查 PR 时说”这会破坏迁移”，他依赖的是没有任何文档记载的上下文。
Agent 无法通过潜移默化获取上下文。 它们不会因为在房间里、旁听了计划会议、或者记住了上次事故就获得理解。任何你没有塞进提示词、文件树、工具或明确指令中的信息，Agent 都不会有。没有上下文，Agent 会针对一个稍微偏离的问题给出一个看起来合理的答案。
所以，当我为某个 Agent 在 .txt 做了有用的工作而兴奋时，诚实的评估是：上下文工作是我们自己做的。 接下来的十个工程师不会默认拥有这些理解。他们只有在我们认真地把这些知识写下来的时候，才能获得它。
上下文——这个组织一直赖以运行但从未明确记录的底层——现在成了速率限制的输入。而人类的天性是让它保持隐式，因为以前从来没有”人”需要阅读那些明确写出来的版本。
Agent 能帮我们提取上下文
真正的程序员不会写文档。
人类恰恰不喜欢做一件事：产出易于消费的上下文。
但也许能救我们的是，Agent 在阅读和提取信息方面有着不合理的高效率。一个 Agent 会阅读每一条 PR 评论、每个关闭的 issue、每条 commit 信息、每份过期的设计文档、每个 Slack 归档，并提取出没人愿意写下来的模式——因为以前没人会去读它们。
.txt 已经开始构建这个能力了。Agent 爬取代码库、issues、PRs、讨论串，产出一个关于隐式决策、约定、”为什么我们这样做”的知识库。不只是”这个模块存在”，而是”这个模块很奇怪，因为迁移必须保留旧行为”，或者”这个 benchmark 很重要，因为之前的优化悄悄改变了分布”。其他 Agent 在需要操作代码库时，就可以使用这个知识库。人类间潜移默化传递的上下文正在被外化成 Agent 和人类都可以读取的东西。
消费上下文的 Agent 需要产出上下文的 Agent。 一旦这个循环运转起来，组织就拥有了一个它自己永远不会产出的书面知识基础。之前提到的速率限制就不再是固定的了。上下文变成了可以批量生产的东西。
当然，这个循环永远只能产出局部的图景。引用 Michael Polanyi 的话：我们知道的比我们能说出来的多。 一些关键的上下文恰恰因为从未被诉诸文字而存在，写下来反而会改变它的本质。人类通过在面对面交流中积累的潜移默化层，无法从书面记录中完全恢复。最终产出的更像是一个有用的起点，而不是完整的还原。这是否足够支撑复利增长，还是一个我正在验证的实证问题。我认为是的，但我不确定。
新的护城河是组织层面的，不是技术层面的
未来十年赢的公司，不一定是拥有最好模型或最好 Agent 基础设施的公司。
赢家将是那些——无论 50 人、200 人还是 2000 人的规模——都能在不断缩小的决策集上保持一致，同时每个人产出更多成果的公司。它们会是那些在 Agent 到来之前就已经知道，最困难的问题是一致性（coherence）的公司。
这是一个文化和管理问题，一直都是。
之前的每一代工具——无论是 IDE、版本控制、CI、微服务（microservices）还是 DevOps——都承诺通过更好的工具来解决协调问题。每一代最终都只是对已有组织一致性的乘数器。小团队天然就有一致性，乘数效应在那里是正面的——这也是为什么最响亮的 Agent 鼓吹者往往是小团队，以及为什么他们对自己的情况基本上是对的。超过一定规模后，一致性需要被主动生产和维护，而乘数器会在两个方向上放大：好的组织变得更好，差的组织更快地把事情搞砸。
Agent 是比上述任何工具都大得多的乘数器。信号在两个方向上都会更响。 它们作为”让个人更快写代码”的工具被高估了，而作为”让组织外化其知识”的方式被低估了。
写在最后
Agent 可以感觉像你思维的延伸，这种感觉令人兴奋。但更大的挑战是让它成为你公司文化的延伸。这是一个不同的问题，一种不同形态的工作。
它需要写作文化。它需要管理层足够敏锐，能识别出自己在哪些地方仍然是上下文的瓶颈。它需要人们把组织一致性当作一个真正需要维护的产物来对待。新的变化是，其中一些东西现在是可以被构建的。”阅读-提取”循环是一种形态，还会有其他的。
我会继续汇报实验的进展。
关键要点：
- 写代码从来不是真正的瓶颈——团队协作、达成共识、上下文共享才是
- Coding Agent 让隐性成本显性化——代码成本降低后，规格说明和管理决策成了新的瓶颈
- 杰文斯悖论在起作用——代码更便宜意味着更多代码，但更多功能不等于更好的产品
- 上下文是新的速率限制——Agent 无法通过潜移默化获取上下文，组织需要主动外化知识
- Agent 之间的上下文循环——消费上下文的 Agent 和产出上下文的 Agent 形成飞轮
- 组织一致性是真正的护城河——比最好的模型或 Agent 基础设施更重要