Why AI coding agents mean devtools must be open source
A blog post on blog.exe.dev argues that AI coding agents have collapsed the cost of personalizing software, and that this makes open source code a requirement for developer tools rather than a nicety. The author recalls that five years ago, most engineers they asked had never written software for themselves: building and then maintaining a personal tool took real effort, so most people made do with off-the-shelf programs. The author says that has changed because two prompt patterns now do the work an engineer used to do by hand. The first: download the source of a program, build it locally, and treat any future change as an edit to that source rather than a workaround. The second: run a nightly job that has an agent fetch upstream changes, rebase local modifications on top, check that the result still works, and swap it in. If the agent itself is open source, these two prompts can be packaged as a skill, so a user does not need to write code at all, just ask for what they want. The author built this into their own editor, called Shelley: typing a request like 'make Shelley's UI high-contrast' is enough to personalize it.
The author illustrates the idea with meat.dev, a side project worked on over the past month. It is a tool that feeds a code diff to an LLM to strip out lines the author no longer needs to review by hand, such as import blocks, nil checks, and routine error handling, so review time goes to the substantive changes. The author says that over the past six months, their own review habits shifted: models have become reliable enough at rote correctness that edge-case checking is no longer where review time is best spent, and attention has moved to architecture and unexpected behavior instead. Wanting meat.dev built into Shelley's diff view rather than run separately on the command line, the author used a single prompt: install the latest meat.dev, run it in the background whenever Shelley creates a commit, add a toggle to the diff view, and show when a commit is still being processed. The prompt produced the working feature; the one hitch was that the model chose a meat emoji for the toggle button.
From there the post generalizes: before agents, it made sense for complex software such as Vim to ship with large configuration files, extension APIs, and plugin systems, because the cost of understanding and modifying the underlying code was too high for any one user to bear alone, so it was worth sharing that cost across many users. With that cost now much lower, the author argues a top-end agent can usually add a single-user feature in one shot, and that for single-user software, careful review can often be replaced by checking whether the result seems to work. On that view, personalized software no longer needs a config file or plugin system: to change a font size, an agent can find and edit the hardcoded value directly, or even generate a new bitmap font with a tool like Monobit. The author extends the argument to teams too, asking why a team would buy and configure a rigid task manager, CMS, or CRM when they can assemble just the features they want. The author's own blog is built this way, in Shelley, using libraries such as Tiptap pieced together rather than a ready-made publishing product.
The post ends on where agents diverge. The same skill-based personalization applied to Shelley, the author says, works just as well on other open-source agents such as Pi, to the point that the author questions why Pi needs a built-in extension system at all, since the source code already is one. It could also be applied to Codex, which is open source, though the author notes it would take a lot more tokens. Claude Code is the exception: because it is closed source, users cannot personalize it this way, and are limited to whatever customization hooks it ships with. The author's advice is to hope your needs fit those hooks, and if they do not, switch to an agent whose source is open.
Key facts
- Two reusable prompt patterns, downloading and editing a program's source, and a nightly job that rebases local changes onto upstream, are what the author says has made personalizing software cheap; if the agent is open source, both can be packaged as a skill.
- The author built meat.dev, a tool worked on over the past month that uses an LLM to strip boilerplate such as imports, nil checks, and error handling out of diffs, and added it to their editor Shelley with one prompt covering background processing and a diff-view toggle.
- The author says their code-review focus shifted over the past six months, from checking edge cases models now handle reliably to architecture and unexpected behavior.
- The post argues personalization removes the need for config files and plugin systems in software like Vim, since a top-end agent can typically add a single-user feature in one shot and 'does it seem to work' can replace careful review for single-user code.
- The same technique works on open-source agents like Pi and, with more tokens, Codex, but not on closed-source Claude Code, whose users are limited to its built-in customization hooks.
Why it matters
The post's core claim is that AI coding agents have changed the economics of software personalization enough to flip a long-standing tradeoff. The author spent years finding that writing software for themselves rarely paid off: time was scarce, and maintaining a personal tool after a year away was painful. The claim is that agents now do both the writing and the ongoing maintenance, through source edits and automated rebasing against upstream, which is why the author frames open source access to a program's code as the precondition for personalizing it at all.
Who it affects
The post speaks to developers who use coding agents day to day, and to the makers of developer tools who choose whether to keep their source open or closed. It names specific tools throughout: Shelley, the author's own editor, built to accept personalization prompts directly; meat.dev, the author's diff-simplifying tool; Pi and Codex, open-source agents the author says the same technique applies to; and Claude Code, called out by name as the closed-source exception where users cannot personalize the agent this way.
How to use it
The post describes two concrete prompt patterns. The first: tell the agent to download a program's source, build it locally, and treat future changes as edits to that source, recording the reasoning in version control. The second: set up a nightly job with a prompt that fetches upstream changes, rebases local modifications on top, verifies the result works, and replaces the running version. If the agent is open source, both prompts can be bundled into a skill so a user only has to ask in plain language, such as the author's example, 'make Shelley's UI high-contrast.'
How solid is it
The piece is a first-person blog post recounting the author's own experience building and personalizing Shelley and meat.dev. It cites no external data, benchmarks, or other sources, no author name appears in the text, and no usage or adoption figures are given for either tool. The argument rests on the author's own anecdotes and reasoning about how agent-driven development has changed, not on measured or independently verified evidence.
Risks and caveats
The post does not say how many devtools makers might actually open source their products, or offer any timeline for that happening; the argument is a prediction and a personal appeal, not a reported trend. The author also flags a small rough edge in their own example: the agent's automated pass chose a meat emoji for a UI toggle without being asked to. Applying the same technique to Codex is noted as requiring a lot more tokens than doing it for Shelley, and Claude Code users are not entirely locked out of customization, only limited to whatever hooks the closed-source agent already provides.
“The source code is the extension system.”
— the author, on why open-source agents like Pi do not need a built-in extension system