本文翻译自 The Bottleneck Was Never the Code，原载于 Hacker News。
上个月，我终于做了一个在 .txt 公司推迟了一年多的实验。目标是测试我们的结构化生成算法以及开源替代方案——不再用朴素的”它能接受这个字符串吗？”来评估，而是用更接近真实问题的标准：”它能产生正确的 token 分布吗？”
这个实验一次次出现在讨论中，又一次次被推回路线图。直到上个月，我花了半个小时向 Codex 解释了方法。几个小时后，它产出了一个可用的初版。就这样，搞定了。
编程 Agent（编码智能体）正在改变个人编写代码的方式。从某种意义上说，这已经发生了。然而，我对人们通常讲述的故事仍然持怀疑态度——即个人生产力的提升会转化为整个行业的大幅加速。几个月来，我一直在这种张力中思索。
是时候重读经典了。
协作才是真正的研究单位
有影响力的软件往往是由许多需要协作的人共同编写的。
关于编程 Agent 的讨论几乎完全集中在个人生产力的提升上。但协作才是真正值得分析的维度。
这不是一个新想法。Fred Brooks 在 1975 年的《人月神话》中就写到了这一点，而且当时也不新鲜——Gerald Weinberg 在 1971 年的《计算机编程心理学》中就提出了这个观点。软件，是一群人在就”系统应该做什么”进行协商之后留下的东西。代码很重要，但它是更困难工作的残留物，而不是工作本身。
五十年来，这种残留物昂贵到足以让我们始终关注它。打字速度、语言设计、框架选择、IDE 插件、代码审查工具——这些都是为了降低残留物的成本。有了编程 Agent 之后，成本已经降得足够低，以至于我们终于看清了底下的东西：人们在试图达成一致。
协商、达成共识、传达对”我们在构建什么”的共同理解，已经变成了核心工作。而且它一如既往地困难。
路线图才是上限
当一个团队使用 Agent 来完成实现工作时，拖慢进度的不是编码——而是产出足够精确的规格说明，让 Agent 可以直接上手执行。路线图，要写下来。验收标准，要写下来。”我们真正想要什么”必须被迫精确化，无论是通过测试套件、工单还是书面设计文档。
不同团队的情况可能不同，但我认识的许多管理者已经被这压垮了。功能以惊人的速度被实现，工程师们不再等待其他工程师。他们在等待下一个成型的 spec（规格说明）。瓶颈从写代码的人转移到了决定代码应该存在的人。也就是说：管理层。
这对中国开发者来说可能是个反直觉的结论——很多人以为 AI 会让”写代码”这件事变得不那么重要，但实际上，它让”想清楚写什么”变得更重要了。能精确描述需求的能力，正在成为新的核心竞争力。
专注就是说”不”
而且需要达成共识的面积还在扩大。这就是杰文斯悖论（Jevons Paradox）：当某样东西变得更便宜时，你倾向于用更多，而不是更少。当代码的编写成本降低 10 倍时，我们不会用 10% 的精力完成同样的成果。我们会用同样的精力去追求以前不值得做的事情。三个月前”不值得花时间”的原型，现在一个下午就能搭出来。解决没人真正遇到过的问题的内部工具，被构建出来然后被遗忘。
每一个靠”氛围编程”（vibe coding）搞出来有 12 个功能的产品，距离优秀还有 11 个功能的距离。
人们吸收功能的速度是有限的，无论团队交付 10 个功能还是 50 个功能，这个速度大致相同。Steve Jobs 在 1997 年说：专注就是说”不”。那一年 Apple 砍掉了大约 70% 的产品线，而回归的那个 Apple，正是学会了做减法的公司。有了 Agent 之后，这种纪律变得更难执行了——谁不喜欢发布新功能的感觉呢？
上下文是金子
所有这些协商都依赖于人类很少去思考的东西：共享上下文（shared context）。
上下文是一个组织运转的基础商品。它是对”我们在建什么、为什么重要、尝试过什么、谁决定了什么、什么是承重的、什么是残留的”的共同理解。团队中的人通过渗透来积累它——因为在同一个房间里，因为读同一个 Slack 频道，因为凌晨两点一起调试同一个故障。其中大部分从未被写下来。当一个资深工程师审查 PR 时说”这会破坏迁移”，他调用的上下文没有任何文档记录。
Agent 无法做到渗透。它们不会因为身在房间中、半听到规划对话、或带着上次事故的记忆而获得上下文。你没有设法塞进 prompt、文件树、工具或明确指令中的任何东西，它们都不一定能拥有。没有上下文，一个 Agent 会针对一个略有偏差的问题给出一个看似合理的答案。
所以，当我对一个 Agent 在 .txt 完成了某件有用的事情感到兴奋时，诚实的核算是：我们做了上下文工作。接下来的十个工程师默认不会有这个全局图景。他们只会在我们认真写下来的范围内拥有它。
上下文——组织一直在其上运转的未书写底层——现在是速率限制输入。而人类的自然倾向是让它保持隐性，因为以前从来没有人会去读那个显式的版本。
真正的程序员不写文档
生产易于消费的上下文，恰恰是人类不喜欢做的事情。
但可能拯救我们的是，Agent 在穷尽式阅读方面异常出色。一个 Agent 会阅读每一条 PR 评论、每一个已关闭的 issue、每一条 commit 消息、每一份过时的设计文档、每一个 Slack 归档，然后提取出没人费心写下来的模式——因为没人会去读它们。
我们已经在 .txt 开始构建这个了。Agent 爬取代码库、issue、PR、讨论线程，产出关于隐性决策、约定、”为什么我们这样做”的知识库——那些没人有时间记录的东西。不只是”这个模块存在”，而是”这个模块很奇怪，因为迁移必须保留旧的行为”，或者”这个基准测试很重要，因为之前的优化悄悄改变了分布”。其他 Agent 在需要操作代码库时使用这个知识库。人类之间非正式进行的渗透，正在被外化为 Agent 可以阅读、人类也可以阅读的东西。
消费上下文的 Agent 需要生产上下文的 Agent。一旦这个循环运转起来，组织就拥有了一个它自己永远不会主动产出的书面底层。上一节中的速率限制约束不再是常数。上下文变成了一种你可以生产更多的东西。
当然，这个循环永远只会产生一个局部的图景。引用 Michael Polanyi 的话：我们知道的比我们能说出的多。一些承重的上下文恰恰因为它从未被诉诸语言而存在，把它写下来会改变它本身。人类通过在场积累的渗透层无法从书面记录中完全恢复。出来的东西更接近一个有用的起点，而不是完全的恢复，这是否足以产生复利效应——这是一个我仍在测试的实证问题。我认为可以。但我不确定。
新的护城河是组织层面的，不是技术层面的
在未来十年中获胜的公司，不一定是拥有最好的模型或最好的 Agent 基础设施的公司。而是那些五十人、然后两百人、然后两千人，能够在交付更多产出的同时，对不断缩减的决策集保持一致的公司。它们是那些在 Agent 到来之前就已经知道——最困难的问题是一致性——的公司。
这是一个文化和管理问题。一直都是。
每一代之前的工具——无论是 IDE、版本控制、CI、微服务（microservices）还是 DevOps——都承诺通过更好的工具来解决协调问题。每一代最终都证明是组织一致性的乘数。小团队的凝聚力是免费的；在那里乘数始终是正的，这也是为什么最大声的 Agent 支持者往往来自小团队，而且他们对自己的环境大多是正确的。超过一定规模后，一致性必须被生产和维护，乘数在两个方向上都变得更尖锐。好的组织变得更好。差的组织更快地搞砸事情。
Agent 是一个比上述任何工具都大得多的乘数。信号在两个方向上都会更响亮。它们作为让个人更快写代码的方式被高估了，而作为让组织外化其所知的方式被低估了。
Agent 可以感觉像你自己思维的延伸，这种感觉令人兴奋。更难的挑战是让它们成为你公司文化的延伸。那是一个不同的问题，一种不同形态的工作。它需要写作文化。它需要足够深思熟虑的管理层来识别他们仍然是上下文瓶颈的地方。它需要把一致性视为一个需要维护的真正制品的人。新的变化是，其中一些东西现在变得可以构建了。读取-提取循环是一种形态，还会有其他的。
我会持续报告这个实验的进展。
核心要点：
- 协作 > 个人效率：编程 Agent 的真正价值不在于让个人写得更快，而在于改变团队协作的方式
- 规格说明是新瓶颈：当代码编写不再是瓶颈，”想清楚要写什么”就变成了最稀缺的资源
- 上下文是金子：组织中从未被写下来的共享理解，现在是速率限制因素
- Agent 的真正潜力：不在于替代程序员写代码，而在于外化组织中的隐性知识
- 新的护城河是组织层面的：公司的竞争优势将取决于保持组织一致性的能力，而不是技术本身