Preface

On August 3, 2026, David Crawshaw, co-founder of exe.dev and co-founder of Tailscale, published an article titled Devtools must be open source on the official blog. The post quickly topped the Hacker News hot list, garnering over 500 upvotes and more than 190 comments. Developers including Simon Willison also reposted and expanded on the ideas on their personal blogs.

Crawshaw’s core argument is straightforward: When AI Agents can directly read source code, modify it, and automatically rebase upstream updates, the decades-old customization paradigm of “plugin API + configuration files” is being replaced by a more fundamental capability—the source code itself is the extension system. For developers choosing IDEs, terminals, or Coding Agents, this is not a philosophical debate, but a practical selection issue.

From “Config Modifications” to “Source Code Modifications”

In the article, Crawshaw reviews a long-standing phenomenon: Most engineers spend their days coding with tools written by others, but rarely write programs for their own use. Occasionally, someone uses a static site generator to build a blog or modifies an editor theme via plugins, but the time cost of forking Vim or VS Code just to add a single line to “display line numbers by default” is prohibitive for nearly everyone.

AI Agents have changed this calculation. Crawshaw presents two reusable Agent prompt templates:
1. Personalized Initialization: Pull the source code of a software, compile and install it locally; inform the Agent that all future modifications will be made directly to the source code; record the motivation for each change in version control.
2. Continuous Upstream Sync: Use cron to schedule regular execution—pull upstream updates, rebase local changes onto the latest version, replace the current installation after verifying functionality.

The key is not “being able to modify code”, but that the Agent can automatically manage fork and upstream synchronization. In the past, forking a tool and returning to maintain it a year later was a nightmare; now models can handle rebasing, compiling, and smoke testing, reducing both the fixed and ongoing costs of customized software.

Case Study: Comparison of Shelley, meat.dev, and VS Code Extension API

Crawshaw uses his own products for two specific demonstrations.

Shelley is an open-source Coding Agent launched by exe.dev. Crawshaw’s team has integrated the two prompt templates mentioned above into built-in Skills of the Agent: Users do not even need to manually configure cron, and can simply say “Change Shelley’s UI to high contrast” to complete the customization.

meat.dev is Crawshaw’s personal side project: It uses an LLM to filter out “noise lines” in Git diffs (such as imports, nil-checks, and boilerplate error handling), allowing human reviewers to focus only on the “meat” (architecture and business logic). He hopes meat will preprocess diffs in the background when Shelley creates a commit, rather than running commands manually in the terminal.

The prompt he gave the Agent roughly translates to: Integrate meat.dev into Shelley; install it to PATH; start meat in the background to process diffs when Shelley creates a git commit; add a toggle switch in the Diffs view; prompt the user to wait during processing.

One prompt is all it takes. Crawshaw specifically contrasts this with the VS Code Extension API: To trigger background LLM preprocessing at the exact moment a commit is created, the extension system’s mount points rarely align. A more realistic solution might be to spin up a separate meatd daemon to monitor the filesystem, then have the extension read from the cache. It can be done, but the “curvature” is far steeper than directly modifying Shelley’s source code.

This is the fundamental difference he describes: Classic customization is limited by the shape exposed by the API; Agent customization is limited by whether you have access to the source code.

Divide Between Open-Source and Closed-Source Agents

The latter half of the article extends the discussion from editors to Coding Agents themselves.

Crawshaw believes that the Skill techniques demonstrated on Shelley can be applied to other open-source Agents, such as Pi; open-source versions of Codex can theoretically do the same, albeit with higher token overhead. He even asks: Does Pi still need a built-in extension system? The source code is the extension system.

Claude Code is cited as a counterexample: It is closed-source, and users cannot ask the Agent to modify its core behavior, only work within the hooks and configuration options provided by the vendor. “Hope your needs happen to fall within their hooks; otherwise, switch to an Agent that can be personalized.”

In the top Hacker News comments, Simon Willison expressed similar sentiments: Previously, cloning a project and compiling it had such high friction that he often gave up; now he asks Codex or Claude Code to checkout and build, and returns ten minutes later to check the results. He has not yet gotten used to “modifying the software he uses every day”, but the path forward is clear.

Community practices support this: One developer uses AI to maintain a personal fork of the Ghostty terminal—just to add a graphical settings page, instead of manually modifying configuration files; another maintains private forks of about six tools, using Agents to rebase upstream changes and selectively contribute bug fixes back upstream.

At the same time, opposition is equally sharp: Merge conflicts remain a reality for fast-moving projects after forking; “AI slop PRs” make upstream maintainers less willing to merge contributions; the value of plugin systems lies in shareable, maintainable customization boundaries, not everyone maintaining their own private fork. Crawshaw himself acknowledged in replies that platforms with significant hosted-side capabilities like exe.dev still face issues with product pacing and self-hosting barriers when going fully open-source.

Zed, Ghostty, Cursor: Three Coordinates on the Selection Map

The original article did not name Zed or Ghostty specifically, but Hacker News discussions and developer community practices have filled out this map more completely.

Zed is an open-source, Rust-built high-performance editor that built AI collaboration into its product narrative from its inception (such as directions like DeltaDB). Under Crawshaw’s logic, Zed falls on the side where “Agents can fork, modify the UI, and connect to private workflows”.

Ghostty is a terminal emulator initiated by Mitchell Hashimoto, which intentionally keeps itself simple and plugin-free. The community’s response is exactly a living example of Crawshaw’s argument: Someone has forked Ghostty, used an Agent to keep it synchronized with upstream, and added a built-in settings page; others like Henry Chen use Ghostty + tmux to run Agents, and Zed for diff reviews—splitting the toolchain by role, choosing open-source components for terminals and editors that are composable and hackable.

Cursor represents another path: It is a closed-source AI IDE with high integration and a great out-of-box experience, but its core behavior and model routing are controlled by the vendor. If your customization needs exceed official capabilities, you cannot “modify the core logic with one sentence” like you can with Shelley’s source code, and will have to wait for the roadmap or switch tools.

This is not to say closed-source tools have no value—Claude Code still performs strongly in many benchmark scenarios, and many teams mix Copilot, Cursor, Claude Code, and open-source Agents. Crawshaw emphasizes that when Agents become daily drivers, “the ability to modify source code” shifts from a nice-to-have to a first-class requirement.

Practical Takeaways for Developers

Crawshaw’s thesis can be condensed into three sentences:
1. Personalization costs have plummeted: Agents handle reading code, modifying code, rebasing, and compiling; maintaining a private fork alone shifts from “irrational” to “daily feasible”.
2. Plugin APIs have relatively depreciated: This is not to say plugins are useless, but the upper limit of “impossible if the API shape does not match” is raised by the open-source + Agent combination.
3. Hidden locks in closed-source DevTools: This is not to say you should fork today, but that vendors are betting you will never exercise the right to “modify the core”; this bet deserves reevaluation in the AI era.

When choosing DevTools in 2026, ask one extra question: If an Agent could modify its source code next week, can I access its source code? Tools where the answer is no are not unusable, but you should be clear that what you are buying is “configuration space”, not “logic space”.

Open-source DevTools have gained, not moral superiority, but structural choice in the era of AI personalization. Debates will continue—fork maintenance, licenses, upstream slop, non-forkable hosted subsystems are all real constraints. But the direction is clear: Source code access rights are becoming part of the competitiveness of a new generation of developer tools.