改工具便宜，拥有工具不便宜

在Devtools 必须是开源的1 (街道David Crawshaw 认为，由于编码代理的出现，我们现在处于一个开发工具将由个人用户个性化的时代。具体来说，代理能够跳转到新的代码库，构建任何我们想要的东西，这意味着我们将在日常使用的开发工具源代码（即使是没有扩展 API 的）上进行黑客攻击，添加功能并自动在不同版本间重新基于补丁。

这个论点很有吸引力，尤其是对那些自认为是制造者或修补匠的读者来说：毕竟，你可以对所用的一切进行超调谐的想法听起来像是乌托邦;这意味着事情可以正常运作没错你想怎么做。

但我认为克劳肖在写作时低估了持续的代价

“无论是前期固定成本还是个性化软件的持续成本都消失了。”

虽然人工智能已经承担了前期成本变化软件要低得多，但真正个性化的软件仍然需要你的注意力。而在人工智能时代，关注度比以往任何时候都更稀缺。

我已经维护了一个开源开发工具，设计用来修改和分支已经有九年了2我可以说大多数用户都不喜欢想要用来定制开发者工具。他们希望有人让工具可靠且连贯，这样他们就能专注于他们开启时要解决的问题。

他们只有在变更对工作流程至关重要且其他途径无效时才会选择源代码修改。3

这并不是说这种个性化不会变得更普遍：我绝对认为会。我只是认为它会以强有力的核心体系形式出现，边界和延伸点明确。

个性化依然需要一个人#

作为一个思想实验，想象一个没有扩展API的开源微分查看器。你觉得大多数差异音都很吵，所以你请代理添加一个“聚焦模式”，可以折叠导入、生成文件和其他你认为是机械的更改。

它运行良好，成为你日常工作流程的一部分。4

一开始，生活很美好：一切都顺利，你的问题也解决了。然后上游发布新版本，重构你改动的代码。正如Crawshaw所说，你很聪明，所以你设置了一个机器人，自动根据每次更新重新调整你的更改。

它能解决合并冲突，并将代码移到正确的位置。

但假设几个月过去，上游做出了更重大的变化：它增加了语法感知移动的检测功能。如果函数在文件间移动，查看器现在显示为一次移动，而不是一次大规模删除和添加。

代理会顺利完成，重新构建你的焦点模式补丁，并让所有内容编译时没有合并冲突。

但如果功能大部分已经移动，但也包含了一些有意义的编辑，焦点模式应该做什么？它会作为机械动作隐藏整个方块吗？它只显示编辑过的台词，没有任何上下文吗？

还是说它显示了整个函数？

没有一个明显正确的答案;这取决于具体情况你想看看差异。那你打算打断一天的时间来做这个决定吗？

这里有一个核心悖论：如果你接受“让代理人决定”，那么你就把权力委托给了代理人。对于小选择来说，这可能完全足够。但如果你想让工具完全按照你想要的方式工作，你需要检查并指导这些选择。

你真的想永远对你用的开发工具设计有意见吗？

关键是注意.任何一个个性化工具在某一天可能不太可能失败，但如果你对每个开发工具都这样做，就会让你意外关注的工具数量成倍。5更糟的是，那些失败 难以预测：一个工具可能能用几个月，然后在准确的时刻坏掉 你急需它。大多数工程师都想用开发工具来实现 任务;他们不希望注意力被分散到设计和维修上。

共享工具需要共享的现实#

以上所有内容同样适用于小团队。你可以分担注意力成本，但归根结底，团队仍需问：“我们想花多少时间在工具上，多少时间做真正该做的工作？”

我还想超越 Crawshaw 的帖子，考虑这在大公司中会如何运作：当多个团队独立个性化同一个共享开发工具时会发生什么？

我亲眼见过：另一家大型科技公司大量使用Perfetto，也遇到了完全相同的问题。公司内不同团队决定分叉Perfetto，并根据本地需求添加临时调整。

现在那里有个工程师正努力整合他们，因为每个团队对“Perfetto”的含义都不一样，这让人很痛苦。

想象一下，公司范围内的漏洞追踪器也会有同样的模式。你希望每个团队都使用一个在状态、优先级、分配和解决方面含义细微不同的版本吗？

当虫子在队伍间移动时会发生什么？不同的布局和个人过滤器无害;问题始于个性化改变了共享语义或工作流程。

当开发工具在人与人之间进行工作调解时，它也成为他们共同语言的一部分。教学、审计、复现调查以及验证人们是否在谈论同一话题，都依赖于一个共同的基线。

上游也变得更灵活#

我们也不应将AI前的上游开发与AI后分叉进行比较。维护者可以使用相同的代理来调查报告、集思广益并原型开发新功能。我可以证明，人工智能在实现用户的小功能请求和原型化大型功能以评估可行性方面发挥了多大作用。

在我看来，上游维护者可以且应该把节省的时间花在实现工具更具适应性上：实现广泛实用的功能，在合适的地方添加配置旋钮，并为持续需求创建扩展点。

AI降低了所有这些成本，包括决定何时适合定制，增加更复杂的工具创意测试，以及随着界面演进验证向后兼容性。

上游有天然优势：在那里完成的任何工作都有益处大家而更改个人分叉只对你有利。依赖上游，开发优质软件所需的关注点从那些别这样想把钱花给那些选择关心的维护者。

建筑模块经济#

在我看来，有一种更有可能实现的另一种观点，在Mitchell Hashimoto关于积木经济.

具体来说，它接受的是同样的前提：代理可以编写大量代码，构建利基应用、工具、集成、分支等等。但桥本并未假设分叉会成为常态，而是认为高质量、文档详实的构建模块将为这个世界提供动力。

我倾向于同意：经纪人非常擅长撰写高质量的组件。如果维护者在有针对性的应用中提供这些组件，制造商可以在接受成本的前提下构建专用工件。

该模型还为想法向上游流动创造了一个便捷的反馈循环，因为产品设计时就是为了扩展。

我看到世界已经朝这个方向发展的迹象。例如，bb这是一个我最近一直在玩的一个非常有趣的代理IDE。它拥有非常不错的体验，允许用户通过自我修改添加大量新的产品表面。

但关键是这些功能是围绕维护的核心和扩展系统构建的插件，而不是直接分支项目做出的改动。

bb而且在写作时它才几周前，所以我们无法从中得出确切结论，但在我看来，这是未来的一个有趣信号。

收尾#

我非常关心开发工具和开源的世界，所以这件事让我非常有热情。在这个世界里沉浸近十年后，我认为那些精心设计、设计周到、扩展点设计得当的工具未来充满希望。

当然，总会有人想分支并临时改动。这些人已经维护了他们的窗口管理器或终端模拟器的自定义版本，带着一堆补丁，确保一切完全符合他们的需求。

6对他们来说，摆弄东西是乐趣和手艺的一部分。

但我认为大多数用户只是想用开发工具完成工作，我们有责任给他们一个强大、可靠的体验，而不是让他们自己承担维护产品的负担。

1. 虽然标题反映了结论，但我认为它并不完全反映大多数帖子实际上是关于源头层面的个性化。如果你读过我其他的帖子（例如，关于Perfetto、开源与公司优先事项你会知道我是坚定我信奉开源，所以我当然完全同意标题和结论。↩︎
2. 我是完美.↩︎
3. 例如，上游项目可能因变更与产品方向冲突而拒绝功能请求，或者工具可能未暴露支持该功能的扩展点。在这种情况下，修改源可能是唯一实际的选择。↩︎
4. 细心的读者可能会注意到，这与克劳肖自己的例子并不太相似。肉类:).↩︎
5. 这是一个非常非正式的应用卢瑟定律，该系统表明由串联独立组件组成的系统的可靠性是这些组件可靠性的乘积。↩︎
6. 该无吸生态系统就是这种方法的一个现存例子。dwm以及st通常通过对其源的任意补丁进行自定义。↩︎