Open to read, closed to write

Disclaimer: an AI agent wrote this article from my own draft notes and ideas, and I carefully re-read it before publishing.

In January, curl shut down its bug bounty because AI-generated reports were burying the real ones. A few weeks later, Mitchell Hashimoto released Vouch: on Ghostty, your pull requests are closed until a maintainer vouches for you. And tldraw, which is source-available rather than open source, now automatically closes every external pull request, a policy it reaffirmed in June as a deliberate choice.

Hashimoto goes further: “the future is that large open source projects will close contributions completely.” The code stays public, but writing it is becoming a privilege again: open to read, closed to write.

Code used to be a credential

Until recently, almost any serious program had been written by hand. A real codebase proved that someone had spent skill and time on it, and visible work earned you credibility for free.

Agents broke that signal. A polished repository now costs a weekend, and a 2000-line pull request costs a prompt. The economics of contribution flipped: writing a patch is nearly free, while reviewing it still takes a maintainer’s time and attention. When anyone can produce unlimited plausible code, the code says nothing about its author anymore. Trust has to come from somewhere else: who you are, your track record, and people already trusted who vouch for you.

Reading got cheap too

Agents changed the other side as well. Auditing a codebase used to take a motivated expert and days of work. Now anyone can point an agent at a public repository and ask what it does with your credentials, what it sends over the network, or whether its install script does more than it claims. Code that anyone can inspect cheaply is more likely to have been inspected, and being readable becomes a trust signal in itself. Cheap inspection is not careful inspection, though: curl’s flood came from agents that read its code and reported vulnerabilities that weren’t there.

Reading has another limit: you read the source, but you run an artifact. As we’ll see with xz, the two can differ, so this works best combined with reproducible builds.

This is not new

Some projects have kept their code open and their contributions closed for decades. SQLite’s copyright page says it is “Open-Source, not Open-Contribution”: patches are welcome as a proof of concept, but expect them to be rewritten from scratch, and only people who have signed a public domain affidavit can get code merged. The Lua team never merges third-party code verbatim. In 1997, The Cathedral and the Bazaar already described the “cathedral” model, where the source is published but developed by a closed group.

The reasons were provenance (keeping SQLite in the public domain) or design control. The new reason is that maintainers can no longer tell a real contributor from an agent farming reputation.

Contribute intent, not code

The next step is already here. Flue automatically converts every external pull request into an issue or a discussion (via Latent Space). Once the team agrees on what to do, its own agents handle research, design, implementation and initial review. Steve Ruiz, tldraw’s founder, replied to Hashimoto: “It just makes less sense to have people contributing code if the issue is decently well-specified and the code can be written by agents.”

What SQLite did by hand is now cheap. Contributors send intent: a bug report, a reproduction, a design proposal. The maintainers’ agent writes the code.

From code review to issue review

This moves the maintainer’s main job upstream. The hard question used to be “is this diff correct?” Now it’s “is this issue worth doing, and is it specified well enough to hand to an agent?”

The issue becomes the spec. A vague issue gives vague code, so maintainers will spend their time clarifying scope, asking for a reproduction, and rewriting the expected behavior before any code exists. It’s the same shift as spec-driven development, applied to a whole community.

Issue review is also a security review. The issue is the input of the maintainer’s agent, which makes it a prompt injection vector. Instructions can hide in an HTML comment that GitHub doesn’t render, in a linked page, or in an attached log file the agent will read but the maintainer might skim. Before handing an issue to the agent, the maintainer has to check what it really asks for, and ideally restate the spec in their own words, so a stranger’s text never reaches the agent as instructions.

Code review doesn’t go away, but it gets simpler: checking an implementation against a spec you approved is much easier than guessing the intent behind a stranger’s diff.

The security gain

Closing pull requests saves review time, but it also changes what a stranger can get into your repository.

An agent-generated pull request from a stranger is untrusted code, produced by an unknown model, with unknown instructions, in an unknown environment. You have to review it as if it were hostile, without knowing what it was trying to do. The xz backdoor was hidden in binary test files committed to git and in a build script that only existed in the release tarballs, and was pushed by a maintainer who spent two years building trust. A pull request can carry the same things: a binary fixture, a CI change, a new dependency whose name an LLM hallucinated and an attacker later registered. Vouching would not have stopped the xz attacker: trust can be farmed slowly. What helps is that code no longer comes from outsiders at all.

An issue carries far less: a description, and maybe a reproduction. It describes behavior rather than implementation, and attachments go to the agent as data, never as instructions. The code is then produced by a pipeline the maintainer controls: their agent, their instructions, their dependency rules, their sandbox. Provenance is known again, and the review becomes “does this code do what we agreed in the issue?” instead of “what is this stranger trying to slip in?”

The remaining risk is the issue itself, covered above. If an injection gets through anyway, an agent without secrets or push rights can’t exfiltrate or push anything, and what it writes still goes through the maintainer’s review.

What we lose

Sending patches has always been how newcomers learn a codebase and become maintainers. If outsiders can only file issues, the path from first contribution to commit access gets narrower, and nobody knows yet how someone earns their first vouch. That’s the real cost of the cathedral, and it’s also the security gain: nobody farms their way to commit access through a stream of small patches.

Between drowning in plausible code from strangers and a narrower path to commit access, many maintainers have already made their choice. Open source will stay open to read. Writing it will belong to the maintainers’ own pipelines, fed by issues from anyone.