最后的瓶颈

历史上，编写代码的速度比审查代码的速度慢。

也许你没有这种感觉，因为代码审查会在队列中等待，直到有人处理它。但是，如果你比较实际的行为本身，创建通常是更昂贵的部分。在团队中，人们既编写又审查代码，从来没有觉得“我们应该编程得更慢。”

所以，当越来越多的人告诉我，他们不再知道自己的代码库中有什么代码时，我觉得这里有些非常不对劲，需要反思。

你现在在这里

软件工程师经常认为，如果我们让浴缸变大，如果我们让浴缸变大，溢出就会消失。但是，它不会消失。OpenClaw 目前有超过 2,500 个拉取请求打开。这是一个大的浴缸。

任何与队列合作过的人都知道这一点：如果输入速度超过吞吐量，你就会有一个累积的故障。在那时，背压和负载削减是唯一能保持系统正常运行的东西。

如果你曾经在星巴克被移动订单淹没，你就会知道那种感觉。在店内体验会崩溃。你不知道还有多少订单在你前面。没有明确的队列，没有可靠的等待时间估计，通常也没有真正的取消路径，除非你升级并制造噪音。

这就是许多人工智能相关的开源项目现在的感觉。并且，越来越多的内部公司项目在“AI优先”的工程团队中也会有这种感觉，这是不可持续的。你不能分类，你不能审查，很多拉取请求在某个时候不能合并，因为它们已经过时了。而创建者可能已经失去了将其合并的动力。

人们对新发现的交付速度感到非常兴奋，但在私下交谈中，我一直听到相同的第二句话：人们也对如何跟上他们自己创造的节奏感到困惑。

我们以前也曾经历过

人类以前也曾经历过。很多次。我们已经在人工智能的背景下谈论了卢德派，但看看导致这一切的原因很有趣。马克·卡特赖特（Mark Cartwright）写了一篇关于英国工业革命期间纺织业的优秀文章。其核心是一个简单的想法：每当一个瓶颈被消除，下游就会发生创新。织布速度加快？纱线就成了限制。纺纱速度加快？为了支持新的速度，需要改进纤维，直到最后对棉花的需求增加，也需要自动化。这与导致现代自动化港口和集装箱化的航运业一样。

作为软件工程师，我们也曾经历过这一切。汇编语言不能扩展到更大的工程团队，我们不得不发明更高级的语言。许多编程语言和软件开发框架所做的事情是让我们能够更快地编写代码，并扩展到更大的代码库。但是，它们到目前为止并没有消除工程的核心技能。

虽然用C语言编程比汇编语言更容易，但很多核心问题是相同的。内存延迟仍然很重要，物理学仍然是我们的最终瓶颈，算法复杂性仍然会在规模上使或破坏软件。

放弃？

当管道的一部分变得明显更快时，你需要限制输入。Pi 是一个很好的例子。除非人们被信任，否则拉取请求会被自动关闭。它需要开源假期。这是一个选择：你只是限制输入。你抵制你的新力量，直到你可以处理它们。

或者放弃

但是，如果速度继续增加呢？在编写代码的下游，我们需要加速什么？当然，拉取请求审查明显变成了瓶颈。但是，它不能真正被自动化。如果机器编写代码，机器最好同时审查代码。所以，最终由人类审查的内容已经通过了最关键的可能审查，即最有能力的机器的审查。还有什么阻碍了我们？如果我们继续坚持机器不能被追究责任的基本信念，那么人类就需要能够理解机器的输出。而机器将无情地交付。客户的支持票将直接发送给机器以实施改进和修复，其他机器将审查，人类将在早上批准。

这些听起来既不吸引人，又让人联想到纺织业。个别织工不再对一块坏布负责。如果它很糟糕，它就变成了整个工厂的责任，并且被直接更换。当我们进入一次性塑料软件阶段时，我们可能正在将整个责任层转移到其他地方。

我是瓶颈

但是，对我来说，它仍然感觉不同。也许这是因为我的低级大脑无法理解我们正在经历的变化，未来几代人只会对我们的挑战发笑。它对我来说感觉不同，因为我在一些开源项目中看到的事情，在一些公司和团队中感觉深深地不对劲和不可持续。甚至史蒂夫·叶格（Steve Yegge）现在也对代码创造的日益增长的速度的可持续性表示怀疑。

那么，如果我们需要放弃呢？如果我们需要为这种新型工程成为标准铺平道路呢？我们需要创建什么样的便利设施来使其发挥作用？我不知道。我带着着迷和困惑的眼光看着这一切，试图理解它。

因为这不是最终的瓶颈。我们将找到方法来对我们交付的内容负责，因为社会将要求它。非感知机器永远无法承担责任，看起来我们需要在机器达到这一状态之前解决这个问题。无论它们看起来多么奇怪。

我也是瓶颈。但是，你知道吗？两年前，我也是瓶颈。我一直都是瓶颈。机器并没有真正改变这一点。只要我承担责任并被追究责任，这将始终如此。如果我们能够将责任推向上游，它可能会改变，但到目前为止，如何实现这一点尚不清楚。