Dora NodaSite-wide merged pull requests on GitHub grew from 25 million a month in January 2023 to 90 million a month in March 2026. Pull requests opened by AI agents specifically went from 4 million to 17 million in the six months before that — and of the AI-created PRs landing in maintainers' queues, roughly one in ten is judged legitimate enough to even review. The other nine are noise: plausible-looking diffs nobody asked for, from an author who can't answer a follow-up question.
On June 26, 2026, the Kubernetes project — the largest thing on GitHub with a full-time contributor-experience team and CNCF funding behind it — published its answer: a formal policy for AI-assisted contributions, built around one non-negotiable rule. If you can't personally explain the AI-generated code in your PR, your PR gets closed. Below it sits a stack of process: a disclosure requirement, a ban on AI as a listed co-author, a CLA bot that flags submissions it can't do, and a slow rollout of AI review tooling paid for by the CNCF.
None of that stack is available to a project with one maintainer and no foundation behind it — which is most open-source software, including a project like Bex.co the moment it starts taking outside contributions to its Apache-2.0 codebase. This post pulls apart what Kubernetes actually did, what projects with zero budget are doing instead, and which pieces of Kubernetes' policy cost nothing to copy today.
What Kubernetes Actually Did
The policy Kubernetes shipped is narrower than "regulate AI usage." It's built around a single idea: the project doesn't care how a change was produced, only whether a human can stand behind it. Concretely, that breaks into five rules:
- Disclose AI assistance in the PR description. A one-line statement — "This PR was written in part with the assistance of generative AI" — is sufficient. The point isn't to shame the contributor; it's to tell the reviewer what level of scrutiny to apply before they start reading.
- No AI as a commit co-author. Trailers like
Co-authored-by: <AI tool>orAssisted-byare prohibited outright. The stated reasoning: "If something breaks, there needs to be a human who understands why and can fix it" — and a bot can't be that human, so it doesn't get listed as one. - The CNCF's CLA bot auto-flags any PR with a co-author field. Since AI agents can't sign a Contributor License Agreement, a co-authored commit is itself a signal the PR isn't merge-ready — the tooling catches the violation of rule 2 mechanically, instead of relying on a reviewer to notice.
- You have to be able to explain your own PR. This is the load-bearing rule. Contributors can't hand off review-comment replies to an AI tool; if a maintainer asks "why did you do it this way" and the answer is a shrug, the PR closes regardless of whether the code itself was correct.
- AI review tooling is opt-in and project-funded, not mandated everywhere. CodeRabbit is piloting in three kubernetes-sigs repos — Kueue, JobSet, and Agent-Sandbox — and the CNCF pays for GitHub Copilot Enterprise seats so maintainers (not just contributors) get an AI-assisted first pass before a human review. Notably, only maintainers get this tooling; there's no automated review offered to the general contributor pool, because doing that without a contributor license was, in the post's own words, "out of reach."
Read as a whole, the policy is agnostic about tooling and strict about accountability. Nothing in it says "don't use AI." Everything in it says "AI doesn't get to be the thing responsible when this breaks."
The Budget Kubernetes Has That You Don't
Rule 5 is where the gap opens up. Kubernetes can afford to pilot a paid review bot in three repos and buy Copilot Enterprise licenses for its maintainer pool because it has a foundation writing checks and a dedicated SIG — sig-contributor-experience — whose job is literally to maintain contribution policy and tooling. A solo maintainer, or a five-person team running an open-source PaaS on the side, has neither.
What that end of the spectrum actually looks like in 2026 is instructive, because it's not hypothetical — three well-known projects landed on three different answers this year, none of which involved a CNCF budget:
- curl shut down its HackerOne bug bounty program entirely in January 2026. Daniel Stenberg's stated reason wasn't PR review load specifically — it was that AI-fabricated vulnerability reports had pushed the valid-submission rate below 5%, to the point where the security team was spending more time debunking fake CVEs than fixing real ones. It's a different contribution surface than a PR queue, but the same underlying failure: AI-generated submissions cost more to triage than they're worth, at any volume a small team can sustain. (Stenberg has since noted the opposite effect too — AI-assisted researchers using tools like ZeroPath surfaced over 100 real curl bugs static analyzers had missed, so the project's actual position is "no automated bulk submissions," not "no AI.")
- Ghostty, the terminal emulator maintained largely by Mitchell Hashimoto, adopted a zero-tolerance policy: drive-by AI-generated PRs get closed without discussion, full stop. No disclosure exemption, no case-by-case review — the cost of adjudicating each one individually was judged higher than the cost of occasionally closing a good one by mistake.
- tldraw went further. Steve Ruiz announced the project would auto-close all external pull requests, AI-assisted or not, because the triage cost of distinguishing "good human PR," "good AI-assisted PR," and "slop" had exceeded what the team could absorb at any granularity finer than "closed."
None of these three had sig-contributor-experience's staffing or the CNCF's checkbook. Each picked a different point on the same tradeoff curve — accept the review burden and filter harder (curl), refuse the ambiguous middle case and accept some false positives (Ghostty), or opt out of external contributions altogether (tldraw). That's the real menu for a small project: not "adopt Kubernetes' policy," but "pick the point on this curve your team's actual bandwidth can sustain."
The Cheat Sheet: What Transfers for Free
The good news buried in Kubernetes' five rules is that only one of them — rule 5, the paid tooling — actually costs money. The other four are policy and process, and every project, regardless of size, can adopt them this week:
| Kubernetes mechanism | What it costs Kubernetes | Free/small-project equivalent |
|---|---|---|
| Disclosure statement in PR description | Nothing (a documented convention) | Add a checkbox to your PR template: "This PR used AI assistance (describe where)." Costs a .github/PULL_REQUEST_TEMPLATE.md edit. |
| No AI as commit co-author | Nothing (a CONTRIBUTING.md rule) | State it in CONTRIBUTING.md, and add a one-line CI check that greps commit messages for Co-authored-by: patterns matching known AI tool signatures. A GitHub Action, not a service. |
| CLA bot flags co-authored PRs | CNCF-run infrastructure | If you require a CLA at all, most CLA-bot integrations (cla-assistant, EasyCLA) already fail on unrecognized co-author emails for free — you're likely one config flag from the same behavior. If you don't require a CLA, skip this row; it doesn't apply. |
| "Explain your PR or it's closed" | Nothing — pure reviewer discipline | This is the one that actually matters most, and it's entirely free: write it into CONTRIBUTING.md, and as a maintainer, ask one clarifying question on any PR that reads as AI-generated before you invest real review time. No answer, no further review. |
| GitHub-native PR caps | N/A (Kubernetes doesn't need this — it has SIG-level triage) | GitHub shipped per-user PR caps as a native repo setting in 2026, free on every plan: cap how many open PRs a non-collaborator can hold at once, with a bypass list for trusted contributors. For a small project, this alone kills the "spray fifty PRs and see what sticks" failure mode that made curl and tldraw give up entirely. |
That last row is the one worth calling out on its own: it's the single mechanism that gets a small project most of the way to Kubernetes-style triage control without needing a SIG, a CLA bot, or a paid review tool. Combined with a disclosure checkbox and a stated "explain it or it's closed" policy, a solo maintainer can implement the entire spirit of Kubernetes' policy in an afternoon — the accountability rule (4) plus the volume control (GitHub's cap) cover the two failure modes (unaccountable code, unsustainable triage load) that actually drove curl, Ghostty, and tldraw to more drastic measures.
Where "AI Agents as Operators" and "AI Agents as Contributors" Collide
There's a sharper version of this question waiting for any project — bex included — that's building toward AI agents as first-class operators of the software itself, not just potential contributors to its source. Bex's own roadmap treats an agent calling deploy(service, ref) or rollback(service, revision) through an MCP tool as a normal, expected way the platform gets used. That's a deliberate design choice, and it's a different role than an agent showing up in a PR queue.
But it's the same underlying question. "Can a human explain and stand behind this deploy tool's behavior" and "can a human explain and stand behind this AI-generated PR" are both instances of the exact same accountability check Kubernetes' rule 4 encodes — just applied to two different surfaces of the same project. A platform that's already written a careful trust boundary around its agent-callable operator tools (scoped credentials, confirmation gates on destructive actions — the kind of audit worth running against any MCP server exposing deploy/rollback) has no principled reason to skip the equivalent check on its agent-assisted contributor traffic. An AI-authored PR that touches the deploy or rollback code path itself is arguably higher-stakes than either surface alone: it's an unaccountable-contribution risk landing directly inside an already-sensitive trust boundary.
The concrete recommendation, then, isn't complicated: write the "explain your PR or it's closed" rule into CONTRIBUTING.md before the first AI-heavy PR against deploy.go or rollback.go shows up, not after. Kubernetes had the luxury of writing its policy in response to volume it was already drowning in. A smaller, earlier-stage project gets to write the same rule pre-emptively, for a tenth of the effort, while it still only needs one sentence and a PR template checkbox instead of a CLA bot and a dedicated SIG.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with deploy and rollback exposed to agents as scoped, confirmation-gated MCP tools. The same accountability bar applies to code landing in the repo itself. Star the repo on GitHub or open a PR — just be ready to explain it.