There's a new protocol gaining traction in the open-source world: HTTP 406 as a standard response for rejecting AI-generated pull requests. The idea is simple. If a repository doesn't accept AI-written code, it can signal that rejection cleanly using an existing HTTP status code.
Love it or hate it, this tells you something important about where we are with AI-generated code. The volume is high enough that maintainers need automated ways to deal with it.
The Problem Is Real
Open-source maintainers are drowning in AI-generated pull requests. Some are fine. Many are not. The bad ones share common traits: they technically compile, they pass basic tests, and they completely miss the architectural intent of the codebase.
An AI can fix a bug by adding a null check. A human engineer fixes the bug by asking why the null got there in the first place. Both PRs "work." One makes the codebase better. The other adds technical debt that compounds for years.
Maintainers don't have time to write detailed rejection notes for hundreds of low-quality PRs per month. A protocol-level rejection makes sense as a first filter.
This Isn't Anti-AI. It's Pro-Quality.
Let's be clear about something. Using AI to write code isn't the problem. Using AI to write code without review, without context, and without understanding the codebase is the problem.
The best engineering teams using AI right now treat it as a first draft generator. The AI writes the initial implementation. A human engineer reviews it with full context of the system architecture, business requirements, and long-term maintenance implications. Then they ship something that's actually good.
The worst teams treat AI code generation as a fire-and-forget weapon. Generate code, open PR, move on. That's what's flooding open-source repos and that's what the 406 protocol is designed to catch.
Quality Gates Apply to AI Agents Too
This same principle applies directly to AI agent deployments. An AI agent without quality gates is a liability. An AI agent with proper review layers is a multiplier.
When we deploy agents for businesses, every automated action has a confidence threshold. High-confidence actions (scheduling a meeting, sending a standard reply) happen autonomously. Low-confidence actions (modifying financial data, sending a contract, responding to an angry customer) get flagged for human review.
The threshold varies by client and by action. A marketing team might let their agent publish social media posts autonomously. A legal team wants human eyes on everything. Both are valid. The point is the gate exists.
What Good Quality Gates Look Like
Action-level permissions. Not all agent actions carry the same risk. Classify them. Reading data is low risk. Writing data is medium. Sending external communications is high. Set review requirements accordingly.
Audit trails. Every action your agent takes should be logged with the reasoning behind it. When something goes wrong (and eventually something will), you need to trace exactly what happened and why.
Rollback capability. If an agent makes a bad call, can you undo it? If the answer is no, that action needs a human in the loop. Period.
Progressive trust. Start with tight gates. As the agent proves reliable in your specific context, loosen them gradually. This is how you build trust without gambling on day one.
The 406 Protocol Is a Symptom
The real story isn't one HTTP status code. It's that AI output volume has exceeded our ability to review it manually. Every domain, not just code, needs quality gates designed for AI-speed output.
The teams that build those gates now will be the ones still standing when everyone else is buried under AI-generated noise.