L’IA può scrivere codice Godot velocemente. Può anche scrivere codice Godot 3 in un progetto Godot 4, allucinare API che non esistono, spostare corpi fisici nel callback sbagliato e collegare segnali con pattern che il motore ha deprecato due anni fa.
Il problema non è che l’IA sia scarsa con Godot. Il problema è che l’IA sbaglia con sicurezza, in modi che sembrano corretti se non conosci già il motore. Il codice compila. Il gioco funziona. Poi qualcosa si rompe nel momento peggiore possibile e non riesci a capire perché.
Gli stessi maintainer di Godot lo hanno segnalato. Le pull request generate dall’IA verso il motore stesso sono diventate un peso ricorrente per i maintainer, che si chiedono se i contributori capiscano o abbiano anche solo testato il proprio codice. Se succede sul repo del motore stesso, succede anche sul tuo.
Questi sono i cinque errori più comuni che vediamo nel codice Godot generato dall’IA, colti durante la revisione del codice. Ogni esempio include cosa ha scritto l’IA, perché sembra corretto, perché si rompe e cosa dovrebbe notare un revisore.
Nota: gli esempi qui sotto sono casi di test riprodotti basati su pattern che troviamo costantemente nei repo Godot. Rappresentano categorie reali di errori dell’IA, dimostrate su fixture di test.
1. Codice di movimento Godot 3.x in un progetto Godot 4
Cosa scrive l’IA:
extends KinematicBody2D
var velocity = Vector2.ZERO
func _physics_process(delta):
velocity = move_and_slide(velocity, Vector2.UP)Perché sembra corretto: è il classico movimento da manuale di Godot 3. Ogni tutorial dal 2020 al 2022 lo insegna esattamente così. La struttura è pulita, i nomi delle variabili hanno senso e, se sei nuovo a Godot, niente sembra sbagliato.
Perché si rompe: KinematicBody2D è stato rinominato in CharacterBody2D in Godot 4. move_and_slide() non accetta più argomenti. Invece, legge dalla proprietà velocity integrata nel nodo. La guida ufficiale alla migrazione elenca questo tra i principali breaking change.
Cosa dovrebbe notare un revisore: tipo di nodo sbagliato. Firma del metodo sbagliata. Il progetto fallirà con errori di classe e metodo intorno a KinematicBody2D e move_and_slide(), ma se la modifica è sepolta in una PR più grande, il collegamento con la rinomina Godot 3/4 non sarà ovvio a chi non conosce la migrazione.
La correzione:
extends CharacterBody2D
func _physics_process(delta):
velocity = Vector2.ZERO # set before input handling
# ... input logic ...
move_and_slide()2. API allucinate o rinominate
Cosa scrive l’IA:
var marker = Position2D.new()
var sprite = Sprite.new()Perché sembra corretto: Position2D e Sprite sono classi Godot reali. Sono esistite per anni. Compaiono in migliaia di tutorial, risposte su Stack Overflow e thread di forum.
Perché si rompe: entrambe sono state rinominate in Godot 4. Position2D è diventata Marker2D. Sprite è diventata Sprite2D. I vecchi nomi non esistono più. La documentazione di migrazione elenca decine di rinomine come questa. I modelli IA addestrati su contenuti pre-4.0 useranno con sicurezza i vecchi nomi.
Cosa dovrebbe notare un revisore: qualsiasi nome di classe nodo che non compare nel riferimento delle classi di Godot 4.x. Surmado Code Review confronta i diff con la documentazione Godot attuale, quindi le classi rinominate vengono segnalate automaticamente.
3. Movimento fisico in _process() invece che in _physics_process()
Cosa scrive l’IA:
extends CharacterBody2D
func _process(delta):
velocity.x = Input.get_axis("left", "right") * speed
move_and_slide()Perché sembra corretto: il codice usa il nodo e il metodo corretti di Godot 4. La gestione dell’input è pulita. delta è disponibile. Funziona.
Perché si rompe: _process() viene eseguito a ogni frame renderizzato. _physics_process() viene eseguito a una frequenza fissa (60 volte al secondo di default). Spostare un CharacterBody2D in _process() causa velocità di movimento incoerenti su hardware diversi, scatti durante i cali di frame e rilevamento delle collisioni inaffidabile. La documentazione ufficiale è esplicita: il lavoro legato alla fisica appartiene a _physics_process().
Cosa dovrebbe notare un revisore: qualsiasi move_and_slide(), move_and_collide() o manipolazione diretta della velocità dentro _process(). Questo è il più pericoloso dei cinque errori perché il codice funziona nei test e fallisce solo in condizioni reali.
4. Connessioni di segnali basate su stringhe
Cosa scrive l’IA:
func _ready():
$Button.connect("pressed", self, "_on_button_pressed")Perché sembra corretto: è così che funzionavano i segnali in Godot 3. Tutorial, corsi e video su YouTube insegnano ampiamente questo pattern.
Perché si rompe: Godot 4 usa connessioni di segnali basate su callable. Il connect() a tre argomenti con nomi di metodo in stringa è deprecato. La nuova sintassi è:
func _ready():
$Button.pressed.connect(_on_button_pressed)Lo stile vecchio potrebbe ancora funzionare in alcuni casi ma perde la validazione a tempo di compilazione. Se rinomini il metodo in seguito, la connessione tramite stringa si rompe silenziosamente a runtime invece di generare un errore in fase di parsing. La documentazione sui segnali di Godot 4 raccomanda la forma callable.
Cosa dovrebbe notare un revisore: qualsiasi pattern .connect("signal_name", target, "method_name") in un progetto Godot 4. È un indicatore affidabile di codice generato dall’IA proveniente da tutorial obsoleti.
5. Assunzioni in stile Unity e percorsi fragili nell’albero della scena
Cosa scrive l’IA:
func _ready():
var hud = get_parent().get_node("HUD")
var player = get_node("../../Player")
health_bar = get_node("../UI/HealthBar")Perché sembra corretto: funziona se l’albero della scena ha esattamente la struttura che il codice presuppone. I percorsi si risolvono. I nodi esistono.
Perché si rompe: l’architettura di Godot è costruita attorno a scene componibili che possono essere istanziate ovunque. Percorsi hardcoded verso genitori e fratelli presuppongono una struttura ad albero fissa. Sposta il nodo, riassocia la scena a un altro genitore o riutilizzala in un contesto diverso, e i percorsi si rompono silenziosamente. La regola pratica in Godot è “chiama verso il basso, segnala verso l’alto”: i figli accedono direttamente ai propri figli e comunicano verso l’alto tramite segnali. L’accesso a genitori e fratelli dovrebbe usare riferimenti esportati o query di gruppo, non percorsi hardcoded.
Cosa dovrebbe notare un revisore: get_parent(), get_node("..") o qualsiasi percorso che risale nell’albero. Sono fragili per design, e sono un pattern che l’IA importa dal modello a componenti di Unity, dove GetComponentInParent è comune e atteso.
Perché i linter non lo colgono
Il sistema di avvisi integrato di Godot e strumenti come gdscript-toolkit colgono la formattazione, le variabili inutilizzate e alcuni problemi di tipo. Sono utili e dovresti usarli.
Ma non colgono le API della versione sbagliata in un progetto Godot 4. Non colgono l’uso improprio di _process() rispetto a _physics_process(). Non sanno che il tuo STANDARDS.MD dice “niente navigazione con percorsi verso il genitore” o “usa sempre connessioni di segnali callable”. Quelle sono correzioni a livello di revisione, non a livello di linting.
È questo il vuoto che la revisione del codice automatizzata colma. Si colloca tra il linter (che controlla la sintassi) e il revisore umano (che controlla l’architettura), e gestisce lo strato intermedio: questo codice è corretto per questa versione del motore, questi standard e questo progetto?
Colti in ogni PR
Surmado Code Review per Godot viene eseguito a ogni push su una pull request GitHub. Confronta il diff con la documentazione ufficiale di Godot 4.6, il contesto del tuo repo e il tuo STANDARDS.MD. Cattura:
- Errori tra versioni (pattern Godot 3 in progetti Godot 4)
- API allucinate o rinominate
- Uso improprio del ciclo di vita (
_processcontro_physics_process) - Pattern di segnali deprecati
- Assunzioni fragili sull’albero della scena
- Qualsiasi altra cosa tu definisca nei tuoi standard
Gratuito per 10 PR al mese. $15/mese per 100. Nessun prezzo per posto.
Se stai costruendo un gioco Godot con l’assistenza dell’IA, l’IA è l’autrice. Ti serve un cervello diverso come revisore.
Installa Surmado Code Review per Godot (gratuito) →
Nuovo a Godot? Chiedi a GDScout qualsiasi cosa su Godot 4.6 in linguaggio semplice. Gratuito, con citazioni dalla documentazione ufficiale.
Domande e risposte
Qual è il miglior strumento di revisione del codice IA per Godot? Surmado Code Review per Godot è un revisore automatizzato di PR che confronta i diff con la documentazione ufficiale di Godot 4.6, il contesto del repo e il STANDARDS.MD di un team. Coglie errori tra versioni (pattern Godot 3 in progetti Godot 4), API allucinate, uso improprio del ciclo di vita, pattern di segnali deprecati e assunzioni fragili sull’albero della scena. Gratuito per 10 PR al mese, $15 al mese per 100 PR.
Quali sono gli errori comuni dell’IA nel codice Godot 4? Gli errori più comuni generati dall’IA nel codice Godot 4 includono l’uso di tipi di nodo rinominati di Godot 3 (KinematicBody2D invece di CharacterBody2D), il passaggio di argomenti a move_and_slide() che non li accetta più in Godot 4, il posizionamento del movimento fisico in _process() invece che in _physics_process(), l’uso di connessioni di segnali basate su stringhe deprecate invece di connessioni basate su callable, e l’hardcoding di percorsi verso nodi genitori/fratelli che si rompono quando le scene vengono riutilizzate.
Surmado Code Review funziona con GDScript? Sì. Surmado Code Review supporta GDScript e C# nei progetti Godot. Le revisioni si basano sulla documentazione ufficiale di Godot 4.6 e segnalano problemi specifici del motore che gli strumenti generici di revisione del codice IA non colgono.
In cosa Surmado Code Review è diverso da un linter GDScript? I linter GDScript e il sistema di avvisi integrato di Godot colgono errori di sintassi, problemi di formattazione, variabili inutilizzate e alcuni problemi di tipo. Surmado Code Review coglie problemi di livello più alto: API della versione sbagliata, uso improprio dei callback del ciclo di vita, pattern deprecati, architettura fragile dell’albero della scena e violazioni del STANDARDS.MD del team. Linter e revisione del codice sono complementari. I linter applicano regole. La revisione del codice valuta il contesto.
Il codice Godot generato dall’IA può passare il linting ed essere comunque sbagliato? Sì. Il codice Godot generato dall’IA passa spesso il linting e compila senza errori ma contiene pattern di versione del motore errati, uso improprio dei callback del ciclo di vita o assunzioni sull’albero della scena che causano guasti a runtime. Ad esempio, posizionare il movimento di un CharacterBody2D in _process() invece che in _physics_process() supererà il linting, compilerà ed eseguirà, ma produrrà un comportamento incoerente su hardware e frame rate diversi.