Godot Makes The Right Call in Blocking AI Code in Their Engine | 08/07/26
With coding agents on the rise, we risk losing insight into our own software.
Hello and welcome to this week’s edition of AI and Games. Right now with Xbox committing it’s own weird form of seppuku to placate their AI masters, I struggled real hard with not ranting about that in this week’s issue. However, I decided to focus on something a little more interesting. In previous editions I’ve talked about efforts by game engine Godot to mitigate code submissions for the engine that they suspect are AI generated, and this has only continued to escalate since. So why not dedicate this issue to talking about why this has became such a problem, and the surge in capabilities of AI code generation even in the past 6-9 months.
Follow AI and Games on: BlueSky | YouTube | LinkedIn | TikTok
Announcements
Obligatory round of announcements for this week. Lots of stuff happening and coming your way!
AI and Games Events
We have a bunch of stuff happening in the coming weeks.
Develop: Brighton [14th - 16th July]
I’m down in Brighton, UK next week for the Develop conference and looking forward to catching up with many of my friends in and around the industry.
Drop me a message if you’re going to be in town and want to arrange a meeting to discuss everything from our consultancy work to the conference events too!
Or just y’know, some solid bants. Banter is always good.
SAVE THE DATE: Montreal Meetup [Thursday 23rd July]
I am going to be in Montreal, Canada for a work project later this month and figured why not buy a round for the local development community? If you’re based in and around Montreal you’re more than welcome to join us. It will be on the evening of Thursday 23rd July, and I’ll have more info on the venue and times next week!
Gamescom Dev AI Tracks [24th-25th August]
Tickets are on sale now. Two days of tracks on AI alongside the rest of Gamescom Dev and the Gamescom trade show.
AI and Games Conference 2026 [10th-11th November]
Early bird tickets: Ticket sales have really ramped up in the past couple weeks, and odds are we’ll sell out before early bird sales end later this month.
Call for speaker submissions has also seen a stack of stuff come in, and closed August 2nd.
1st Episode of AI and Games Podcast on Friday
The new AI and Games Podcast is available here in this newsletter, plus on:
Spotify | Apple Podcasts | YouTube Music | YouTube | PocketCasts
Our first episode goes live on Friday July 10th, with me giving an overview of AI adoption in the 2026 games industry.
Godot’s Hardens Stance on AI Code Submissions
Back in February I wrote about how Godot’s developer team had voiced their frustration with the number of submissions being sent to them for updating their codebase that had arisen courtesy of generative AI tools. This has since escalated, with the Godot Foundation issuing a statement on June 30th on how they’re amending their contribution policy to prohibit the use of AI agents being used to write code for the engine, or as part of dialogue with their review team.
I think this is a sensible and practical decision made by the organisation, and as a programmer myself I agree with 100%. Not from some righteous perspective of rejecting AI on principle, but that the current trends in excessive code generation run real risks to product performance maintenance on both technical and human levels.
I also figured why not use this as a bit of an intro to some of these issues, namely:
The recent surge in AI code generation.
Why this affects open-source projects like Godot.
Why Godot are right in taking this approach.
Code Generation is the Big Boom of 2026
This year if there’s one big AI trend I’ve acknowledged is the sudden excessive enthusiasm with which many organisations are now using AI tools to generate code for software. Not just using it as an auto-complete or generating small snippets, but now entire codebases. GitHub Copilot launched as a complete service around four years ago (June 21st, 2022), and it relied on OpenAI’s GPT to help developers write code. You give it prompts, you give it code, it generates results, and it can do so within the Integrated Development Environment (IDE) that you’re working in.
Code generation seemed like a natural next step for software engineers. We already use a lot of autocomplete tools in IDE’s, and a lot of this can simply help you write faster. But of course any tools that are derived from LLMs are prone to all sorts of issues, ranging from mediocre or generic outputs to hallucinating the wrong intent for your code, or of course the fundamental issue that in most instances it doesn’t really understand what you want, nor how it should output it.
However, it was clear from a lot of data coming out of companies who build enterprise scale software that seasoned engineers were seeing the value in it. Nonsense from vibe coders on social media aside, engineers were often enthusiastic about adopting it and using it as a force-multiplier for the work they were doing - though there is little insight on games studios.
Fast forward to early 2026 and the ground had shifted drastically. This was largely in part due to Anthropic’s Claude Code, which has proven to be a far more capable AI coding tool that others on the market. Copilot, GPT, Gemini or frankly anything else on the market. While effective prior to now, code generation had seemed capped off in its broader capabilities, most notably in writing larger coding tasks across multiple files. In addition Claude Code is highly capable in an agentic workflow; meaning you can have AI writing code, running tests, observing errors, then writing code to debug and fix the tests.
There’s a lot more we could talk about here, but I’d recommend instead going to read the The Pragmatic Engineer, where the newsletter has been reporting on how the entire field of enterprise software development has been transformed - in both positive and negative ways - due to heavy adoption of AI coding tools.
How Does This Affect Godot?
In the past couple of years the Godot game engine has became an increasingly popular tool for game developers, and has begun to really start carving out territory once owned by Unity. Speaking as someone who has built in Unity myself, developers have fought for fought for years with poor monetisation practices, broken features, inconsistent updates, long-standing unresolved bugs, and a push for new tools that most developers don’t want - I have joked in the past that Unity has now bundled up and announced their Generative AI suite three times, and unsurprisingly most indie developers simply don’t care. I have dabbled briefly in Godot in the past year and it’s come a long way! I am sorely tempted whenever I find some free time to make a game again (ha!), I’d boot up a wee project in Godot to see how far it’s come along.
However unlike Unreal Engine and Unity, Godot is an open-source game engine driven by a community of game developers. Meaning that not only can developers download the full source code and modify it to suit your needs, but also that people can propose changes to the engine and, if accepted, they get adopted in the main repository where the original code is maintained and becomes part of the product. This is a common practice in open-source software development, and is managed by a collection of developers who oversee the proposed change submissions, known in GitHub as Pull Requests.
As mentioned back in February, one of the maintainers of the code, Rémi Verschelde, had said the team were being inundated with pull requests that were either full of AI-generated code, or in they suspected were generated entirely with AI.
Since then they’ve realised not only is it going to continue, but it’s only going to get worse as AI code generation becomes normalised. To that end they updated their contribution policies to not only prohibit use of AI tools in any pull requests submitted, but will begin to automatically ban users who present work that appears heavily AI-generated.
Why They’re Right in Banning AI-Driven Submissions
The argument made in the announcement by Godot was that the increased number of submissions is adding to the workload of the rather small review team who maintain the engine’s codebase. While it’s easier than ever to generate a pull request, the time taken to review one has not changed, and it’s difficult and complex work.
The reason pull request’s take time to review is that people build these additions and then submit them often without consideration for the impact of the entire engine’s implementation and performance. To be able to write substantial changes to the engine that will work successfully and to the community’s benefit, requires a user to understand the existing code, and then integrate their new feature in ways that compliment and reinforce what’s already there. This is something that AI code generation can’t really do at the same level or quality, if at all, like a human can. It’s expected that people that seek to contribute to the engine do so because they know it well, and have the knowledge to help enhance it further. The argument being made is that most of the requests they receive are often people generating low-effort submissions that simply clog up the queue that the reviewers are dealing with.
For me one of the biggest stumbling blocks with AI code generation is that it prevents me from learning my codebase. Having written software for around 30 years, I internalise my understanding of systems by sitting and writing them out. I design the systems and then implement them, and it’s that process that helps me build a mental model of the software as a whole. Hence I can be playing a demo of a game I have built which has tens of thousands of lines of code and upon seeing a bug during a playtest I can often quickly determine which file, and what function might be the culprit. That comes from building the software, and then internalising its structure as you build it.
I personally do not feel the same about using AI coding assistants, because now the code it writes and how it writes it is at the whim of how the model is trained. Not only does it not write code like me, it writes code I don’t know. I then have to sit and understand the code it has written, lest I fail to interpret how my software works. Yes I will have the general understanding of how it works given I prompted the model to what I wanted, and I won’t just trust its output without reviewing it, but given I didn’t write the code, I don’t know it. In the same way people write things by hand to boost memory retention, I can’t really understand my own code lest I’ve sat and actually written it out and tested it myself.
Now of course I see the appeal and value of code generation, given we’re often writing a lot of code. Plus let’s be honest, a lot of the code we’re writing is kinda dull, not that exciting, and boilerplate to help build up features, and so having AI write that for you does sound enticing to some degree. But I feel it robs the creator of having any sense of ownership of the codebase, and this is often driven by knowledge of how it works.
This is a big part of what Godot’s team are focussed on, because what they need to be building is a larger community of contributors who know the project well enough that they can help maintain it. This includes not just knowing about the parts of the project they themselves have written, but also understanding the rest of the broader engine. It requires people to have gone away and internalised how Godot works such that changes they propose ‘fit’ into the engine more seamlessly. Relying on AI to maintain knowledge of the engine, and then write code to update it, will result in a tool that ultimately nobody will understand. To quote the announcement, “AI cannot take responsibility, and we can’t trust heavy users of AI to understand their code enough to fix it.”
As discussed in the announcement the review team spend time giving feedback and attempting to build a dialogue with contributors, and in many cases they’re getting AI-generated responses - because odds are it’s an AI agent that’s receiving it. This is rather demoralising for a team of people seeking to build community, and if the only solution is to add that as a condition for banning users, then that strikes me as sensible.
When you compare this to large-scale companies where every update you’re forced to use is riddled with AI features people don’t need, or suspected to be driven by poor-quality AI generated code (i.e. any time you update Windows 11), the big difference is in accepting responsibility. Of acknowledging that a human is responsible for these changes, even if they didn’t actually make them themselves.
If you can’t trust developers to take responsibility for the code they create, and the bugs it will generate - because no code is perfect - then how can you expect them to fix it, and maintain the standards being set? The Godot Foundation understands this.
Wrapping Up
Okay, as mentioned at the top I’ll be at Develop next week, so I’m not sure what time I will have to commit to a newsletter. Perhaps a run through of my favourite games of the year so far? Yeah, that might be a fun thing to do.
Have a good one, and catch you next week.