By ByteBot
David Crawshaw published something this week that 573 Hacker News points found worth arguing about: developer tools should be open source, because AI agents can now personalize them directly by modifying source code. No plugin APIs. No settings.json. Just a prompt. The argument is not new — the economics are. And they shift the stakes for every developer choosing tools in 2026.
What Actually Changed
The case against forking a devtool has always been maintenance. Diverge from upstream and you own the diff forever — every release means reconciling your changes manually. That math kept most developers inside whatever extension ecosystem their editor provided, however clunky.
AI agents changed the math. Crawshaw’s argument rests on two capabilities that are real right now: an agent can document your local changes in version control as you make them, and a nightly process can rebase those modifications against upstream automatically. He demonstrates this with meat.dev, a diff-filtering tool he integrated into the open-source Shelley agent with a single prompt — something VS Code’s extension API would have required elaborate workarounds to accomplish.
It is not theoretical. HN commenter spullara writes: “I now have a fork of Ghostty that is kept up to date with AI and automatically triages and PRs issues.” That is a custom terminal, maintained by an AI agent, running modifications that no closed extension system would allow. Personal computing, circa 2026.
The Counterarguments Are Serious
The HN discussion did not just applaud. The critics landed real punches.
The efficiency argument: replacing config files with AI-driven source modification burns compute every time someone wants to tweak a keybinding. Traditional configuration exists precisely to avoid this. Crawshaw’s vision does not make configuration systems obsolete — it supplements them, and the distinction matters when you are scaling to thousands of developers with different preferences.
The maintainer crisis is the sharpest counterpoint. Research published this year confirms what maintainers have been saying for months: 67% report AI-generated PR volume as a significant burden, and AI-generated PRs have 1.7 times more issues than human-written ones. The cURL project ended its bug bounty program in January 2026 after AI submissions drove valid-submission rates to roughly 5%. If open source devtools succeed and developers start forking them routinely, some portion will also start sending upstream PRs — generating more noise for already-stressed maintainers.
The reliability question is real too. Nightly AI rebasing sounds clean in a blog post. In practice, it means an automated actor rebuilding your tools every night without meaningful spec validation. Crawshaw says it works for him. Whether it works at scale, across dozens of tools, for developers who are not ex-Google engineers — that remains unproven.
Why This Lands Now
The timing is not coincidental. The devtools market is mid-flip. The JetBrains Developer Ecosystem survey in early 2026 showed GitHub Copilot at 29%, with Cursor and Claude Code tied at 18% each. IdeaPlan’s survey has Claude Code at 28%, Cursor at 24%. Every major IDE now ships agent capabilities. When tools converge on features, the differentiator becomes modifiability.
Crawshaw names Claude Code explicitly as a closed-source tool that limits personalization — a pointed observation, given Claude Code’s current standing with professional developers. Meanwhile, Zed gets implicitly praised: open-source, written in Rust, AI built in from the ground up rather than bolted on. Ghostty, Shelley, Theia IDE — the open-source agents and editors where you can type a prompt and change the tool itself, not just configure it.
JetBrains is pitching “independence” as a feature — the only major IDE vendor not enmeshed with a cloud provider or an AI company. That is a different kind of openness argument, and it is landing with enterprise buyers tired of vendor lock-in. According to The New Stack, the devtools market is sorting itself around this axis faster than most expected.
The Verdict
Crawshaw is right about the direction. The economic case against forking has weakened significantly, and open source devtools give developers a real option that closed tools categorically cannot. The personalization upside is not hypothetical — developers are already doing it.
But the transition is messier than the blog post admits. Most developers will not maintain nightly AI rebases. Maintainer burnout from AI-generated contributions is a genuine problem that a “everyone should fork everything” culture will intensify. The approach works well for motivated engineers with time to debug when the nightly rebase breaks something.
The practical takeaway: when evaluating devtools in 2026, weight open-source access as a first-class requirement — not because you will fork today, but because the option now carries genuine value. Closed tools are betting you will never exercise it. That is a bet worth questioning.
