Godot bans AI-authored PRs — 'we can't trust heavy users to fix it'

What happened

The Godot Engine project — the largest fully open-source game engine, with roughly 100k GitHub stars and a full-time foundation behind it — has updated its contribution policy to reject pull requests containing AI-authored code. The change was announced by core maintainer Rémi Verschelde on the project's forums and mirrored in the CONTRIBUTING guidelines. PCGamer's coverage lit up Hacker News at 200 points within hours.

The policy isn't a disclosure requirement. It isn't a quality bar. It's a flat ban on submissions where the code itself was produced by a large language model. Verschelde's quoted reasoning is worth reading twice: 'we can't trust heavy users of AI to understand their code enough to fix it.' That sentence reframes the entire AI-in-open-source debate. The maintainers aren't arguing that Copilot output is bad — they're arguing that the humans routing it into PRs have lost the ability to defend it in review.

Godot joins a small but growing list. The NetBSD project banned AI-generated commits in 2024. The Gentoo project followed. QEMU's maintainers have publicly refused several PRs traced to Cursor and Claude Code. But Godot is the first project of its size and cultural weight — a genuine competitor to Unity and Unreal in indie development — to make this call.

Why it matters

Every previous ban framed the problem as output quality: hallucinated APIs, license laundering, subtle bugs that pass tests but fail in production. Godot's framing is different and, honestly, more damning. The problem isn't the code the LLM produced. The problem is the human on the other end of the PR who can't answer 'why did you write it this way?' without pasting the question back into ChatGPT.

This matches what a lot of maintainers have been saying privately for eighteen months. Review cycles have gotten longer, not shorter. Contributors who used to iterate on feedback in a day now go silent for a week, come back with a rewrite that's clearly a fresh LLM session, and re-introduce the exact bug that got flagged the first time. The Godot maintainers finally said the quiet part out loud: the bottleneck isn't the tool, it's the human's inability to reason about what the tool produced.

The policy has an obvious enforcement problem. Nobody can prove a PR was AI-authored — the maintainers admit as much. What they can do, and what they've apparently been doing informally already, is close PRs where the author demonstrably can't discuss their own code. The formal ban gives them cover to do that faster without a comment-thread argument about 'well, I did use AI but I also understand it.'

Community reaction on HN split along predictable lines. One camp — mostly people who ship — read it as maintainers protecting their time and the project's long-term architectural integrity. The other camp read it as gatekeeping that will fall apart the first time a well-known contributor quietly uses Claude Code and nobody notices. Both camps are right, which is why the policy is a social signal more than a technical one: Godot is telling its contributor base which side of the review-quality debate the project is on.

Compare this to the Linux kernel's approach. Linus has been publicly skeptical but hasn't banned anything; kernel patches from AI-assisted contributors still land, because the review process is brutal enough that unreviewable code doesn't survive. Godot's maintainers presumably don't have kernel-scale review bandwidth, so they're rationing it by policy instead.

What this means for your stack

If you contribute to Godot, the practical implication is narrow: write the code yourself, or be able to defend every line as if you did. That's already the standard for any serious contribution to any serious project — Godot just wrote it down.

If you maintain an open-source project, watch this policy's enforcement over the next six months. The interesting question isn't whether Godot can detect AI-authored PRs — they can't — but whether the stated policy changes contributor behavior in ways that reduce maintainer load. If it does, expect similar language to appear in CONTRIBUTING.md files across mid-sized projects by end of year. If it doesn't, expect the policy to quietly disappear or get watered down to a disclosure requirement.

If you use AI to write code for your own projects, none of this applies. The Godot policy is specifically about the maintainer-contributor contract in a volunteer-driven project, where the maintainer's time is the scarce resource and the contributor's ability to close the review loop is what makes the transaction work. Nobody's coming for your Cursor setup at your day job.

The more interesting downstream effect is on hiring signals. When a top-100 open-source project publicly states that heavy AI users can't debug their own code, it becomes harder for senior engineering hiring managers to ignore that as a red flag on a candidate's PR history. The 'AI-assisted' contributor category was starting to get normalized as a legitimate skill; Godot just re-stigmatized it in the specific context where the human's technical judgment gets tested.

Looking ahead

The honest read is that this policy is unenforceable but coherent. Godot's maintainers can't detect what tool wrote a given diff, but they can enforce a norm that PR authors must be able to reason about their own submissions in real time. Every project that adopts similar language will be making the same bet: that formalizing the expectation shifts the marginal contributor's behavior even if detection is impossible. Whether that bet pays off depends entirely on whether heavy AI users self-select out of Godot contributions or just get better at pretending. We'll know by the end of Q3 2026 which way it broke.