今年二月，我给自己定下了一条规则：我不再手动编写代码。我已经遵循这条规则六个月了。这个系统存在于我的头脑中。在2024年，AI出现之前，我的超能力是知道整个系统的工作方式，尤其是其不同组件之间的接口。如果有人来找我想要构建的功能或试图修复的bug，我通常可以指给他们确切的代码行，并告诉他们需要改变什么。我还记得为什么那些奇怪的决策存在，以及哪些假设从未被记下来。这是我在代码库中工作数月和数年积累的知识。这是来之不易且无价的。它让我快速地构建功能，更重要的是，安全地构建。代价是我必须跟上所有事情。随着更多人参与进来，我花费越来越多的时间阅读变化，只为维持那种心理模型。更大的代价是输入。每次我想构建什么东西时，我可以在脑海中看到代码。我只是无法快速地将其输入出来。输入速度只是问题的一部分：一个功能几乎从来不是一次编辑。即使是小的改变也跨越了多个层次，并涉及处理程序、模式、测试和文档。而这些编辑并不平等：一个坏的处理程序可以被回退，但一个坏的迁移可能会留下麻烦。因此，手动编写代码意味着安全地通过它所触及的每个地方携带一个决策。Copilot 自动补全立即提供了帮助：文档注释变成了初稿，虽然通常是错误的，但总比编辑一个空文件好。Cursor 的标签补全更有帮助。模型显然快速改善了。Claude Code 发生了巨大的变化。我只需描述一次变化，代理就会同时编辑一堆文件。结果，我输入的内容大大减少。但输入少并不意味着工作少：我会阅读模型生成的每一项变化，将其与我脑中的期望状态进行匹配。代理仍然会经常出错，并进行不必要的更改。增量工作使它们保持在轨道上。这意味着手动编辑一些生成的代码。毕竟，我仍然要对合并的每一行负责。模型不可能承担责任。然后，今年年初，模型突然变得非常出色，几乎是同步的。GPT-5.3 和 Opus 4.6 突然能够处理更大的更改，调控也减少，结果终于足够好，可以建立在其上。因此在二月我定下了这个规则：不再手动编写代码。如果一个代理陷入困境，我不能自己完成代码。我必须弄清楚代理缺少什么——而是修复那个。我不是通过阅读编程书籍来提高编程能力的。我是通过编写大量代码，运行它，看到它失败，修复它，然后再做一次。毕竟，AI 代理只是软件。我不可能通过阅读提示指南来理解它们。我必须在实际工作中使用它们，看到它们失败，改变提示、工具或环境，然后再试一次。这个规则迫使我得到了这些经验。我打破了它一次，持续三分钟。我打开代码并写了几行，感觉很好。我想念这个。直到我意识到我仍然有多少要输入。我立刻放弃了。一位代理变成了十几个。一旦我停止自己输入代码，我开始发现这些空闲时间的口袋。我会给一个代理一个任务，然后在它工作时我没有什么可以做的。与其等待，我就启动了另一个代理去做其他事情。然后我又这样做了一次。我并不是故意构建一个并行系统。我只是填补任务之间的时间。我有多动症。我很容易分心。想象一下，如果你把一个开发箱共享给同事会发生什么。现在想象他们不彼此交谈，并且他们都在同时工作。这就是我的第一次并行设置。代理改变了相同的文件和 Git 状态，安装依赖项，争夺端口，并留下运行的进程。我还得协调每个代理何时可以测试、推送或部署。更糟的是，我通常会等到运行时间最长的代理才能让其他人向前推进。我启动了更多代理以避免等待，并不知怎么创建了一种新的等待方式。我问朋友和同事他们是如何处理这个问题的，每个人都有一个解决方法。首先提到了工作树。每个代理都有自己的检出和分支，源冲突大多消失，但工作树只解决了 Git 部分。代理仍然共享数据库、端口、进程以及其他资源。所以人们用 AGENTS.md 修补这个问题：使用随机端口，创建临时数据库，避免触及另一个代理的进程。每个冲突都变成了另一条指令，而代理在弄清楚如何不相互干扰的过程中消耗了上下文，而不是完成任务。容器更加接近：独立端口、进程和本地状态。但边界是漏的：无论我的笔记本可以访问什么，容器也可能会访问。因此，破坏半径……