Maintainers are drowning, and the review queue is the bottleneck nobody funds

The cost of producing a plausible contribution collapsed. The cost of evaluating one did not. Banning agents is the wrong control and it will not hold, because the problem was never the tool. It is that nobody can tell how many humans are on the other end.

Monday morning, forty seven open pull requests

Picture a maintainer of a widely used library. Not a famous one, just one of the few thousand packages that quietly sit underneath everything. She has a day job. She has maintained this thing for nine years, mostly on Sunday evenings, and until recently the queue on a Monday held maybe three items, one of which was a typo fix from someone she recognised.

This Monday there are forty seven. She opens the first. It is well formatted. It has a clear title, a description with bullet points, a changelog entry, and a test. It touches the retry logic. It looks, at a glance, like the work of a competent contributor who read the code.

It takes her twenty minutes to work out that it is wrong. Not obviously wrong, which would have been a mercy. It is subtly wrong in a way that would surface as an intermittent failure under load in about one deployment in fifty, because the author, whoever or whatever the author was, did not understand why the existing backoff was calculated the way it was. There is a comment three functions away that explains it. The comment was not in the context window.

She writes a careful reply explaining the reasoning, because that is the kind of maintainer she is. The reply takes another ten minutes. Half an hour gone, on the first of forty seven.

Nobody paid for that half hour. Nobody will pay for the next twenty three either. This is the part of the story that gets lost in the arguments about whether AI generated code is any good: the code might be excellent, and the queue would still be underwater, because the constraint was never the supply of patches. It was always the supply of review.

What happened to open source contribution in 2026?

Three events, in order, tell the story better than any statistic.

curl closed its bug bounty

In January 2026, the curl project moved to end its bug bounty programme, which had run on HackerOne for years. The change landed as a commit to the project's bounty policy, and the reasoning given by lead maintainer Daniel Stenberg centred on a sustained flood of low quality vulnerability reports, a significant proportion of them generated by language models, arriving faster than a small security team could triage them.

Read that carefully, because the detail that matters is easy to skim past. curl did not close the programme because it was attacked. It closed the programme because the cost of deciding whether it was being attacked exceeded what seven or so people could absorb. The security programme of one of the most widely deployed pieces of software on earth was ended by triage load.

HackerOne reported that the same tooling was finding real bugs

Here is the complication that any honest treatment has to sit with. Over the same period, HackerOne reported a large year on year increase in valid vulnerabilities found with AI assistance across its platform, with figures discussed publicly in the range of a doubling or better.

So the tooling is not noise. The tooling is genuinely productive and genuinely noisy at the same time, and those two facts are not in tension, they are the same fact. A generator that produces plausible security reports produces more true ones and more false ones, and the true ones are worth a great deal while the false ones cost a human hour each to dismiss. If you ban the generator you lose the true positives. If you do not, you drown. That is the actual dilemma, and any post that pretends otherwise by picking one half is not worth reading.

Projects started restricting rather than banning

In early 2026 the Ghostty project, maintained by Mitchell Hashimoto, updated its contribution policy to restrict AI generated contributions to pre approved issues and to existing maintainers. Other projects made comparable moves through the year. Commentary during 2026 described very large volumes of agent opened pull requests arriving on GitHub, with a high proportion characterised as noise, and while the specific counts circulating came from individual analyses rather than platform disclosures and should be treated as directional, the direction was not disputed by anyone maintaining anything.

Notice the shape of the Ghostty policy, because it is smarter than a ban and it points at the answer. It does not say AI is forbidden. It says: contribution is now gated on a prior relationship. Pre approved issues and existing maintainers are both proxies for the same underlying thing, which is a known, accountable person. The policy is reaching for identity and is forced to approximate it with process.

Why did the review queue break now?

Because of an economic relationship that held for thirty years and then stopped, quietly, in about eighteen months.

Every open contribution system is a trade. The submitter spends effort producing something. The reviewer spends effort evaluating it. Historically, producing a plausible patch to an unfamiliar codebase was expensive. You had to clone it, build it, read enough to understand the conventions, find the relevant function, and write something that compiled. That cost was substantial, and, crucially, it was correlated with quality. Someone willing to spend four hours understanding your retry logic was usually someone worth listening to.

That correlation was the filter. It was never written down, no project has it in its contributing guide, and it did most of the work of keeping review queues survivable. Effort was a costly signal, in the economic sense: expensive to produce, and expensive in a way that was hard to fake without actually doing the thing.

