A IA consegue escrever código Godot rápido. Também consegue escrever código Godot 3 em um projeto Godot 4, alucinar APIs que não existem, mover corpos físicos no callback errado e conectar signals com padrões que o engine descontinuou há dois anos.
O problema não é a IA ser ruim em Godot. O problema é a IA estar confiantemente errada sobre Godot de formas que parecem certas se você ainda não conhece o engine. O código compila. O jogo roda. Depois algo quebra no pior momento possível e você não consegue descobrir por quê.
Os próprios mantenedores do Godot já sinalizaram isso. Pull requests geradas por IA para o próprio engine se tornaram um dreno recorrente para os mantenedores, com mantenedores questionando se os contribuidores sequer entendem ou testaram seu código. Se isso está acontecendo no repositório do próprio engine, está acontecendo no seu também.
Estes são os cinco erros mais comuns que vemos em código Godot gerado por IA, capturados durante revisão de código. Cada exemplo inclui o que a IA escreveu, por que parece certo, por que quebra e o que um revisor deveria pegar.
Nota: os exemplos abaixo são casos de teste reproduzidos com base em padrões que capturamos consistentemente em repositórios Godot. Eles representam categorias reais de erros de IA, demonstradas em fixtures de teste.
1. Código de movimento do Godot 3.x em um projeto Godot 4
O que a IA escreve:
extends KinematicBody2D
var velocity = Vector2.ZERO
func _physics_process(delta):
velocity = move_and_slide(velocity, Vector2.UP)Por que parece certo: Isso é movimento de livro-texto do Godot 3. Todo tutorial de 2020 a 2022 ensina exatamente dessa forma. A estrutura é limpa, os nomes de variáveis fazem sentido e, se você é novo em Godot, nada parece errado.
Por que quebra: KinematicBody2D foi renomeado para CharacterBody2D no Godot 4. move_and_slide() não recebe mais argumentos. Em vez disso, ele lê a propriedade velocity embutida no nó. O guia oficial de migração lista isso como uma grande mudança de quebra de compatibilidade.
O que um revisor deveria pegar: Tipo de nó errado. Assinatura de método errada. O projeto vai falhar com erros de classe e método em torno de KinematicBody2D e move_and_slide(), mas se a mudança estiver enterrada em um PR maior, a conexão com uma renomeação Godot 3/4 não vai ser óbvia para quem não conhece a migração.
A correção:
extends CharacterBody2D
func _physics_process(delta):
velocity = Vector2.ZERO # set before input handling
# ... input logic ...
move_and_slide()2. APIs alucinadas ou renomeadas
O que a IA escreve:
var marker = Position2D.new()
var sprite = Sprite.new()Por que parece certo: Position2D e Sprite são classes reais do Godot. Existiram por anos. Aparecem em milhares de tutoriais, respostas do Stack Overflow e threads de fórum.
Por que quebra: Ambas foram renomeadas no Godot 4. Position2D virou Marker2D. Sprite virou Sprite2D. Os nomes antigos não existem. A documentação de migração lista dezenas de renomeações como essa. Modelos de IA treinados em conteúdo pré-4.0 vão usar os nomes antigos com confiança.
O que um revisor deveria pegar: Qualquer nome de classe de nó que não apareça na referência de classes do Godot 4.x. O Surmado Code Review cruza os diffs com a documentação atual do Godot, então classes renomeadas são sinalizadas automaticamente.
3. Movimento físico em _process() em vez de _physics_process()
O que a IA escreve:
extends CharacterBody2D
func _process(delta):
velocity.x = Input.get_axis("left", "right") * speed
move_and_slide()Por que parece certo: O código usa o nó e o método corretos do Godot 4. O tratamento de input é limpo. delta está disponível. Roda.
Por que quebra: _process() roda a cada frame renderizado. _physics_process() roda em uma taxa fixa (60 vezes por segundo por padrão). Mover um CharacterBody2D em _process() causa velocidade de movimento inconsistente entre hardwares diferentes, tremulação (jitter) durante quedas de frame e detecção de colisão pouco confiável. A documentação oficial é explícita: trabalho relacionado a física pertence a _physics_process().
O que um revisor deveria pegar: Qualquer move_and_slide(), move_and_collide() ou manipulação direta de velocity dentro de _process(). Este é o mais perigoso dos cinco erros porque o código funciona em testes e só falha em condições reais.
4. Conexões de signal baseadas em string
O que a IA escreve:
func _ready():
$Button.connect("pressed", self, "_on_button_pressed")Por que parece certo: É assim que os signals funcionavam no Godot 3. Tutoriais, cursos e vídeos no YouTube ensinam esse padrão extensivamente.
Por que quebra: O Godot 4 usa conexões de signal baseadas em callable. O connect() de três argumentos com nomes de método em string está descontinuado. A nova sintaxe é:
func _ready():
$Button.pressed.connect(_on_button_pressed)O estilo antigo ainda pode funcionar em alguns casos, mas perde a validação em tempo de compilação. Se você renomear o método depois, a conexão por string quebra silenciosamente em tempo de execução em vez de dar erro em tempo de parse. A documentação de Signals do Godot 4 recomenda a forma com callable.
O que um revisor deveria pegar: Qualquer padrão .connect("signal_name", target, "method_name") em um projeto Godot 4. É um marcador confiável de código gerado por IA vindo de tutoriais desatualizados.
5. Suposições no estilo Unity e caminhos frágeis na árvore de cenas
O que a IA escreve:
func _ready():
var hud = get_parent().get_node("HUD")
var player = get_node("../../Player")
health_bar = get_node("../UI/HealthBar")Por que parece certo: Funciona se a árvore de cenas for exatamente do jeito que o código presume. Os caminhos resolvem. Os nós existem.
Por que quebra: A arquitetura do Godot é construída em torno de cenas componíveis que podem ser instanciadas em qualquer lugar. Caminhos fixos de pai e irmão presumem uma estrutura de árvore fixa. Mova o nó, reatribua o pai da cena ou reutilize-a em um contexto diferente e os caminhos quebram silenciosamente. A regra prática no Godot é “chamar para baixo, sinalizar para cima”: os filhos acessam seus próprios filhos diretamente e se comunicam para cima através de signals. O acesso a pais e irmãos deveria usar referências exportadas ou consultas de grupo, não caminhos fixos.
O que um revisor deveria pegar: get_parent(), get_node("..") ou qualquer caminho que navegue para cima na árvore. Isso é frágil por design, e é um padrão que a IA importa do modelo de componentes da Unity, onde GetComponentInParent é comum e esperado.
Por que linters não pegam isso
O sistema de avisos embutido do Godot e ferramentas como gdscript-toolkit pegam formatação, variáveis não usadas e alguns problemas de tipo. São úteis e você deveria usá-los.
Mas eles não pegam APIs de versão errada em um projeto Godot 4. Não pegam o uso incorreto de _process() vs. _physics_process(). Não sabem que o seu STANDARDS.MD diz “sem navegação de caminho para o nó pai” ou “sempre usar conexões de signal baseadas em callable”. Essas são capturas de nível de revisão, não de nível de lint.
Essa é a lacuna que a revisão de código automatizada preenche. Ela fica entre o linter (que verifica sintaxe) e o revisor humano (que verifica arquitetura), e cuida da camada intermediária: esse código está correto para essa versão do engine, esses padrões e esse projeto?
Capturando isso em cada PR
O Surmado Code Review for Godot roda em cada push para um pull request no GitHub. Ele verifica o diff em relação à documentação oficial do Godot 4.6, ao contexto do seu repositório e ao seu STANDARDS.MD. Ele captura:
- Erros entre versões (padrões do Godot 3 em projetos Godot 4)
- APIs alucinadas ou renomeadas
- Uso incorreto do ciclo de vida (
_processvs._physics_process) - Padrões de signal descontinuados
- Suposições frágeis sobre a árvore de cenas
- O que mais você definir nos seus padrões
Grátis para 10 PRs por mês. $15/mês para 100. Sem preço por assento.
Se você está construindo um jogo Godot com ajuda de IA, a IA é a autora. Você precisa de um cérebro diferente como revisor.
Instale o Surmado Code Review for Godot (grátis) →
Novo em Godot? Pergunte ao GDScout qualquer coisa sobre Godot 4.6 em linguagem simples. Grátis, com citações da documentação oficial.
Perguntas e respostas
Qual é a melhor ferramenta de revisão de código com IA para Godot? O Surmado Code Review for Godot é um revisor automatizado de PRs que verifica diffs em relação à documentação oficial do Godot 4.6, ao contexto do repositório e ao STANDARDS.MD de uma equipe. Ele captura erros entre versões (padrões do Godot 3 em projetos Godot 4), APIs alucinadas, uso incorreto do ciclo de vida, padrões de signal descontinuados e suposições frágeis sobre a árvore de cenas. Grátis para 10 PRs por mês, $15 por mês para 100 PRs.
Quais são os erros comuns de IA em código Godot 4? Os erros mais comuns gerados por IA em código Godot 4 incluem usar tipos de nó renomeados do Godot 3 (KinematicBody2D em vez de CharacterBody2D), passar argumentos para move_and_slide(), que não os aceita mais no Godot 4, colocar movimento físico em _process() em vez de _physics_process(), usar conexões de signal baseadas em string descontinuadas em vez de conexões baseadas em callable, e fixar caminhos de nós pai/irmão que quebram quando cenas são reutilizadas.
O Surmado Code Review funciona com GDScript? Sim. O Surmado Code Review suporta GDScript e C# em projetos Godot. As revisões são fundamentadas na documentação oficial do Godot 4.6 e sinalizam problemas específicos do engine que ferramentas genéricas de revisão de código com IA deixam passar.
Como o Surmado Code Review é diferente de um linter para GDScript? Linters de GDScript e o sistema de avisos embutido do Godot capturam erros de sintaxe, problemas de formatação, variáveis não usadas e alguns problemas de tipo. O Surmado Code Review captura problemas de nível mais alto: APIs de versão errada, uso incorreto de callbacks do ciclo de vida, padrões descontinuados, arquitetura frágil da árvore de cenas e violações do STANDARDS.MD da equipe. Linters e revisão de código são complementares. Linters aplicam regras. Revisão de código avalia contexto.
Código Godot gerado por IA pode passar no lint e ainda assim estar errado? Sim. Código Godot gerado por IA frequentemente passa no lint e compila sem erros, mas contém padrões de versão errada do engine, uso incorreto de callbacks do ciclo de vida ou suposições sobre a árvore de cenas que causam falhas em tempo de execução. Por exemplo, colocar movimento de CharacterBody2D em _process() em vez de _physics_process() vai passar no lint, compilar e rodar, mas produz comportamento inconsistente entre diferentes hardwares e taxas de frame.