The 406 Protocol: Open Source's Answer to AI Spam Pull Requests

There's a new protocol circulating among open source maintainers. They're calling it the 406 Protocol, after the HTTP status code "406 Not Acceptable." The idea is simple: a standardized way for repositories to signal their policy on AI-generated pull requests and for automated systems to respect those signals.

It exists because open source is drowning in AI-generated garbage, and the existing tools to manage it are failing.

The Problem

If you maintain a popular open source project, you already know. The volume of low-quality pull requests has exploded over the past year. AI coding tools made it trivially easy for people to generate plausible-looking code changes and submit them to any repository.

Some of these PRs are well-intentioned. Someone used AI to try to fix a bug or add a feature, but didn't review the output carefully enough. The code compiles. The tests might even pass. But it introduces subtle issues, violates project conventions, or solves a problem that didn't need solving.

Others are outright spam. People gaming contribution metrics for their GitHub profiles. Hacktoberfest-style drive-by PRs that add comments, rename variables, or "refactor" code in ways that make it worse. Except now, instead of submitting these manually, people have AI agents that can generate hundreds of PRs across dozens of repositories in an afternoon.

The numbers are staggering. One maintainer of a popular JavaScript library told me they went from receiving about 15 PRs per week to over 200. Of those 200, maybe 3 or 4 were genuine, useful contributions. The rest were AI-generated noise that took hours to review and close.

This is the hidden cost of AI-generated code. The generation is free. The review is not.

What the 406 Protocol Does

The 406 Protocol introduces a machine-readable file (.github/ai-contributions.yml) that repositories can use to declare their policy on AI-generated contributions. It's inspired by robots.txt, the decades-old standard that tells web crawlers which pages to index.

The spec is straightforward. A repository can declare:

Acceptance policy. Whether AI-generated PRs are welcome, conditionally accepted, or rejected by default. Options range from "all AI contributions welcome" to "no AI contributions accepted" with several nuances in between.

Disclosure requirements. Whether contributors must disclose if their PR was AI-generated or AI-assisted. Many maintainers don't mind AI-assisted contributions (using AI as a tool while a human directs and reviews). They do mind fully autonomous AI-generated PRs that nobody reviewed before submitting.

Quality gates. Minimum requirements that AI-generated PRs must meet before a human maintainer will look at them. Things like: tests must be included, the PR must reference a specific open issue, the contributor must have a prior contribution to the project.

Agent identification. A field where AI coding agents can self-identify, similar to how web crawlers identify themselves via User-Agent strings. This allows maintainers to track which AI tools are generating PRs and potentially block specific agents that produce consistently low-quality contributions.

The protocol also defines behavior for AI coding agents that encounter repositories with a 406 policy. Agents should read the policy file before submitting PRs. If the policy rejects AI-generated contributions, the agent should not submit. If the policy requires disclosure, the agent should automatically add disclosure to the PR description.

Why This Matters Beyond Open Source

The 406 Protocol is interesting on its own, but the underlying problem it addresses is much bigger than open source PRs.

We're entering an era where AI can generate huge volumes of plausible-looking content across every domain. Code. Articles. Emails. Applications. Reviews. Comments. The marginal cost of generation is near zero. The marginal cost of evaluation is not.

This creates an asymmetry that existing systems aren't designed to handle. Every system that accepts user input (repositories, job applications, review platforms, academic journals, content platforms) is going to face the same flood of AI-generated submissions. The volume will overwhelm human reviewers. The quality will be uneven. And the existing signals we use to filter (reputation, effort, formatting) will become unreliable because AI output matches those signals effortlessly.

The 406 Protocol is one of the first attempts to solve this at a protocol level rather than an individual level. Instead of each maintainer independently figuring out how to handle AI PRs, there's a shared standard that both humans and AI agents can follow.

I expect we'll see similar protocols emerge in other domains. Academic journals will need machine-readable policies on AI-generated paper submissions. Job platforms will need signals about AI-generated applications. Content platforms will need standards for AI-generated media.

The Quality vs. Quantity Trap

Here's the thing that bothers me most about AI-generated code. The incentive structure is inverted.

For AI coding agents, the incentive is to maximize successful contributions. More merged PRs means more demonstrated value. More demonstrated value means more users. So agents are optimized to submit as many PRs as possible to as many repositories as possible, hoping that some percentage get merged.

For maintainers, the incentive is to maximize code quality. Every merged PR becomes their responsibility. Every line of code becomes something they maintain, debug, and answer questions about. A low-quality PR that gets merged is worse than no PR at all because it creates ongoing maintenance burden.

These incentives are directly in conflict. Agents want volume. Maintainers want quality. Without a protocol to mediate between them, the result is what we're seeing now: maintainer burnout.

Some of the most experienced open source contributors I know have stepped back from maintaining projects. The workload of triaging AI-generated PRs, on top of the existing unpaid labor of maintaining software that millions of people use, pushed them over the edge. We're losing human maintainers to protect ourselves from AI contributors. That's perverse.

What Good AI Contributions Look Like

I want to be clear: I'm not against AI-assisted contributions to open source. Some of the best PRs I've reviewed recently were written with AI assistance. The difference is in how they were created.

Good AI-assisted contributions involve a human who understands the project, identifies a real problem, uses AI to help write the solution, and then reviews the output carefully before submitting. The human provides judgment. The AI provides speed. The result is a high-quality contribution that was produced more efficiently than doing it entirely by hand.

Bad AI-generated contributions involve an agent that scans repositories for potential "improvements," generates changes without understanding the project context, and submits PRs that technically work but miss the point entirely. No human judgment. No project context. Just pattern-matching that produces syntactically correct but semantically meaningless changes.

The 406 Protocol gives maintainers a way to distinguish between these. By requiring disclosure, quality gates, and agent identification, it creates a framework where good AI contributions can thrive while bad ones get filtered out.

The Broader Lesson

We're going to keep running into this pattern. AI makes generation easy. Evaluation stays hard. Systems that accept input from the public will be flooded with AI-generated content. And we'll need new protocols, standards, and norms to handle it.

The 406 Protocol is a small, pragmatic solution to a specific problem. But the thinking behind it applies everywhere. How do we build systems that benefit from AI generation without being overwhelmed by it? How do we maintain quality standards when volume becomes infinite? How do we keep human judgment in the loop without burning out the humans?

These are the real questions of the AI age. Not whether AI can generate code. It can. The question is how we manage the flood of what it generates while preserving the quality of what we ship.

The 406 Protocol is a start. We need a lot more like it.