Generative tooling did not lower the cost of that signal. It severed it. Producing a well formatted, plausibly reasoned, test bearing pull request against a codebase you have never seen now costs a few cents and about ninety seconds, and the artefact is indistinguishable at a glance from the four hour version. Meanwhile the cost of evaluation did not move at all, because evaluation still requires a human who understands the system, and there is no way to generate one of those.

The subsidy nobody priced

Put it in plain terms. Open source contribution has always been an implicit subsidy flowing from reviewers to submitters. The reviewer donates the scarce resource, which is expert attention, and the project gets better. That trade was priced when producing a patch was expensive, and it was a good trade at that price.

The price changed by a factor of a thousand on one side of the transaction and did not change at all on the other. No system survives that without renegotiating, and almost none of them have renegotiated, which is why maintainers are quitting.

This is worth stating without moralising, because the moral framing is where this conversation usually goes wrong. Nobody involved is behaving badly. A person who uses an agent to open a fix for a bug that annoys them is doing something entirely reasonable. The tool vendor shipping that capability is doing something reasonable. The aggregate outcome is still that a volunteer somewhere is doing unpaid triage until they stop. It is a coordination failure, not a morality play.

Why do the existing controls fail?

Every mechanism currently deployed fails in the same specific way: it operates on accounts or on text, and neither is scarce.

Policies are checkboxes

A contributing guide that says "do not submit AI generated code" is enforced by asking people to confirm that they have not. It filters exactly one population, which is honest people who read the guide. It is not a control, it is a request, and it costs its most conscientious readers the most.

The Developer Certificate of Origin proves provenance, not personhood

This one deserves care, because it is the closest thing the ecosystem has to an existing answer and people reach for it immediately.

The DCO is a short statement, originally developed for Linux kernel contribution, that a contributor adds to a commit as a trailer reading Signed-off-by: Name <email>. It is a genuinely good mechanism and it does its job well. Its job is to assert that the contributor has the right to submit the code under the project's licence, which is a provenance and licensing claim.

What it is not, and was never designed to be, is evidence that a human wrote the code or that a human exists behind the name. The sign off is a line of text in a commit message. Any tool can emit it. A Contributor Licence Agreement has the same property with more paperwork. Neither answers the maintainer's actual question, which in 2026 is not "may I merge this" but "is there a person here who will answer for this if it breaks".

Bot detection is a guess, and rate limits punish the wrong unit

Heuristic detection of generated text and generated code is a probabilistic classifier in an adversarial setting, with the additional problem that false positives land on real humans who write tidily, and land hardest on non native English speakers whose prose reads as machine smooth. Meanwhile per account rate limits are defeated by the trivial expedient of another account, because accounts are free and unlimited.

The unit of rate limiting is wrong. Limiting per account limits nothing. The unit that would work is the person, and no forge can currently count people.

What would a proof of human contributor actually look like?

The proposal is narrow, and it deliberately does not try to judge code.

When a contribution is opened, the contributor confirms it from an enrolled device. What that produces is a receipt binding a person to a specific set of bytes, the head commit of the change, at a specific time. The receipt attaches to the pull request and also to the contributor's own wallet, where it accumulates into a portable contribution history that belongs to them rather than to any one forge.

Then the useful part. Because the receipt is bound to a human rather than to an account, a project can set a limit that means something: three open pull requests per person, not per login. Opening a fourth requires closing one. Creating nine more accounts achieves nothing, because all nine resolve to the same person.

And the part that makes this different from a ban. The contributor can openly declare that an agent produced the work, under their authority, by attaching a delegation. That declaration is not a confession. It is exactly what a maintainer wants to know, and today the incentives run the other way, because admitting it invites rejection while staying silent costs nothing.

{
  "type":        "contribution",
  "forge":       "github.com",
  "repo":        "acme/ledger",
  "pr":          14821,
  "head_sha":    "e3b0c44298fc1c149afbf4c8996fb92427ae41e4...",
  "contributor": "did:manav:4Kd9Rm2p",
  "assurance":   "glance",
  "generated_by": {
    "declared":   true,
    "agent":      "did:manav:agent:8Tz1Qw",
    "delegation": "dlg_01J9XR7K3M"
  },
  "signed_at":   "2026-09-12T09:14:22Z"
}

The verification a maintainer's tooling performs is short, and every line of it answers a question a maintainer already asks informally.

// 1. Is this receipt actually about this change?
assert receipt.head_sha == pr.head_sha

// 2. Is there a human at the root of the authority?
chain = resolve(receipt.generated_by.delegation)
assert chain.root == receipt.contributor
assert chain.depth <= chain.maxChainDepth
assert now() within [chain.notBefore, chain.notAfter]
assert "pr.open" in chain.scope.actions

