The post argues that developer tools should be open source because coding agents have changed what users can realistically do with source code. Instead of source access being a mostly theoretical freedom, a user can now ask a model to clone a repo, explain how something works, make a tweak, and even keep a fork rebased over upstream. The author goes further than the usual OSS case. He suggests that if software can be personalized cheaply by agents, many classic product surfaces like plugin systems, config files, and built-in options matter less.
That first claim landed well. Plenty of people said LLMs have genuinely lowered the friction to reading and patching tools they use, especially for one-off fixes, local features, and understanding unfamiliar codebases. Several described already maintaining personal forks with Claude or using agents to rebase patch stacks that would have been annoying before. The bigger shift is not that open source suddenly became valuable. It is that the old value proposition of inspectability and tweakability is becoming practical for far more users.
The stronger reaction was against the leap from "AI makes source code more usable" to "software no longer needs config or extension mechanisms." Readers were blunt that recompiling or regenerating software to change ordinary settings is a bad trade, even if an agent does most of the work. Config files, plugin systems, and scriptable extension points exist because they make customization cheap, shareable, testable, and easier to carry across updates. AI may make source-level changes less painful, but it does not make stable seams irrelevant.
A second fault line was maintenance. Supporters of the idea said AI makes rebasing forks and replaying patches much easier than before, especially when changes are narrow and intent is documented. Skeptics said unattended "nightly maintain my fork" workflows are exactly where agents still fail in dangerous ways. They can satisfy the prompt while quietly breaking
UX, introducing subtle bugs, or drifting from what the user actually wanted. The workable version here looked narrower. Keep a private fork for niche improvements, vendor dependencies when needed, and upgrade on your own cadence with rollback and tests.
The business angle got almost as much attention as the tooling angle. Many agreed that developers trust and prefer open devtools, but several people with experience building or running devtools companies said AI makes commercialization harder, not easier. Open sourcing the code used to leave enough friction that many users still bought hosting, support, or the polished product. If agents can now extract the useful parts or recreate "good enough" equivalents quickly, the old
open-core bargain gets weaker. That fed a broader complaint that developers are unusually unwilling to pay for tools, and that open source maintainers absorb the downside.
There was also a layer of skepticism about the messenger. exe.dev itself is a VC-backed company and parts of its stack rely on closed model providers, so some readers called the argument ironic. Others replied that this is not really a contradiction. A devtool can be open source while still offering hosted conveniences or gateways to proprietary APIs, and open models are getting good enough that the dependency on closed providers may shrink. The net result was not a rejection of the post's premise. People mostly accepted that AI has made open source more operationally useful. What they rejected was the idea that this erases the need for product architecture, shared defaults, maintainer boundaries, or sustainable economics.
blog.exe.dev