LLMs are really good at C# (and tscn files for some reason), so that solves the "LLMs suck at GDScript" problem. Also, C# can be cheaper in terms of token usage (even accounting for not having to load the additional APIs): one agent writes the interfaces, another one fills in the details.
Saying this because I had really enjoyed vibecoding a Godot game in C# - and it was REALLY painful to vibecode with GDScript.
The original reasoning: GDScript is the default path in Godot, nearly all docs and community examples use it, and the engine integration is tighter (signals, exports, scene tree). C# still has some gaps — no web export, no GDExtension bindings.
But you're right that from the LLM side, C# flips the core problem. Strong training data, static typing for better compiler feedback, interfaces for clean architecture. The context window savings from not loading a custom language spec could be significant.
Main thing I'd want to test is whether headless scene building — the core of the pipeline — works as smoothly in C#. Going to experiment with this.
This always puzzled me about Godot. I like Python as much as the next guy (afaik GDScript is a quite similar language), but for anything with a lot of moving parts, wouldn't you prefer to use static typing? And even simple games have a lot of moving parts!
But it's gotten much better.
I was starting from scratch and mainly relying on Opus/Sonnet 4.
I also kept running into the Godot 3 vs 4 issue before adding specific guidance about this into CLAUDE.md
Be happy to find out I’m wrong.
The way unity solves this is with some kind of proprietary compiler. They translate the C# into C++, and then compile that into webassembly.
Whereas others (incl. Godot) need to ship the .NET runtime in the browser. (A VM in a VM.)
It makes me sad that Unity doesn't open source that. That would be amazing.