// 3. Did that human actually sign this?
ok = ed25519_verify(published_key(receipt.contributor),
                    sha256(jcs(receipt)),
                    receipt.signature)
// Verifies offline, against a published key. No callback.

Note what the check does not do. It does not evaluate the patch. It does not detect whether a model wrote it. It answers one question, which is whether an accountable person stands behind the submission, and it answers it as a fact rather than a guess. The mechanics of the delegation object itself, including why the depth limit and the narrowing rule matter, are covered in the piece on delegation chain depth.

How reputation changes the calculus

This is the second order effect, and it is the one that actually drains the queue.

Today a maintainer triages blind. Every submission arrives with the same weight, from an account created for free, with no history that survives being blocked. There is no way to distinguish a first time contributor who will become a core maintainer from someone firing generated patches at four hundred repositories, until you have read both.

Once contributions are signed by people, history attaches to people. A contributor with forty merged changes across a dozen projects arrives with that visible. Someone who has signed a hundred rejected submissions arrives with that visible too, and no amount of new accounts detaches it, because it was never attached to the account. Maintainers can then do the obvious thing: sort the queue by the contributor's track record and review accordingly.

This is the same primitive we described for security reports and for publishing, and the fact that it recurs is not a coincidence. It is the same underlying failure appearing in three places: an act with consequences, and no way to attribute it to a person. We wrote up the publishing case in who signed the decision to publish, and the wider pattern is catalogued in the Identity Failure Map.

The objection that matters: does this shut out newcomers?

It might, and this deserves a straight answer rather than a reassurance, because it is the strongest argument against the whole idea.

Open source runs on drive by contributions. Someone hits a bug at eleven at night, finds the cause, opens a two line fix, and disappears. Many of those people become maintainers years later. Any requirement placed at the front door reduces that flow, and a project that optimises purely for maintainer load will optimise itself into irrelevance.

Three things make this tractable, and none of them fully eliminates the cost.

First, scope the requirement rather than applying it universally. Signature requirements belong on paths where the asymmetry actually bites: bounty claims, security reports, changes to release infrastructure, contributions from accounts younger than a week, and anything touching build or publish. A typo fix in documentation needs nothing. The curl situation was a bounty programme, which is precisely the highest value case, since the submitter is claiming money.

Second, enrolment must be genuinely light and must not require identity. This is where a lot of proposals in this space quietly fail, so be precise about it. Proving that you are a unique human is a different claim from proving who you are. A contributor can hold a stable pseudonymous identifier with no name, no document, and no email attached, backed by a one way key derived on their own device, where no biometric template is stored anywhere and nothing links the identifier to a legal identity. Pseudonymity in open source is not a nice to have, it is load bearing, and it protects contributors in countries where their work could put them at risk. Any design that trades it away deserves to fail, and would.

Third, unsigned does not mean rejected. The right default is a lower priority queue, not a closed door. Unsigned contributions still get reviewed, when there is capacity, after the accountable ones. That preserves the eleven at night two line fix while ensuring that the people who accept accountability get attention first. It is a queue discipline, not a gate.

What this cannot do

• It does not tell you whether the code is good. A signature is an accountability claim, not a quality claim, and a well regarded contributor can submit something broken on a bad day. Review does not go away. What changes is the order you do it in.
• A human can sign slop. Nothing prevents someone from personally signing a hundred generated patches. What changes is that the hundred accrue to one identity that they cannot discard, and the rate limit binds. It converts an unbounded anonymous flood into a bounded, attributable one.
• It needs adoption to be worth anything. A signature scheme used by one project is a nuisance for its contributors and helps nobody else. This has to arrive through forges and foundations, ideally as an extension to the sign off convention that already exists, or it will not arrive.
• Manav has not shipped a forge integration. The signing and verification primitives described here are live, and the signed code demo shows a human signature bound to a commit. A GitHub application that gates pull request intake is a proposal in this post, not a product you can install today. Anyone telling you otherwise, including us, should be corrected.
• It does not address the funding problem. The deepest issue here is that critical infrastructure is maintained by unpaid volunteers, and a better intake filter is a way to make an unfunded job survivable rather than a way to fund it. Regulation such as the European Union's Cyber Resilience Act, which introduces obligations around software with digital elements and recognises a distinct category for open source stewards, is beginning to push on this, with its main obligations phasing in over the second half of the decade. Better queue discipline does not substitute for paying people.

What to do this week

