Godot bans AI code. The OSS ban list is now a pattern, not an outlier.

What happened

Godot's engine maintainers updated the contribution guidelines to prohibit AI-authored code. The public reasoning, from maintainer Rémi Verschelde, is blunt: they cannot trust heavy users of AI-generated code to understand their submissions well enough to fix them when review turns up problems. The HN thread hit 435 points, which for a governance-not-shipping story is unusual.

This isn't the first ban and it won't be the last. Gentoo shipped an explicit prohibition on AI-generated commits, bug reports, and documentation in April 2024. NetBSD followed with policy language stating that code generated by ChatGPT, Copilot, or 'any other AI-driven pipeline' is presumed tainted and will not be accepted without explicit prior approval. Daniel Stenberg has spent the last eighteen months publicly complaining that Curl's bug-bounty inbox has become an LLM slop firehose. Godot is now the fourth well-known project to write the rule down.

The common trigger, in every case, is the same: a spike in low-quality submissions from contributors who cannot answer follow-up questions about their own patch.

Why it matters

The surface framing — 'AI code bad' — is the wrong lens. The Godot rule doesn't fail LLM-generated code that a human authored, understood, edited, and can defend in review. It fails contributors whose relationship to their patch is 'the model wrote it and I pasted it.' That's a behavioral policy dressed as a provenance policy.

The real economic story is that AI decoupled two things that used to move together: submission volume and author understanding. Before Copilot, if you sent a 400-line PR against a game engine's renderer, you had spent enough hours in that renderer to answer questions about it. The friction was a filter. LLMs removed the friction. Maintainer review capacity did not increase to match. Verschelde's 'we can't trust them to fix it' is a polite way of saying every AI-authored PR that ships a subtle bug converts into infinite unpaid future work for the same three people who reviewed it.

This is why the pattern shows up first in project categories with high downstream blast radius: an OS (NetBSD), a distribution (Gentoo), a networking primitive (Curl), and a game engine (Godot). Engines and OSes have an unusual property — a bug in the render loop or the scheduler doesn't stay local. It corrupts save files, crashes user projects, and gets reported by people three abstraction layers up who have no idea where it came from. The cost of a wrong merge is asymmetric.

The enforcement question is where this gets uncomfortable. You cannot reliably detect AI-written code — the state of the art in classifiers is barely above random on short spans and drops further with light editing. So the rules are unenforceable as written. What they are actually enforceable on is the review interaction. A maintainer can ask 'why did you pick a mutex here instead of a spinlock' and if the answer is a hallucinated GPT-flavored paragraph, the PR gets closed. The rule is a license to close, not a detection mechanism. That's a legitimate governance tool, but people should be honest about what it is.

Community reaction in the HN thread split along predictable lines. The 'this is gatekeeping and won't scale' camp argued that within two years the median junior dev's workflow will be so entangled with AI that this policy amounts to banning junior contributors. The counter, upvoted higher, was that Godot's not obligated to subsidize the education of contributors who ship code they can't defend, and that OSS maintainership has always been a hostile-review environment for exactly this reason. The interesting take, buried around 60 upvotes, was that this is Chesterton's Fence at the organizational level: if you can't explain why the existing code does what it does, you don't get to change it — and LLMs are very good at generating changes with no theory of what they replaced.

What this means for your stack

If you maintain an open-source project that accepts external contributions, you now have a written-or-unwritten position on AI code. Pick one on purpose. The three viable positions are: (1) explicit ban à la Godot/Gentoo, (2) explicit disclosure requirement — you may use AI but must label the PR and remain able to defend every line, (3) no policy but a de facto behavioral filter in review. Silence defaults to option 3 and offloads the political cost onto individual reviewers, which is how maintainers burn out.

If you work at a company that ships against Godot, or against any project on this list, watch the contribution graph for the next two quarters. Bans reduce PR throughput. Godot's fix-forward velocity on niche renderer bugs may drop if the population of contributors willing to hand-write engine code is smaller than the population willing to Copilot-paste it. That's a real cost, and 'good, the bar is higher' is a reasonable answer but not a free one. Budget for it.

If you're a contributor who uses AI heavily — and statistically you are — the useful mental adjustment is that submitting to a strict OSS project is now closer to submitting to a peer-reviewed journal than to a Stack Overflow answer. The unit of trust is your ability to defend the diff under adversarial questioning. Copy-paste-submit doesn't clear that bar. Copy-paste-read-understand-rewrite-submit does. The policies aren't asking you to stop using the tools; they're asking you to stop skipping the middle steps.

Looking ahead

Expect one of the CNCF or Apache Foundation projects to publish a formal AI-contribution policy within the next two quarters — the maintainer-time economics that pushed Godot, NetBSD, and Gentoo apply harder to any project with a bigger contributor pool and a lower per-PR review budget. The interesting fight is whether the industry converges on 'ban' or 'disclose,' because the two produce very different contributor demographics five years out. Godot picked ban. Someone big is about to pick disclose, and that's when the pattern becomes a debate instead of a trend.