A new proposal hit Hacker News today with 216 points and climbing: the 406 Protocol, a standard way for open source maintainers to signal that AI-generated pull requests are not acceptable without human review and attestation.
The name is a nod to HTTP 406 "Not Acceptable." The message is blunt: your AI-generated PR is not acceptable here.
This is the inevitable collision between two trends that have been on a crash course for over a year.
The Problem
Open source maintainers are drowning in AI-generated pull requests. Not the good kind, where a developer uses AI to help them write better code faster. The bad kind, where someone points an AI agent at a repo's issue tracker and lets it spray PRs everywhere with zero human oversight.
These PRs share common traits. They technically address the issue title. They often introduce subtle bugs. They rarely follow the project's conventions. They sometimes make changes to files that shouldn't be touched. And they waste enormous amounts of maintainer time to review and reject.
One maintainer described it as "a denial of service attack that looks like helpfulness."
The volume is the real problem. A popular repo might get 5 to 10 human PRs a week from contributors who understand the codebase. Now it gets 50 AI-generated PRs from people who have never read the source code. Each one takes time to review. Each rejection takes time to explain. The maintainers are doing more work, not less, because of AI.
What the 406 Protocol Does
The protocol is simple. A repo includes a .406 file or a 406 section in its CONTRIBUTING.md that specifies:
- Whether AI-generated PRs are accepted at all
- What level of human attestation is required
- What disclosure is expected (did you use AI? which tool? how much of the code is AI-generated?)
- What the consequences are for violating the policy
Some repos are going full ban: no AI-generated code accepted, period. Others are taking a middle ground: AI-assisted is fine, but you must have personally reviewed every line, you must understand every change, and you must disclose your AI usage.
The protocol also proposes that CI systems can check for the presence of AI-generation markers (certain comment patterns, commit message formats, code style fingerprints) and flag PRs for additional scrutiny.
Why This Was Inevitable
The open source community ran face-first into a problem that every organization will eventually face: AI makes it easy to produce work, but it doesn't make it easy to produce good work. And when producing work is cheap, you get flooded with cheap work.
This is the classic quality vs quantity trap. AI didn't invent it. Email spam was the same dynamic. But AI made it worse because AI-generated PRs look plausible. Spam was easy to filter because it was obviously garbage. An AI-generated PR that introduces a subtle race condition or misunderstands the project's threading model looks legitimate at first glance. It takes expert review to catch the problems.
The Tension
Here's what makes this hard. AI is genuinely useful for writing code. Many experienced developers use AI assistants every day and produce better code faster. Banning AI-generated code entirely means rejecting contributions from developers who used Copilot to autocomplete a function, which is most developers at this point.
The protocol tries to draw the line between "AI-assisted" (human developer using AI tools) and "AI-generated" (AI agent producing code with minimal human oversight). But that line is blurry and getting blurrier.
Did I write this code or did my AI assistant? If I prompted an AI to write a function, then reviewed it, understood it, tested it, and refined it, is that AI-generated or human-written? What if I just accepted the first suggestion without changes? What if I understood it but didn't test it?
The protocol acknowledges this gray area and puts the onus on the contributor: you must be able to explain and defend every line of code in your PR. If you can't, it doesn't matter whether you or an AI wrote it. It's not ready.
That's actually a solid principle that predates AI entirely. The new part is formalizing it because the volume of "I can't actually explain this code" PRs has made informal norms insufficient.
What This Tells Us About AI Agents in Production
The 406 Protocol is an open source story, but the lesson applies everywhere AI agents produce output.
When you deploy an AI agent in your business, you face the same tension. The agent can produce a lot of work fast. But who reviews it? Who catches the subtle errors? Who makes sure the output meets your standards and not just the minimum bar of "technically addresses the requirement"?
The open source community is solving this with protocol and social norms. Businesses need to solve it with workflow design. Every AI agent output that matters should have a review step. The review doesn't need to be as thorough as reviewing code written by a stranger. But it needs to exist.
The companies getting burned by AI agents right now are the ones that treated "AI can produce the output" as equivalent to "the output is correct." Those are very different statements.
The Path Forward
The 406 Protocol won't stop AI-generated PRs. It will make the norms explicit and give maintainers a standard way to set expectations. That's useful even if enforcement is imperfect.
For the broader tech industry, this is a preview of what's coming everywhere. Every domain where AI can produce output at scale will need its own version of quality gates. Content moderation, code review, legal document review, financial analysis. The pattern is the same: AI produces, humans verify, and the verification step becomes the bottleneck you need to design for.
The irony is that the best solution to AI-generated noise might be better AI. AI that reviews AI-generated PRs. AI that flags likely low-effort submissions. AI that helps maintainers triage faster.
We're going to need AI agents to protect us from AI agents. If that sounds circular, welcome to 2026.