1. Measure your queue honestly. Count open pull requests, median age, and the share closed without merge over the last ninety days. If the unmerged share climbed sharply during 2025 and 2026, you have this problem and are probably describing it as burnout.
2. Time three reviews with a stopwatch. Maintainers routinely underestimate this. The number you get is the price of every submission your project accepts, and it is the number to put in front of anyone who asks why you are changing intake policy.
3. Stop asking contributors to declare that they did not use AI. It is unenforceable, it is increasingly meaningless as the tooling is built into editors, and it teaches people that the honest answer is punished. Replace it with a field where they can declare what generated the change, with no penalty attached.
4. Separate your high consequence paths. Write down which changes could realistically ship a vulnerability: build configuration, release scripts, dependency manifests, authentication code. Those are the paths worth gating first. Documentation is not one of them.
5. Adopt a per person limit even before you can enforce it cryptographically. State it in the contributing guide: three open pull requests per contributor. It is a norm today and becomes enforceable later, and stating it now starts the conversation with your community rather than surprising them.
6. Triage by accountability rather than arrival order. Review submissions from known contributors first, explicitly and openly. Most projects already do this informally while feeling guilty about it. Writing it down is fairer than pretending the queue is first in first out.
7. If you run a bounty, gate the claim rather than the report. Anyone may report. Claiming money requires a signature. This preserves open disclosure, which you want, while attaching a cost to the submissions that are motivated by payment, which is where the flood concentrated.

The signing and offline verification calls are documented in the developer documentation, and the broader argument about attributing machine produced work to an accountable human runs through what happens when one person runs hundreds of agents.

Frequently asked questions

Why did curl end its bug bounty programme? The project moved to close the programme in January 2026 after a sustained volume of low quality vulnerability reports, many of them model generated, exceeded what a small security team could triage. The stated reasoning centred on maintainer burden rather than on any single malicious submission. The programme was ended by the cost of evaluation, not by an attack.

Does a DCO sign off prove a human wrote the code? No. The Developer Certificate of Origin is a line of text added to a commit asserting that the contributor has the right to submit the code under the project's licence. It is a provenance and licensing claim, it works well for that purpose, and any tool can emit it. It makes no claim about whether a human wrote or reviewed the change.

Is the answer to ban AI generated contributions? Bans are unenforceable, they filter only contributors honest enough to read the policy, and they discard genuinely useful work, since AI assisted reporting also surfaces real vulnerabilities at increasing rates. Accountability is the better control: any contribution is welcome provided a person signs for it and accepts a limit attached to their name.

Would requiring signatures exclude pseudonymous contributors? Not if it is built correctly. Proving you are a unique human is a separate claim from proving who you are. A contributor can hold a stable pseudonymous identifier with no name, document, or email attached, derived on their own device with nothing stored centrally that links it to a legal identity. Pseudonymity is essential in open source and a design that removes it would rightly be rejected.

How many agent generated pull requests is GitHub actually seeing? Large volumes were discussed publicly through 2026, along with high estimates of the noise fraction, but the widely circulated counts come from individual analyses rather than platform disclosures. Treat specific numbers as directional. The direction is not disputed by anyone currently maintaining a popular project.

Why did Ghostty restrict AI contributions? The project updated its policy in early 2026 to allow AI generated contributions only for pre approved issues and from existing maintainers. The structure is notable: both conditions are proxies for a prior accountable relationship, which suggests the policy is reaching for contributor identity and approximating it with process because the underlying primitive is unavailable.

Does signing contributions slow down the review process? It adds seconds for the contributor and removes time for the maintainer, because the queue can be ordered by accountability rather than triaged blind. The cost falls on the person submitting, which is the correct place for it, since that is the side of the transaction whose costs collapsed.

Sources

1. The curl project repository, including the bug bounty policy history: github.com/curl/curl
2. Daniel Stenberg's blog, the primary account of the curl bounty decision and the reporting load behind it: daniel.haxx.se/blog
3. HackerOne research and reporting on AI assisted vulnerability discovery: hackerone.com/blog
4. The Ghostty project repository and its contribution policy: github.com/ghostty-org/ghostty
5. The Developer Certificate of Origin, version 1.1: developercertificate.org
6. Regulation (EU) 2024/2847, the Cyber Resilience Act, including provisions concerning open source software stewards: eur-lex.europa.eu/eli/reg/2024/2847/oj
7. Open Source Security Foundation guidance on contribution and supply chain practice: openssf.org
8. RFC 8785, JSON Canonicalization Scheme, the serialisation used before hashing a contribution receipt: rfc-editor.org/rfc/rfc8785

Do not ban the agents. Rate limit the humans, and let people say out loud which of their work a machine produced.