The Imperative for Open Source Devtools

By David Crawshaw (Adapted from exe.dev)

Historically, a strange trend existed among software engineers: most of them didn't actually write software for their own personal use.

While trying to determine how Tailscale could integrate into the daily workflows of developers, I noticed that engineers spent their entire professional lives using tools created by others to build products for other people. While we might tweak a .yaml config or install a plugin, truly bespoke software—like a custom-built home automation system or a hand-coded blog—was a rarity. Most people just settled for a "close enough" static site generator or a commercial Zigbee hub.

The Maintenance Trap

For a long time, the $\text{ROI}$ (Return on Investment) of writing personal software was abysmal.

$\text{ROI} = \frac{\text{Personal Utility}}{\text{Development Time} + \text{Maintenance Burden}}$

The "Maintenance Burden" was the killer. Between the chaos of professional life—~~everything was fine~~ $\text{Something Was Wrong At Work}$ —and the sheer agony of returning to a year-old personal project to fix a breaking change, many of us simply gave up. I spent years of my career stripping my environment down to the most basic, standard tools possible. In my early days at Google, I didn't even own a personal computer.

A New Paradigm: Agent-Driven Personalization

Today, the barrier to personalizing software has collapsed. AI agents have transformed the process into two primary categories of instructions:

1. The Initial Setup

Download the software's source code.
Compile it for local execution.
Instruct the agent to remember that any future modifications must be applied to the source and then redeployed.
Commit the reasoning behind these changes to version control.

2. The Maintenance Loop

The real magic happens when you automate the upkeep via a nightly cron job:

Key Insight: Agents don't just write a quick hack; they manage the entire lifecycle of synchronizing local forks with upstream releases. This shifts the ROI because starting is easier and staying updated is automated.

If the agent itself is open source, these instructions can be baked directly into its "skills" (text-based instructions). We implemented this in Shelley. Now, instead of complex configuration, you can simply say: make Shelley’s UI high-contrast, and the agent handles the source modification.

Case Study: Integrating `meat.dev` into Shelley

I've been developing a project called meat.dev. The premise is based on how my role as a code reviewer has evolved.

The Evolution of Reviewing:

Past: I spent 20 years hunting for edge cases, nil checks, and error handling.
Present: LLMs are now more diligent than humans at "rote correctness." They rarely miss a nil-check.
The Problem: I'm now wasting time reading boilerplate code that is almost certainly correct.

I created meat.dev to use LLMs to strip away the "fat" (imports, standard error handling) from diffs, leaving only the meat (architecture and logic).

The Integration Challenge

I loved the tool, but it had two flaws:

It ran in a terminal (I prefer Shelley's UI).
It took a few minutes to process, and I hated waiting.

Instead of spending days writing a complex plugin, I gave Shelley a single prompt:

Please build meat.dev into Shelley. When a git commit is created by Shelley, 
start meat processing in the background. If the commit is still being 
processed, notify the user.

The Result: Shelley integrated the tool and automated the background processing. The only "error" was the agent's decision to use a 🥩 emoji for the toggle button.

Comparison: Classic vs. Agent Personalization

Feature	Classic Customization (e.g., VS Code API)	Agent-Driven Personalization
Implementation	Writing boilerplate for a specific API	Natural language prompts
Integration	Limited to provided extension points	Direct modification of source code
Complexity	High (requires `meatd` daemon/cache)	Low (agent understands the logic)
Speed	Weeks of development	Seconds/Minutes

If I had tried to do this via a traditional API, I would have faced a "convoluted misery" of trying to force the extension's shape to fit my needs. With an open-source agent, the software simply evolves to fit the user.