瓶颈从来不在代码上

今天 HN 上有两篇从不同角度写 AI 编程工具的文章，放在一起看有一种难得的连贯感。

先说 Simon Willison 那篇。342 分，但讨论质量远超分数。

Willison 是 Python 社区的老将，也是 OpenAI 的早期员工。他对"vibe coding"和"agentic engineering"的区分一直很明确：vibe coding 是你不怎么看代码，让 AI 随便写；agentic engineering 是你作为专业工程师，用 AI 工具来加速高质量的生产级系统。

但他说了一件事让很多人不安。他发现这两个边界，在自己身上正在模糊。

他说自己现在也不逐行审查 agent 写的代码了。因为他知道，如果你让 Claude Code 写一个 JSON API 端点、跑个 SQL 查询、返回结果，它"就是会写对的"。加自动测试、加文档，它也不会搞砸。

可他没审查。然后他感到内疚：如果我没审查代码，把它放到生产环境，这算不算不负责任？

然后他想到了一个类比。当别的团队交给你一个服务——比如一个图片处理服务——你会去读他们每一行代码吗？不会。你看文档，用一下，开始做你自己的事。只有出现问题时，你才会去翻他们的 Git 仓库。

他开始在用同样的方式对待 agent。而且这感觉越来越自然。

嗯，这里有一个更深层的问题。Willison 说的是"normalization of deviance"——偏差的正常化。每次 agent 写出了正确的代码而没有你的密切监督，你就更容易在下一次信任它，哪怕那一次它写错了。这种信任的累积是无声的，而当你被烧伤时，你才会意识到信任已经越界了。

Willison 还提出了一个新的评估标准。过去你看到一个 GitHub 仓库有 100 个 commit、好的 README、自动化测试，你会觉得这项目投入了很多精力。现在你可以在半小时内让 agent 生成一模一样的东西——100 个 commit、漂亮的 README、每行代码的测试。看起来完全一样，但你无法判断它到底好不好。

所以他现在更看重的不是测试和文档的质量，而是：有人真正用过这个东西吗？一个 vibe coded 的东西如果作者每天用了两周，比一个半小时内吐出来几乎没跑过的东西有价值得多。

第二篇是 Aletheia 团队写的"瓶颈从来不在代码上"。480 分，角度更系统。

他们先讲了一个很朴素的故事。他们拖延了一年多的一个实验——测试结构化生成算法——终于让 Codex 去做了。花了半小时解释方法，几小时后就有了一个可用的初版。就这些。

但文章的核心观点是：讨论 coding agent 时，所有人都在谈论"个人生产力提升"。而真正有趣的分析单位是"协作"。

Fred Brooks 在 1975 年的《人月神话》里就说了：有影响力的软件往往需要许多人协作完成。软件是一群人协商完"系统应该是什么样的"之后剩下的东西。代码很重要，但它不是工作本身，它是更困难的工作——达成共识——的残余物。

五十年来，这个残余物足够贵，所以我们的注意力一直放在它上面。打字速度、语言设计、框架选择、IDE 插件、代码审查工具——一切都是为了降低残余物的成本。现在 coding agent 把这个成本降到了足够低，我们终于看到了底下是什么：人们在试图达成共识。

这个共识的谈判、沟通、共享认知——才是真正的瓶颈。而且它跟以前一样难。

文章还提出了一个很有意思的概念："Context is gold"。

上下文是一个组织真正运行的基础。它是对"我们做什么、为什么重要、试过什么、谁决定什么、什么是承重的什么是遗留的"的共享理解。团队成员通过渗透来积累上下文——在同一个房间、看同一个 Slack 频道、凌晨两点一起调试同一个事故。大部分上下文从未被写下来。

而 agent 无法渗透。它们得不到"在场"的上下文。你没打包进 prompt 的东西，它们就不具备。没有上下文，agent 会产生一个对"略微错误的问题"的合理回答。

所以作者提出了一个可能的解决方案：让 agent 去爬取代码库、issue、PR、线程，提取那些没人有空写下来的隐性决策和约定。不只是"这个模块存在"，而是"这个模块很奇怪，因为迁移必须保留旧行为"。

agent 需要上下文，所以需要有 agent 去生产上下文。一旦这个循环跑起来，组织就有了一个自己永远不会产生的书面基础。

最后文章说了一句很重量的话：

下一个十年获胜的公司，不一定是有最好模型或最好 agent 基础设施的公司。而是那些 50 人、200 人、2000 人能在更少的决策上保持对齐，同时每人产出更多的公司。那些在 agent 到来之前就明白，自己最难的问题是"一致性"的公司。

这是一个文化和管理问题。一直都是。

每一代工具——IDE、版本控制、CI、微服务、DevOps——都承诺通过更好的工具来解决协调问题。结果每一个都变成了组织既有一致性水平的乘数。小团队有免费的一致性；大团队的一致性需要被生产和维护。

agent 是之前任何工具都达不到的乘数。它们作为"让个人更快写代码"的方式被高估了，作为"让组织外化它们所知道的"的方式被低估了。

两篇文章放在一起看，它们其实在说同一件事。

Willison 在个人层面上经历了瓶颈的转移：他不再关注"我写了多少代码"，而开始关注"我是否信任了这个系统"、"这个系统是否被真正使用过"。

Aletheia 在组织层面上看到了同样的转移：当代码成本趋近于零，瓶颈从"实现"移到了"意图定义、验证、判断和反馈"。

两个层面，同一个问题：当执行变得足够便宜时，真正稀缺的是判断。

而判断不能 vibe。