La IA puede escribir código de Godot rápido. También puede escribir código de Godot 3 en un proyecto de Godot 4, alucinar APIs que no existen, mover cuerpos físicos en el callback equivocado y conectar señales con patrones que el motor dejó obsoletos hace dos años.
El problema no es que la IA sea mala con Godot. El problema es que la IA se equivoca con Godot de forma confiada, en maneras que parecen correctas si no conoces bien el motor. El código compila. El juego corre. Después algo se rompe en el peor momento posible y no puedes descubrir por qué.
Los propios mantenedores de Godot han señalado esto. Los pull requests generados por IA hacia el propio motor se han convertido en un desgaste recurrente para los mantenedores, quienes cuestionan si los contribuyentes siquiera entendieron o probaron su código. Si eso pasa en el repo del propio motor, también pasa en el tuyo.
Estos son los cinco errores más comunes que vemos en código de Godot generado por IA, detectados durante la revisión de código. Cada ejemplo incluye lo que escribió la IA, por qué parece correcto, por qué falla y qué debería detectar un revisor.
Nota: los ejemplos a continuación son casos de prueba reproducidos, basados en patrones que detectamos consistentemente en repos de Godot. Representan categorías reales de errores de IA, demostradas sobre fixtures de prueba.
1. Código de movimiento de Godot 3.x en un proyecto de Godot 4
Lo que escribe la IA:
extends KinematicBody2D
var velocity = Vector2.ZERO
func _physics_process(delta):
velocity = move_and_slide(velocity, Vector2.UP)Por qué parece correcto: Este es el movimiento de manual de Godot 3. Todos los tutoriales de 2020 a 2022 lo enseñan exactamente así. La estructura es limpia, los nombres de variables tienen sentido, y si eres nuevo en Godot, nada se ve mal.
Por qué falla: KinematicBody2D fue renombrado a CharacterBody2D en Godot 4. move_and_slide() ya no acepta argumentos. En cambio, lee la propiedad velocity incorporada del nodo. La guía oficial de migración lo lista como un cambio importante que rompe compatibilidad.
Qué debería detectar un revisor: Tipo de nodo incorrecto. Firma de método incorrecta. El proyecto fallará con errores de clase y método alrededor de KinematicBody2D y move_and_slide(), pero si el cambio queda enterrado en un PR más grande, la conexión con un cambio de nombre entre Godot 3 y 4 no será obvia para alguien que no conozca la migración.
La corrección:
extends CharacterBody2D
func _physics_process(delta):
velocity = Vector2.ZERO # set before input handling
# ... input logic ...
move_and_slide()2. APIs alucinadas o renombradas
Lo que escribe la IA:
var marker = Position2D.new()
var sprite = Sprite.new()Por qué parece correcto: Position2D y Sprite son clases reales de Godot. Existieron durante años. Aparecen en miles de tutoriales, respuestas de Stack Overflow y foros.
Por qué falla: Ambas fueron renombradas en Godot 4. Position2D se convirtió en Marker2D. Sprite se convirtió en Sprite2D. Los nombres antiguos ya no existen. La documentación de migración lista decenas de cambios de nombre como estos. Los modelos de IA entrenados con contenido anterior a la 4.0 usarán con confianza los nombres antiguos.
Qué debería detectar un revisor: Cualquier nombre de clase de nodo que no aparezca en la referencia de clases de Godot 4.x. Surmado Code Review cruza los diffs contra la documentación actual de Godot, así que las clases renombradas se marcan automáticamente.
3. Movimiento físico en _process() en lugar de _physics_process()
Lo que escribe la IA:
extends CharacterBody2D
func _process(delta):
velocity.x = Input.get_axis("left", "right") * speed
move_and_slide()Por qué parece correcto: El código usa el nodo y método correctos de Godot 4. El manejo de input es limpio. delta está disponible. Corre.
Por qué falla: _process() se ejecuta en cada fotograma renderizado. _physics_process() se ejecuta a una tasa fija (60 veces por segundo por defecto). Mover un CharacterBody2D en _process() causa velocidad de movimiento inconsistente en distinto hardware, tirones durante caídas de frames y detección de colisiones poco confiable. La documentación oficial es explícita: el trabajo relacionado con física pertenece a _physics_process().
Qué debería detectar un revisor: Cualquier move_and_slide(), move_and_collide(), o manipulación directa de velocidad dentro de _process(). Este es el más peligroso de los cinco errores porque el código funciona en pruebas y solo falla bajo condiciones reales.
4. Conexiones de señales basadas en strings
Lo que escribe la IA:
func _ready():
$Button.connect("pressed", self, "_on_button_pressed")Por qué parece correcto: Así funcionaban las señales en Godot 3. Tutoriales, cursos y videos de YouTube enseñan este patrón ampliamente.
Por qué falla: Godot 4 usa conexiones de señales basadas en callables. El connect() de tres argumentos con nombres de método en string está deprecado. La nueva sintaxis es:
func _ready():
$Button.pressed.connect(_on_button_pressed)El estilo antiguo puede seguir funcionando en algunos casos, pero pierde la validación en tiempo de compilación. Si renombras el método más tarde, la conexión por string se rompe silenciosamente en tiempo de ejecución en vez de dar error en el parseo. La documentación de señales de Godot 4 recomienda la forma callable.
Qué debería detectar un revisor: Cualquier patrón .connect("signal_name", target, "method_name") en un proyecto de Godot 4. Es un marcador confiable de código generado por IA proveniente de tutoriales desactualizados.
5. Suposiciones al estilo Unity y rutas frágiles del árbol de escena
Lo que escribe la IA:
func _ready():
var hud = get_parent().get_node("HUD")
var player = get_node("../../Player")
health_bar = get_node("../UI/HealthBar")Por qué parece correcto: Funciona si el árbol de escena luce exactamente como el código asume. Las rutas se resuelven. Los nodos existen.
Por qué falla: La arquitectura de Godot está construida alrededor de escenas componibles que se pueden instanciar en cualquier lugar. Las rutas fijas a padres y hermanos asumen una estructura de árbol fija. Mueve el nodo, reparenta la escena, o reutilízala en otro contexto y las rutas se rompen silenciosamente. La regla práctica en Godot es “llamar hacia abajo, señalar hacia arriba”: los hijos acceden directamente a sus propios hijos, y se comunican hacia arriba mediante señales. El acceso a padres y hermanos debería usar referencias exportadas o consultas de grupo, no rutas fijas.
Qué debería detectar un revisor: get_parent(), get_node(".."), o cualquier ruta que navegue hacia arriba en el árbol. Son frágiles por diseño, y son un patrón que la IA importa del modelo de componentes de Unity, donde GetComponentInParent es común y esperado.
Por qué los linters no detectan esto
El sistema de advertencias incorporado de Godot y herramientas como gdscript-toolkit detectan formato, variables sin usar y algunos problemas de tipos. Son útiles y deberías usarlos.
Pero no detectan APIs de versión incorrecta en un proyecto de Godot 4. No detectan el mal uso de _process() frente a _physics_process(). No saben que tu STANDARDS.MD dice “sin navegación de rutas a padres” o “siempre usar conexiones de señales callable”. Esas son detecciones a nivel de revisión, no a nivel de linter.
Ese es el vacío que llena la revisión de código automatizada. Se ubica entre el linter (que revisa sintaxis) y el revisor humano (que revisa arquitectura), y maneja la capa intermedia: ¿es este código correcto para esta versión del motor, estos estándares y este proyecto?
Detectar esto en cada PR
Surmado Code Review para Godot se ejecuta en cada push a un pull request de GitHub. Revisa el diff contra la documentación oficial de Godot 4.6, el contexto de tu repo y tu STANDARDS.MD. Detecta:
- Errores entre versiones (patrones de Godot 3 en proyectos de Godot 4)
- APIs alucinadas o renombradas
- Mal uso del ciclo de vida (
_processvs._physics_process) - Patrones de señales deprecados
- Suposiciones frágiles sobre el árbol de escena
- Lo que sea que definas en tus estándares
Gratis para 10 PRs al mes. $15/mes por 100. Sin precios por asiento.
Si estás construyendo un juego en Godot con asistencia de IA, la IA es la autora. Necesitas un cerebro distinto como revisor.
Instala Surmado Code Review para Godot (Gratis) →
¿Nuevo en Godot? Pregúntale a GDScout lo que quieras sobre Godot 4.6 en lenguaje claro. Gratis, con citas de la documentación oficial.
Preguntas y respuestas
¿Cuál es la mejor herramienta de revisión de código con IA para Godot? Surmado Code Review para Godot es un revisor automatizado de PRs que revisa los diffs contra la documentación oficial de Godot 4.6, el contexto del repo y el STANDARDS.MD de un equipo. Detecta errores entre versiones (patrones de Godot 3 en proyectos de Godot 4), APIs alucinadas, mal uso del ciclo de vida, patrones de señales deprecados y suposiciones frágiles sobre el árbol de escena. Gratis para 10 PRs al mes, $15 al mes por 100 PRs.
¿Cuáles son los errores comunes de IA en código de Godot 4? Los errores más comunes generados por IA en código de Godot 4 incluyen usar tipos de nodo renombrados de Godot 3 (KinematicBody2D en lugar de CharacterBody2D), pasar argumentos a move_and_slide(), que ya no los acepta en Godot 4, colocar movimiento físico en _process() en lugar de _physics_process(), usar conexiones de señales deprecadas basadas en strings en lugar de conexiones basadas en callables, y fijar rutas de nodos padre/hermano que se rompen cuando se reutilizan escenas.
¿Surmado Code Review funciona con GDScript? Sí. Surmado Code Review soporta GDScript y C# en proyectos de Godot. Las revisiones se basan en la documentación oficial de Godot 4.6 y marcan problemas específicos del motor que las herramientas de revisión de código con IA de propósito general no detectan.
¿En qué se diferencia Surmado Code Review de un linter de GDScript? Los linters de GDScript y el sistema de advertencias incorporado de Godot detectan errores de sintaxis, problemas de formato, variables sin usar y algunos problemas de tipos. Surmado Code Review detecta problemas de nivel más alto: APIs de versión incorrecta, mal uso de callbacks del ciclo de vida, patrones deprecados, arquitectura frágil del árbol de escena y violaciones del STANDARDS.MD del equipo. Los linters y la revisión de código son complementarios. Los linters aplican reglas. La revisión de código evalúa contexto.
¿Puede el código de Godot generado por IA pasar el linting y aun así estar mal? Sí. El código de Godot generado por IA frecuentemente pasa el linting y compila sin errores, pero contiene patrones de versión de motor incorrectos, mal uso de callbacks del ciclo de vida, o suposiciones sobre el árbol de escena que causan fallas en tiempo de ejecución. Por ejemplo, colocar el movimiento de CharacterBody2D en _process() en lugar de _physics_process() pasará el linting, compilará y correrá, pero producirá comportamiento inconsistente en distinto hardware y tasas de fotogramas.