Devtools must be open source

开发工具必须开源

Five years ago, most software engineers I spoke to had no programs they had written for themselves. (I was asking this question a lot as part of trying to understand how Tailscale could fit into engineers’ lives.) All day, every day, engineers use programs written by others to write programs for others. Many of us customized the programs we used, through config files or plugins or extensions, and many of us used the programs we wrote for others, as users. It was always an unusual treat to ask someone what they had written for themselves and learn about the bespoke software behind their blog, or their home automation, or their homelab, instead of an off-the-shelf, almost-the-right-size static site generator or Zigbee appliance.

五年前，我交谈过的大多数软件工程师都没有为自己编写过程序。（我经常问这个问题，是为了了解 Tailscale 如何融入工程师的生活。）工程师们每天都在使用他人编写的程序来为他人编写程序。我们许多人通过配置文件、插件或扩展程序来定制所使用的工具，也有许多人作为用户使用自己为他人编写的程序。询问某人他们为自己写了什么，并了解他们博客、家庭自动化或家庭实验室背后的定制软件，而不是使用现成的、勉强够用的静态网站生成器或 Zigbee 设备，这总是一种难得的乐趣。

This state of things made a lot of sense to me. Over the years I have written plenty of software for myself, and the return on doing so was always questionable. I could only write so much in a day. There were always more important things to do (Something Was Wrong At Work), and coming back to a project after a year to do maintenance on it was always extraordinarily painful. There were plenty of years in my career where I had thrown out all my custom software and used the most bog-standard environments I could to produce code. In my early years as an engineer at Google I did not even own a personal computer. That was then. Things are different now.

这种状况对我来说很有道理。多年来，我为自己写过不少软件，但这样做的回报总是令人怀疑。我一天能写的代码有限。总有更重要的事情要做（工作中总有各种问题），而且在一年后回来维护一个项目总是极其痛苦的。在我的职业生涯中，有很多年我抛弃了所有定制软件，转而使用最标准的环境来编写代码。在谷歌担任工程师的早期，我甚至没有个人电脑。那是过去。现在情况不同了。

How to Personalize Software

如何个性化软件

It is astonishingly easy to personalize software today. There are two general categories of prompts to an agent that make all of this possible:

1. Download the source for and build it for local use.
2. Modify to know that any future changes to this software mean changing the sources and replacing the current version.
3. Record in version control the original motivation behind the change. and, more importantly: Set up a nightly cron job that executes the prompt: fetch upstream changes to the and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version.

如今，个性化软件变得异常简单。通过向智能体（Agent）发送两类提示词，这一切都成为可能：

1. 下载 <软件> 的源代码并构建以供本地使用。
2. 修改 <智能体使用的任何记忆>，使其知道未来对该软件的任何更改都意味着修改源代码并替换当前版本。
3. 在版本控制中记录更改背后的原始动机。 更重要的是： 设置一个每晚执行的 cron 任务，执行以下提示：获取 <软件> 的上游更改，并将所有本地更改重新基于上游进行变基（rebase）。检查软件是否按预期工作并替换当前版本。

At the heart of this is the realization that agents can not only hack up some code for a specific use but also automatically manage the process of synchronizing changes with upstream releases. This means agents change the ROI on customizing software on two fronts simultaneously: it is much easier to get started personalizing, and much easier to keep going.

其核心在于意识到，智能体不仅可以为特定用途编写代码，还可以自动管理与上游版本同步更改的过程。这意味着智能体在两个方面同时改变了定制软件的投资回报率（ROI）：开始个性化变得更容易，持续维护也变得更容易。

Another astonishing thing about the two prompts above for editing software is that you can build them right into an agent. As long as the agent is open source, it does not even require programming. The two prompts can be loaded into a skill (i.e., some text instructions) put somewhere discoverable to the agent. We built this into Shelley, so now if you want to edit Shelley you don’t even need the preamble or to configure the timer. It takes care of it for you. You can type in a prompt like “make Shelley’s UI high-contrast” and you have personalized your agent.

关于上述两个编辑软件的提示词，另一个令人惊奇之处在于，你可以直接将它们构建到智能体中。只要智能体是开源的，甚至不需要编程。这两个提示词可以加载到一个技能（即一些文本指令）中，并放在智能体可发现的地方。我们将此功能内置到了 Shelley 中，所以现在如果你想编辑 Shelley，甚至不需要前言或配置计时器。它会为你处理好一切。你只需输入类似“让 Shelley 的 UI 变为高对比度”这样的提示，你就完成了对智能体的个性化。

A Worked Personalization Example: Shelley and Meat

个性化示例：Shelley 与 Meat

