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.

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 <software> and build it for local use. Modify <whatever memory your agent uses> to know that any future changes to this software mean changing the sources and replacing the current version. Record in version control the original motivation behind the change.

   and, more importantly:

2. Set up a nightly cron job that executes the prompt: fetch upstream changes to the <software> and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version.

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.

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.

A Worked Personalization Example: Shelley and 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. 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.

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 have in mind. The software we live with is far more powerful with personalization. All you need is the source code.

The Age of Personalized Software

The pre-agent development costs meant it was rational for complex software to ship with large configuration files, extension systems, and plugin systems. The core code of even a moderate project like Vim is huge and baroque, and takes weeks for a human to digest. The thought that, on wanting line numbers to print by default, an engineer would learn the code base and add it just for themselves is unreasonable. Better to design it for sharing with others, which justifies the expense of implementing it by amortizing it over many users. As features in a code base grow, it makes sense to look for common abstractions where you can break out an extension or plugin system.

Now the expense of learning the code and making a change has dropped dramatically. Agents do the heavy lifting. For a single user—which implies extremely constrained conditions under which the program runs—a top-end agent can usually now add a feature in a single shot. For single-user software, the need for careful code review can often be replaced by “does it seem to work?”

The result is that software that can be personalized doesn’t need a plugin system or a config file. Want to change the font size in your text editor? Give the agent the source and tell it to. If it is a hardcoded value it will find and edit it. If it’s a hardcoded bitmap font it will download another and replace it, or it will use Monobit to make you one! You have incredible capabilities on tap.

Whole Categories of Software Products Need to Be Reinvented

Personal software applies well to small teams too. Why would an engineering team purchase an extremely configurable task manager (or a CMS or CRM), spend time learning and configuring it, and contort their team to its limits, when they can assemble just the features they want from common building blocks?

Both the upfront fixed costs and the ongoing costs of personalizing software have disappeared.

The blog you are reading is bespoke software, written in Shelley, because it was easier to piece together and personalize libraries like Tiptap than it is to try and customize traditional software products. For end-user products to make sense in a company today, they need to be personalizable. Which means we need the source code.

Where Codex and Claude Code Diverge

This same skill-based technique that was applied to Shelley to make it personalizable can be trivially applied to other open-source agents like Pi. (So much so that I am left wondering why Pi needs an extension system built into it. The source code is the extension system.) It would require a lot more tokens, but you could do the same to Codex, which is an open-source agent.

Where you would hit a wall, however, is Claude Code. It is closed-source software, so you don’t get to personalize it. There are a lot of old-fashioned customization hooks in Claude Code. Hopefully, how you want an agent to work fits in their hooks. If not, switch to an agent that lets you personalize it.