What does exe.dev's "Devtools must be open source" post actually argue?

That AI coding agents remove the two costs which used to make personalizing a dev tool irrational: the cost of building the customization and the cost of keeping it in sync with upstream. The post's example has an agent build a small diff-preprocessing feature from one prompt and auto-rebase it against nightly upstream releases.

What did Simon Willison add to the discussion?

He reframed open source's classic pitch — freedom to read and modify code — as something that was technically available but rarely used, since reading and safely changing unfamiliar code took more time than most programmers could justify. He argues LLMs are the first thing to make that freedom practically usable, describing his own habit of asking an agent to clone a repo and explain how a specific part works.

Does this mean teams should avoid closed-source coding tools like Claude Code?

That's exe.dev's stronger claim, contrasting Claude Code against agents like Shelley, Codex, and Pi — but it's a contested position, not a settled one. The safer takeaway is narrower: reading or patching a dependency's source is no longer the extraordinary effort it used to be, regardless of which agent you use to do it.

Vibecoding & AI-Assisted Development3 August 20264 min read

Why exe.dev Says Devtools Must Be Open Source — and Willison Agrees

A Hacker News debate over exe.dev's 'devtools must be open source' argument turned into something sharper: LLMs have made reading and modifying other people's code cheap enough that the old open-source promise finally works as advertised.

By TRAGenX Desk

Key takeaways

exe.dev argues devtools must be open source because coding agents can now personalize a tool AND keep that personalization in sync with upstream via automated rebasing — removing the two costs that used to make forking irrational.
Simon Willison's response reframes open source's classic 'freedom to read and modify the code' pitch: for most programmers it was always theoretical, and LLMs are the first thing to make it practical.
exe.dev draws a contested line between agents built in the open (Shelley, Codex, Pi) and closed tools like Claude Code, claiming closed tools box users into whatever hooks the vendor shipped.
The practical shift for teams: patching or reading a dependency's source is no longer an extraordinary measure — it's a prompt away, which changes how much you should tolerate an opaque tool.

Open source has always sold itself on a freedom most people never used: the right to open the hood and change how your software works. A Hacker News thread around an exe.dev post titled 'Devtools must be open source' argued that AI coding agents finally make that freedom worth exercising — and Simon Willison's reply is the more interesting half of the conversation.

The old pitch, and why it mostly didn't pay off

Willison's framing is blunt: the freedom to read and modify code has, in practice, been "more about being able to lean on other people to do that." Reading an unfamiliar codebase and safely modifying it is a real time cost, and most programmers — even experienced ones — couldn't justify paying it for tools they only used, not maintained. Open source's core promise was technically true and practically unused for the average developer.

What exe.dev is actually proposing

The exe.dev post goes further than "agents can write code for you." Its argument is that agents remove the *two* costs that made personalizing a tool irrational: building the customization, and keeping it alive as upstream changes. The author describes personalizing their own agent setup — building a preprocessor (referred to as meat.dev) that flags architecturally significant lines in a diff — from a single natural-language prompt, then having the agent keep that local change rebased against nightly upstream updates automatically. No plugin API, no maintained fork, no drift.

Willison's read: reading code just got cheaper

Willison's own habit backs this up from the reading side rather than the modifying side. He describes prompting something like "clone x/y from GitHub and tell me how Z works," then checking back once the agent has cloned, built, and explored it. His specific line is worth keeping: getting unfamiliar software to even *compile* "used to be enough friction that I often wouldn't bother." That friction — not unwillingness to read code — was the real gate, and it's the one agents remove first.

The open-vs-closed fault line, and its weak spot

exe.dev's sharper claim is that this argues *for* open-source coding agents specifically — naming Shelley, Codex, and Pi as agents built in the open, against Claude Code as the closed counterexample. Their point is that a closed agent's customization is bounded by whatever hooks its vendor decided to ship, while an open one can be re-architected by the same agent that runs it. It's a real distinction, but it assumes your local fork stays mergeable release after release — a bet that holds for a one-person preprocessing script and gets harder to trust the deeper the customization goes.

Why this matters beyond the thread

Set aside which specific agent brand wins that argument — the underlying shift is the one worth carrying into your own team's calculus. "We'd have to read/patch the dependency's source" used to be a legitimate reason to avoid a tool. That reasoning gets weaker every quarter agents get better at cloning, building, and explaining a codebase in ten minutes. It doesn't mean fork everything — it means the bar for tolerating an opaque tool just moved.

FAQ

Frequently asked questions

What does exe.dev's "Devtools must be open source" post actually argue?: That AI coding agents remove the two costs which used to make personalizing a dev tool irrational: the cost of building the customization and the cost of keeping it in sync with upstream. The post's example has an agent build a small diff-preprocessing feature from one prompt and auto-rebase it against nightly upstream releases.
What did Simon Willison add to the discussion?: He reframed open source's classic pitch — freedom to read and modify code — as something that was technically available but rarely used, since reading and safely changing unfamiliar code took more time than most programmers could justify. He argues LLMs are the first thing to make that freedom practically usable, describing his own habit of asking an agent to clone a repo and explain how a specific part works.
Does this mean teams should avoid closed-source coding tools like Claude Code?: That's exe.dev's stronger claim, contrasting Claude Code against agents like Shelley, Codex, and Pi — but it's a contested position, not a settled one. The safer takeaway is narrower: reading or patching a dependency's source is no longer the extraordinary effort it used to be, regardless of which agent you use to do it.

Sources

Devtools must be open source (exe.dev) — Simon Willison's Weblog
Devtools must be open source — exe.dev
Devtools must be open source | Hacker News — Hacker News