Skip to content
Dunking Dog Games Dunking Dog Games

Godot Bans AI-Generated Code Contributions

· Blog

Abstract hexagonal pattern in purple, cover art for the Godot AI policy article

At the start of July 2026, the Godot Foundation announced that the engine’s contributor guidelines would be amended to forbid three things: AI-authored code, pull requests submitted by AI agents, and AI-generated text in human-to-human communication.

The story spent a day near the top of Hacker News and drew several hundred comments, which tells you it touched something bigger than one open-source project’s contribution policy.

What Is Actually Banned

The important nuance, which the headlines mostly flattened: this is not a blanket ban on developers who use AI tools.

  • Banned: code authored by AI and submitted as a contribution, PRs opened by agents, and AI-generated prose in discussions between maintainers and contributors.
  • Still allowed: limited use for what the Foundation called “menial things”, provided the contributor discloses it.
  • The condition throughout: a human has to understand the code, own it, and be able to fix it later.

Godot also said it will keep re-evaluating. In their words, things change every day with respect to the current suite of AI tools, so they are taking a conservative approach for now rather than a permanent position.

Why They Did It

Two reasons were given, and neither is really about code quality in the abstract.

The first is about maintainer supply. Open-source engines depend on contributors growing into maintainers over years. That path runs through the unglamorous work of reading unfamiliar code, getting review feedback, and gradually building a mental model of the codebase. A contribution flow where that learning is skipped produces patches but not maintainers.

The second is about who can fix it later. As PC Gamer’s headline put it, quoting the project: “We can’t trust heavy users of AI to understand their code enough to fix it.” Merged code is a liability someone carries for years. If the person who submitted it cannot debug it, the cost lands on the reviewers.

There was also a practical trigger. Back in February, Godot’s maintainers said publicly that they were working out how to handle a rising tide of AI-generated pull requests, which reviewers were finding “increasingly draining and demoralizing”.

That last part is the bit worth sitting with. Review capacity is the scarcest resource in almost every open-source project. A tool that makes it dramatically cheaper to produce pull requests, without making it any cheaper to review them, puts pressure exactly where a project can least afford it.

Why Unity Developers Should Care

You might reasonably file this under “Godot problems”. Two reasons not to.

It is a contrast worth noticing. In the same fortnight, Unity was shipping a CLI whose headline feature is letting AI agents drive the Editor — observe a live project, act on it, verify the result. Two engines, two very different bets, in the same month. Neither is obviously wrong: Godot is protecting a volunteer review pipeline, Unity is selling tooling to teams who own their own codebase. But if you are choosing an engine partly on where its community is heading, that difference is real information.

The underlying question applies to your project too. Whatever you think about AI-assisted coding, “can the person who submitted this fix it in six months” is a good bar for any code you take responsibility for — from a contractor, from a tutorial, from an asset store package, or from a model. The Godot policy is just that question written down and enforced.

For a small studio the answer usually shakes out as: use the tools, but never merge something you could not have written and cannot debug. The failure mode is not bad code, it is code nobody on the team understands.

Sources

Tags: gamedevprogrammingindiedev