Willison: LLMs turn open source from theoretical freedom into daily workflow

Simon Willison published a short comment on the HN debate around the exe.dev essay "Devtools must be open source". He is not doing PR for a sandbox vendor. He describes how the practical value of open code changed for him once Claude, Codex, or Claude Code sit next to the repo.

The classic end-user open-source pitch is that you may read and modify the code. Willison notes that even experts mostly lived a different reality. Freedom usually meant leaning on other people, because few can justify the time to read and patch tools they use every day.

Clone, explain, build is no longer a half-day project

Willison says that several times a day he asks plain Claude chat to "Clone x/y from GitHub and tell me how Z works". Getting a project to compile used to be enough friction that he often would not bother. Now he treats it as near zero time cost: tell Codex or Claude Code to check out and build X, then come back ten minutes later.

That is a concrete workflow shift, not abstract model praise. Open source stops being mainly an archive for people with a free weekend and becomes material you can interrogate in the middle of a workday.

Why this changes the price of closed devtools

The exe.dev essay argues that developer tools should be open because personalized software is arriving. Willison adds the missing mechanism: LLMs lower the cost of actually exercising that freedom.

For teams buying AI coding agents, IDE plugins, or sandbox hosting, the purchase question shifts. Not only "can it generate code", but "when the tool fails, can I tear it open, fork it, and let an agent find the regression". A closed black box with a silent issue tracker is worse in this regime, because expectations of fast fixes rise while the path inside disappears.

Forks get easier; maintenance still hurts

Willison is explicit that he is not yet habitually modifying the software he uses. He can see a path that did not exist a year ago. The HN thread also surfaces the other side: forks with a custom plan mode or small hacks appear quickly, yet keeping them against a fast-moving upstream remains hard work.

So LLMs do not solve contributor politics or maintainer willingness to take AI patches. They solve entry friction. Anyone who confuses "I can read it" with "I can maintain a long-lived fork" buys the same pain as before agents, only with a prettier demo.

The signal that separates rhetoric from adoption

Watch three things. First: whether major devtools (agents, sandboxes, local runtimes) actually ship permissive source, not only a marketed open-core kernel. Second: whether ordinary patches and forks grow from people who never touched foreign repos before. Third: whether companies start treating open-source devtools as lock-in insurance, not only a recruiting perk.

Lilith's verdict

A license on GitHub stops being an abstract promise. It becomes a permission slip for an agent that unpacks someone else's tool overnight and shows you where the data flows.