I have a personal project I have been idly toying with for the last month: meat.dev. The principle is that while agents write code, I still read it before pushing to our serious systems. As the underlying models improve, what I look for has changed. The humans I have spent twenty years reviewing code for have always struggled with edge cases: do the errors report useful information; are nil-checks handled, etc. (We all do it; when writing code, I am one of the worst offenders.) One of my roles as a reviewer was looking for these details. Over the past six months, I have discovered I don’t need to read for edge cases like that any more: models are far more diligent than humans at rote correctness. Their errors are isolated to architecture, unexpected use cases, visual output their test environment is not feeding back to them, etc. This means most of the lines of code I review are not very useful. So I wrote a tool that takes diffs and uses LLMs to strip out the unimportant stuff. I almost never need to see the import blocks, or the nil-checks, or the error handling any more, so get it off the screen so I can focus on the meat. I like this tool, but it has two downsides: first, I like to read my diffs in Shelley with a good UI, not in a terminal. Second, it takes a couple of minutes for an LLM to digest and minimize a diff, and I don’t want to wait.

我有一个过去一个月一直在闲暇时摆弄的个人项目：meat.dev。其原理是，虽然智能体编写代码，但在推送到我们的核心系统之前，我仍然会进行阅读。随着底层模型的改进，我关注的内容也发生了变化。我花了二十年时间审查代码，人类总是难以处理边缘情况：错误报告的信息是否有用；空值检查是否已处理等。（我们都会这样；在编写代码时，我就是最糟糕的罪魁祸首之一。）作为审查者，我的职责之一就是寻找这些细节。在过去六个月里，我发现我不再需要检查这些边缘情况了：模型在机械正确性方面比人类勤奋得多。它们的错误仅限于架构、意外用例、测试环境未反馈给它们的视觉输出等。这意味着我审查的大部分代码行都没什么用。所以我写了一个工具，它获取 diff 并使用 LLM 去除不重要的部分。我几乎不再需要看导入块、空值检查或错误处理，所以把它们从屏幕上移走，这样我就可以专注于“肉”（核心内容）。我喜欢这个工具，但它有两个缺点：首先，我喜欢在 Shelley 中通过良好的 UI 阅读 diff，而不是在终端中。其次，LLM 消化和最小化一个 diff 需要几分钟，我不想等待。

So ideally I would not run meat on the command line, but have it built into Shelley and have it pre-processing commits the moment they are created. It turns out I can do that with a single prompt: “Please build meat.dev into Shelley. Install the latest version in the PATH. When a git commit is created by Shelley, start meat processing in the background on the commit. Add a toggle to the Shelley Diffs view for meat. If the commit is still being processed, so the user it is in process.”

因此，理想情况下，我不应该在命令行运行 meat，而是将其内置到 Shelley 中，并在提交创建的那一刻就对其进行预处理。事实证明，我可以通过一个简单的提示词做到这一点： “请将 meat.dev 构建到 Shelley 中。在 PATH 中安装最新版本。当 Shelley 创建 git 提交时，在后台对该提交启动 meat 处理。在 Shelley 的 Diffs 视图中为 meat 添加一个开关。如果提交仍在处理中，请告知用户正在处理。”

This single prompt was all it took not just to add meat to Shelley, but to appropriately pre-process commits in the background before I came back to session to review the diff, saving me waiting for a model to reduce the diff. The only unfortunate choice the model made was using the 🥩 emoji for the toggle button. Imagine the convoluted misery it would be trying to plug that into the VS Code extensions API! Or trying to get it into vimdiff. It would certainly be possible, but the machinery to start pre-processing the commits as soon as they appear would be nigh-on impossible. I would be better off implementing an out-of-band meatd that listened to the file system and provided a cache for the meat tool that a customization API could use, because the points of extension and configuration would not be the right shape. And that is the fundamental difference between classic configuration/customization and agent-driven personalization: you can do so much more. The agent will do the hard work of understanding the source and changing it to suit the particular task you.

仅仅这一个提示词，不仅将 meat 添加到了 Shelley 中，还在我回到会话审查 diff 之前在后台适当地预处理了提交，省去了我等待模型精简 diff 的时间。模型唯一不幸的选择是使用 🥩 表情符号作为切换按钮。想象一下，如果试图将其插入 VS Code 扩展 API 会是多么复杂和痛苦！或者试图将其集成到 vimdiff 中。这当然是可能的，但要在提交出现时立即开始预处理的机制几乎是不可能的。我最好实现一个带外（out-of-band）的 meatd，监听文件系统并为 meat 工具提供一个定制 API 可以使用的缓存，因为扩展和配置点将无法以正确的方式呈现。这就是经典配置/定制与智能体驱动的个性化之间的根本区别：你可以做的事情多得多。智能体将完成理解源代码并将其更改以适应你特定任务的艰苦工作。