The Bottleneck Was Never the Code: AI Coding Agent 时代，协作与上下文才是真正的瓶颈
· 阅读 8 分钟 · 标签: AI Coding Agent, 团队协作, 系统设计2026 年 5 月 6 日，一篇题为《The bottleneck was never the code》的文章冲上 Hacker News 首页，获得 511 分、331 条评论。作者来自 .txt（结构化生成工具公司），通过亲身实验——Claude Codex 仅用几小时就完成了他拖延一年多的项目——引出了一个深刻的问题：如果写代码的成本已经降到几乎为零，那软件开发为什么没有变快 10 倍？
核心论点：代码从来不是瓶颈
这篇文章的核心观点其实一点都不新——但它现在比以往任何时候都更重要。
Fred Brooks 在 1975 年的《人月神话》中就写过：软件项目的进度主要受限于沟通和协调，而非编码本身。Gerald Weinberg 在 1971 年的《The Psychology of Computer Programming》中也有类似洞见。五十年来，代码之所以看起来是瓶颈，仅仅是因为它足够贵——贵到人们一直在关注它。
如今，随着 Claude Code、Codex、Cursor、DeepSeek TUI 等编码 Agent 的成熟，代码的边际成本已经暴跌。作者自己的经验是：向 Codex 描述了半小时方法，它几小时内就产出了可用的初版代码。
但问题来了：这真的意味着软件开发变快了吗？
软件是团队协商后剩下的东西。代码很重要，但它是更困难工作的沉积物，不是工作本身。
需求规格才是新瓶颈
当一个团队中 Agent 负责实现时，真正卡住进度的不再是写代码的人，而是——
等下一个精确的 spec。
文章指出：Feature 被以前所未有的速度实现，工程师不再等待其他工程师。他们在等待下一个格式良好的需求规格。瓶颈从「写代码的人」转移到了「决定写什么的人」——也就是管理。而许多管理者已经被高质量 spec 的供应量压垮了。
这意味着 Roadmap 本身的清晰度、优先级排序、决策质量，突然成了整个团队的吞吐率瓶颈。
Jevons 悖论：昂贵的 Feature 生长
作者引用了一个经典经济学概念——Jevons 悖论：当某样东西变便宜时，你不会用得少，反而会用得更多。
当代码变便宜 10 倍，我们不会只花 10% 的精力做同样的事。我们会把同样的精力花在以前不值得做的事上。三个月前"不值得花时间"的原型，一个下午就能搭建出来。没人真正需要的内部工具被写出来又被遗忘。
每个 vibe coding 出来的产品有 12 个功能，其中 11 个是它变好之前的障碍。
这就引出了 Steve Jobs 在 1997 年说过的真理：Focus is saying no。当年 Apple 砍掉了 70% 的产品线才活过来，而在 Agent 时代，说"不"的难度只会更高——因为每个人都很容易用 Agent 快速做出一个 MVP，但没人顾得上维护、迭代和精简。
上下文（Context）就是新货币
文章最深刻的部分在于对 上下文（Context）的分析。
人类团队通过"渗透"积累上下文——在同一间会议室、看同一个 Slack 频道、凌晨两点一起 Debug 同一个事故。绝大部分上下文从未被写下来。当资深工程师说"这个 PR 会破坏迁移"时，他们依赖的是没有文档的上下文。
Agent 无法渗透。它们不能通过在场、偷听计划会议、或带着上次事故的记忆来获得上下文。你没有塞进 Prompt、文件树、工具或显式指令里的任何东西，Agent 都不会可靠地拥有。
所以当你因为一个 Agent 做了一件有用的事而兴奋时——诚实的计算是：上下文工作是你做的。接下来的十个工程师不会有这个图景，除非他们认真把上下文写下来。
上下文，这个组织一直依赖的未书写底层，现在成了速率限制输入。而人类最不喜欢的恰恰就是——把东西写下来。
救星：Agent 消费上下文，Agent 生产上下文
然而，作者看到了一个出路——
Agent 有一个人类不具备的超能力：它们特别擅长穷举阅读。一个 Agent 可以读取每一个 PR 评论、每一个已关闭的 Issue、每一条 Commit 信息、每一份过时的设计文档、每一个 Slack 历史存档，从中提取出那些没有人写下来、因为根本没人会去读的模式。
.txt 公司已经在构建这样的系统：Agent 爬取代码库、Issue、PR、线程，生成隐式决策的知识库——那些"我们为什么这样做"的约定和上下文。这些知识库又被其他 Agent 使用。
人类非正式完成的"渗透"，正在被外部化为 Agent 可读的东西——而人类自己也能读到。
不过作者也坦诚：这个循环只能产生部分图景。引用 Michael Polanyi 的话——"我们知道的东西比能说出来的多"。有些承重的上下文恰恰因为从未被言说而存在，把它写下来会改变它的本质。
新的护城河是组织级的，不是技术级的
文章结尾给出了一个发人深省的判断：
赢得下一个十年的公司，不一定拥有最好的模型或最好的 Agent 基础设施。而是那些 50 人、200 人、2000 人能够在不断缩小的决策集上保持对齐，同时人均产出大幅提升的公司。
这本质上是一个文化和管理的命题。每一代工具——IDE、版本控制、CI、微服务、DevOps——都承诺通过更好的工具解决协作问题。每一代最终都发现，工具只是已有组织一致性的放大器。小型团队天生有一致性，放大效应总是正向的，这也是为什么 Agent 最狂热的鼓吹者通常是小团队。超过一定规模后，一致性必须被主动生产和维护，放大效应就变成了双刃剑——好的组织变得更好，坏的组织变得更糟。
Agent 是比之前任何工具都大得多的放大器。它的两面性会更剧烈地显现。
对开发者的启示
这篇文章虽然是英文技术圈的讨论，但对中文开发者同样有重要的实际指导意义：
1. 投资写文档的文化
Agent 时代，文档不再是给别人看的，是给所有 Agent 看的。每次你写一个清晰的 spec、一个详细的注释、一次结构化的 PR Description，你都在降低整个团队（包括 Agent）的上下文获取成本。
2. 管理者需要更优秀
如果代码不再是瓶颈，管理者的优先级排序、决策质量和需求澄清能力就成了新的稀缺资源。学会说"不"，比学会写 Prompt 重要得多。
3. 上下文工程是新的软件工程
设计 Prompt 和上下文供应机制——让 Agent 能自动获取 PR 历史、系统设计决策、技术债背景——将成为 2026 年后软件团队的核心竞争力。
4. 警惕 Feature 膨胀
Jevons 悖论在 Agent 时代会加速。每个新功能太容易写了，但每次新增都是维护成本的增量。保持正交、保持精简，将是优秀团队与平庸团队的分水岭。