⏱️ Lectura: 11 min
An AI agent can clone the repository of your favorite terminal editor today, compile it with a custom theme, and leave a cron job running every night so it never falls out of sync with the original project. That’s what David Crawshaw, founder of exe.dev and former co-founder of Tailscale, describes in an essay that argues something concrete: if a devtool isn’t open source, it loses the race against those that are, because only open source code lets an agent modify it and keep it in sync without constant human help.
📑 En este artículo
TL;DR
- David Crawshaw, founder of exe.dev and former co-founder of Tailscale, published an analysis on why devtools must be open source in the age of agents.
- The core pattern uses two reusable prompts: one clones and compiles the tool for local use, the other schedules a nightly sync with upstream via cron.
- The author’s own agent, Shelley, packages both prompts as a skill that can be invoked with no prior setup.
- Closed-source software can’t apply this pattern because it doesn’t expose the source code needed to fork or rebase.
- The shift reduces two historical frictions of customizing software: the upfront cost of modifying it and the cost of keeping it up to date.
- The main risk is maintenance debt: an automatic rebase can introduce conflicts that the agent resolves poorly if no one reviews them.
- Original source: blog.exe.dev, article “Devtools must be open source.”
Introduction
For years, customizing the software you use every day was a luxury almost no one indulged in. Crawshaw recalls that five years ago, when he was studying how Tailscale fit into engineers’ workflows, most of them didn’t have a single program written for themselves. Everyone used third-party tools to build software for other people. The reason wasn’t lack of interest: it was simple math. A developer’s time is finite, and keeping a personal fork up to date with every upstream release competed directly with real work.
That math has changed. Coding agents don’t just write the initial patch; they can also run, unsupervised, the repetitive work of pulling in upstream changes, resolving trivial conflicts, and verifying that everything still works. That’s the underlying argument behind open source devtools as a precondition, not an ideological preference.
What happened
On his blog, Crawshaw describes two types of instructions (prompts) that sum up the whole pattern. The first is the bootstrap prompt: ask the agent to download a tool’s source code, compile it for local use, and record the original motivation for the change in version control. The second is the maintenance prompt: a nightly cron job that asks the agent to pull in upstream changes, rebase the local changes on top, verify the software still works as expected, and replace the current version.
What’s notable isn’t the idea itself (forking and rebasing is as old as Git), but that this synchronization work, which used to demand constant human discipline, can now be fully delegated. And if the agent itself is open source, there’s no need to write any code at all: the two prompts are saved as a skill, a text file with instructions, somewhere the agent can find it. The author built this directly into his own agent, Shelley, so customizing Shelley no longer requires copying the preamble or setting up the timer: asking for the change in natural language is enough.
Context and history
Customizing development tools isn’t a new concept. Config files, plugins, and extensions have existed for decades precisely to allow some flexibility without touching the source code. VS Code has a huge extension API; Vim and Neovim have decades of plugins; shells get customized with dotfiles. But those extension surfaces are always limited to whatever the original author decided to expose.
Crawshaw himself admits that, for much of his career, throwing away his customized software and going back to standard setups was the most reasonable decision. In his early years at Google, he didn’t even have a personal computer. The maintenance cost of a homegrown fork, reviewed by hand a year after abandoning it, was “extraordinarily painful” (as he describes it in his original post). That maintenance pain is exactly what the second prompt, the nightly cron one, aims to eliminate: it turns periodic rebasing into a background task, not an obligation the developer remembers (or, more often, forgets) with every release.
Technical details and performance
The pattern rests on two pieces that any team with a coding agent (Claude Code, or another with shell and git access) can reproduce today. The technical key is that both pieces are simple plain-text prompts, not new software.
The customization prompt
This handles the bootstrap: clone the repository, apply the requested change, compile it, and record why it was done. Saved as a skill, it looks like this:
---
name: customize-tool
description: Fork, compile, and prepare an open source tool for local use
---
When the user asks to customize a tool:
1. Clone the official repository into ~/dev/forks/<tool>
2. Apply the requested change and compile it for local use
3. Record the original motivation for the change in the commit
4. Replace the binary the user uses daily with the compiled oneWith that skill saved, asking the agent something like “make the zellij interface high contrast” triggers the whole flow without the developer writing a single line of configuration.
The sync prompt
This is the piece that makes long-term maintenance viable. In practice it’s a script the agent runs from a cron job, against a real fork of an open source project:
#!/usr/bin/env bash
set -euo pipefail
cd ~/dev/forks/zellij
git fetch upstream main
git rebase upstream/main
cargo build --release
cp target/release/zellij ~/.local/bin/zellijAnd the crontab entry that triggers it every night:
0 3 * * * ~/.config/agent/sync-zellij.sh >> ~/logs/sync-zellij.log 2>&1If the rebase fails due to a real (non-trivial) conflict, the script stops because of set -e and the previous binary stays in use: the user never ends up with a broken version at 3 a.m.
Verification: to confirm the sync ran last night, just check the log and the hash of the last rebased commit:
tail -n 20 ~/logs/sync-zellij.log
git -C ~/dev/forks/zellij log -1 --onelineFlow diagram
flowchart TD
A["Developer requests customization"] --> B["Agent clones the repository"]
B --> C["Agent compiles local version"]
C --> D["Nightly cron triggers sync"]
D --> E["Agent fetches and rebases upstream"]
E --> F["Verifies it builds and works"]
F --> G["Replaces the binary in use"]
G --> DThe following table compares the agent-managed fork pattern against the two classic customization alternatives:
| Approach | When to use it | Advantage | Limitation |
|---|---|---|---|
| Official plugin or extension | The tool exposes a stable extension API | Doesn’t break with every release | Only allows what the original author anticipated |
| Manual fork, maintained by hand | The change doesn’t fit the extension API | Full control over the code | Every upstream update requires hours of manual rebasing |
| Agent-managed fork | The project is open source and the change is limited in scope | The agent syncs and resolves trivial conflicts on its own, every night | A non-trivial conflict requires human review before trusting the rebase |
💭 Key point: the whole pattern depends on a single precondition: that the source code exists and has a license that allows forking. Without that, not even the best agent can apply the second prompt.
How to get started / try it
To reproduce the pattern with an agent like Claude Code on any real open source devtool (for example zellij, the terminal multiplexer written in Rust), the steps are:
- Install the agent:
npm install -g @anthropic-ai/claude-codeon Linux and macOS, or the equivalent installer on Windows via WSL. - Fork it: add the real upstream remote,
git remote add upstream https://github.com/zellij-org/zellij.git, so the sync prompt has something to rebase against. - Save the skill: create the file with the customization prompt in the agent’s skills folder (for example
~/.claude/skills/customize-tool/SKILL.md). - Schedule the cron job: add the crontab entry shown above, pointing to the sync script.
- Request the change in natural language: “make zellij always start in high contrast mode” is enough to trigger the whole flow the first time.
Impact and analysis
Crawshaw’s argument has a direct competitive consequence: a closed devtool can’t offer this level of customization without building, on its own, an extension layer equivalent to an agent with access to the code. That’s far more expensive than simply publishing the repository under an open license and letting the agent ecosystem do the rest.
The advantage isn’t just for the end user. It also changes which open source project maintainers receive contributions: if customizing your own fork no longer requires maintaining it by hand, more developers try out changes they would have previously dismissed due to maintenance cost, and some of those changes end up as pull requests to the original project.
But the pattern has an honest cost that shouldn’t be understated. An automatic rebase that runs without human supervision can introduce a poorly resolved, silent conflict that only surfaces when the customized binary fails in production. The author’s own example acknowledges this indirectly: the only “unfortunate” decision the agent made while building a new feature was picking an overly playful emoji for a button, a minor mistake, but it illustrates that the agent makes design decisions without asking permission. For trivial changes (visual themes, keyboard shortcuts), the risk is low. For changes that touch security or networking logic, an unreviewed nightly rebase is a bad idea.
⚠️ Heads up: automating the nightly rebase of a fork running in production, without anyone reviewing non-trivial conflicts, can introduce silent regressions. The script should fail safely (leaving the previous binary active) instead of blindly replacing it.
What’s next
If the pattern catches on, expect shared skill repositories to appear for syncing forks of popular tools, further reducing the friction of customizing a specific devtool. It’s also likely that some closed projects will respond by exposing deeper agent APIs (commit-level hooks, not just configuration ones) to avoid losing ground to their open source equivalents. The underlying tension, between open licenses and a vendor’s control over its product, will determine which categories of devtools survive this transition without losing users to open alternatives.
📖 Summary on Telegram: View summary
Try it yourself: add an upstream remote to a fork of an open source tool you use daily and ask your agent to set up the nightly sync script shown above.
Frequently Asked Questions
Does this pattern work with any open source tool?
It works best with tools that build reproducibly from source (Rust, Go, C) and have licenses permissive enough for personal use of the fork. Tools with complex builds or private dependencies require more manual tweaking of the script.
What happens if the nightly rebase fails?
With set -euo pipefail, the script stops at the first error and the previous binary stays in use. The agent can also notify the user at the next login instead of failing silently.
Do you need to know how to code to apply this?
Not for the basic use case: both prompts can be requested in natural language. Knowing how to read the diff produced by the rebase is still useful for changes that aren’t purely visual.
Why can’t closed-source software replicate this?
Because the second prompt depends on having the source code available to fetch, rebase, and build. Without source, an agent can only automate the configuration the vendor exposes, not the tool’s internal behavior.
What’s the biggest risk of this pattern?
That a non-trivial rebase conflict gets resolved incorrectly and no one notices until the tool fails at a critical moment. That’s why it’s best reserved for narrow changes (themes, shortcuts, small features) and not for sensitive logic.
References
- Devtools must be open source: David Crawshaw’s original post on the exe.dev blog describing the two-prompt pattern.
- Fork a repo, GitHub Docs: official guide on how to fork and sync a repository with its upstream.
- Claude Code, official documentation: reference for the agent used in the skill and automation examples.
- Cron, Wikipedia: background on the task-scheduling mechanism used for the nightly sync.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
0 Comments