现在你可以交付自己并不理解的软件了

Sean Goedecke 有一篇文章叫你无法设计你没有参与开发的软件。他认为，大型代码库中的良好设计取决于系统的具体细节，而唯一了解这些细节的人就是正在开发它的人。他说，在实践中，这几乎总是意味着要成为一名积极的贡献者。

这曾经是一个安全的假设，因为如果你不理解一个系统，你很快就会知道。你什么都发布不了。现在，你可以在一个你几乎不理解的代码库中发布很多东西，而且你很久之后才会发现。有时别人会先发现。

贡献曾经需要理解

过去，对一个系统做出第一次真正的改动是很难的。你必须找到东西在哪里，弄清楚它们为什么那样构建，运行代码，并弄坏一些东西。这些都不是重点。你只是想发布。但当你完成时，你已经对这个系统了解了很多，因为不这样做就无法做出贡献。而当你确实不理解某些东西时，你马上就会发现。

所以产出是一个不错的信号。当一位队友在代码库的某个部分发布了很多好的工作时，你可以信任他们去做那里的高风险改动。他们在这个过程中了解了这个系统。

现在两者已经分离

今天，你可以打开一个从未见过的代码库，描述你想要什么，然后在一小时内得到一个看起来合理的改动。代码能编译，测试能通过。你可以这样持续一段时间。

问题会在之后显现。也许是一个客户遇到的 bug，由别人被呼叫去处理，这个 bug 很难理解，也很难修复。

过去如何捕捉到它

过去有几件事能及早捕捉到理解的缺乏。你卡住了，或者你不得不去问了解这个系统的人，或者一位了解它的审查者对你的改动提出了反对。所有这些都发生在任何东西发布之前，而唯一注意到的人是你，也许还有那个帮助你的人。

智能体移除了大部分这些检查。你很少会卡住，你可以问智能体而不是问人。审查仍然会发生，但比以前弱了。PR 看起来干净，而审查者往往也依赖智能体。没有什么真正取代了那些检查。

构建替代方案很便宜

智能体也让构建替代方案变得便宜。如果一个现有系统令人困惑，现在原型化一个新系统比学习旧系统为什么这样工作更容易。这就是 Sean 所说的针对问题设计。过去这需要几周，所以人们大多不做。现在只需要一天，而且结果看起来干净，因为它还没有遇到旧系统已经处理过的任何情况。

替代方案可能是正确的选择。但如果你跳过了对旧系统的理解，你就扔掉了它所知道的东西，包括还没有人注意到的事情，比如你在错误地使用一个工具。

GitHub 的替代品就是一个很好的例子。很多人用智能体构建了一个，它们看起来不错，直到遇到 GitHub 花了多年才搞定的复杂性。有一个不同，那就是Cursor 的 Origin。其 Git 存储背后的工程师 Vicent Martí 在 GitHub 工作了多年，研究这些确切的问题。正如他在他的文章中所说，Origin 是“构建这些相同系统的数十年经验的成果”。

更早地捕捉到它

把发现过程移回起点的办法之一，是把知识放进代码库里，这样人们就不必随身携带它。Lauren Tan 最近关于一个月内提交 2,500 个 pull request 的演讲主要讲的就是这件事。她把自己对系统的了解编码进类型、lint 规则和工具里，这样智能体就能在没有她的情况下安全工作。

我认为 Lauren 的做法大体上是对的，大多数团队都应该多做一些。但它只能捕捉到有人想到要去捕捉的东西。我对我们系统的很多了解来自对话——与同事、供应商、客户的对话——而这些对话并没有完全进入代码库。也许这些可以更好地记录下来，但这些对话往往有很大的开放性，使它们不太像文档，而更像笔记。当别人使用它们时，它们会受益于后续追问。

一条简单的规则

Sean 在文章结尾说，设计系统的人应该对系统是否有效负责。Mitchell Hashimoto 就与智能体协作提出了类似的观点。如果你提交了一项改动，你应该能够不借助智能体就向同事解释清楚。我认为他的挑战中最重要的部分在于，它拉进了另一位同事。向了解这个系统的人解释一项改动，正是有价值的后续追问和缺失信息浮现出来的时候。