Agent Night demo recap: exe.dev — your agent can rewrite the software you use
David Crawshaw of exe.dev showed how two prompts let an agent customize any open source tool you use, then keep those changes rebased on upstream nightly.
Configuration files are a dying interface. That's the argument David Crawshaw brought to the first lightning demo at Agent Night — the event formerly known as MCP Night — on August 12 at the Regency Ballroom in San Francisco.
Crawshaw is co-founder and CEO of exe.dev and was previously co-founder and CTO of Tailscale. What he brought was less a product demo than a problem thrown over the wall: if your users can now rewrite your software themselves, what happens to the software they can't rewrite?
Configuration is over
Crawshaw opened by asking the room to raise a hand if configuration had been part of their life: editing a config file, setting font sizes, building a custom environment. About half the room did. He put himself in that group, then took himself back out of it. He'd spent years on heavily customized setups and eventually threw them all away to go back to defaults.
His claim is that the whole category is ending, not because configuration stopped being useful, but because nobody wants to keep learning what options their software exposes when they can just change the software instead.
If a program is open source, editing it to fit your environment is now trivial. Shipping that same change as professional, serious software still takes real effort, but hacking it up for yourself takes typing a sentence.
The two prompts
The demo ran inside Shelley, the coding harness Crawshaw uses, though he was clear that the technique applies to agents and software of every kind. The setup is two instructions to an agent sitting next to the program, or to the program itself when the program is the agent.
- Go grab the software: download it, build it, put it somewhere, modify it to do the thing you want, and keep a record of what you did.
- Set up a nightly cron job, a systemd timer or equivalent, that downloads the latest version of the program and rebases all of your changes on top.
That's the whole setup. Give the second instruction once, and after that you just feed in the changes you want.
The nightly rebase is the new part
Crawshaw's point of emphasis was that the second prompt is what changed in the last three months of model capability. A year ago, models could write code perfectly well, but they couldn't reliably work through merge conflicts. Now they can.
That distinction is the difference between a fork and a personalization. A patched binary you built once and can never update is technical debt with a shelf life. A patch set that survives upstream releases without your attention is a supported configuration, just one you wrote in English rather than in someone else's config schema.
Shelley rebases itself
exe.dev built the pattern into its own product, which Crawshaw said takes a couple of hours of work for anyone else who wants to do it. Ask Shelley to change itself, and the automatic upgrader that runs every night detects the customizations sitting on top and handles the rebasing for you. Shelley ships inside every exe.dev VM, the cloud Crawshaw described as being "for you and your agents to run as many VMs as you need to get things done".
The demo version of this is cosmetic: tell it to make it pink and the entire harness changes color scheme. The useful version isn't. His own team has added buttons to Shelley that run their CI — the same two-prompt pattern applied to a shared environment instead of a personal one. Personalizing your own setup is fun; an internal tools team shaping the environment an entire team works in is a different job entirely.
The open source dividing line
Then the demo turned into a problem. You can point this at Codex. You can point it at pi. You can't point it at Claude Code, because it isn't open source. You can ask an agent to download Chromium and adjust your browser to behave the way you want, then keep it current, and that works. You can't do it to Chrome itself, because Google adds enough on top that recompiling isn't practical.
Once you start personalizing your open tools, Crawshaw argued, you start asking why you're still using the closed ones. He put the question to a room full of people who build software for a living: why would your customers choose your unpersonalizable software over a competitor they can personalize?
The payroll problem
His own example was payroll. The software works, it gets the numbers right and understands all 50 states, and the web interface is, in his words, the worst ever. He doesn't want to touch the per-state calculation logic. That's exactly the kind of problem he wants to pay a vendor to own.
What he wants is the seam. Give him an API and he'll build the interface he actually wants on top of it. The first payroll company that does is the one he switches to.
The parts of your product a customer can reach are the parts they can make their own. The parts they can't reach start to look like a choice you made against them. The answer isn't open sourcing everything, because Crawshaw was clear he doesn't want to own the hard domain logic. It's drawing the line honestly: keep the part that's genuinely hard to get right, and expose everything above it through an API an agent can drive.
Watch the demo as and the entire event: