Vibecoding: come si riscrive
un classico arcade nel 2026

Il primo gioco che ho provato a riscrivere con l'AI è durato undici secondi. Un canvas bianco, una pallina che partiva verso l'alto e usciva dallo schermo per non tornare più. Era Pong, teoricamente. In pratica era un punto che fuggiva dalla finestra del browser. Ho guardato il codice, ho guardato lo schermo vuoto, e ho pensato: forse dovrei leggere la documentazione di canvas prima di chiedere a Claude di scrivermi un gioco intero.

Quel momento è il riassunto perfetto di cosa significa fare vibecoding nel 2026. Su PixelPrompt abbiamo riscritto da zero sette classici arcade (Pong, Snake, Tetris, Pac-Man, Space Invaders, Arkanoid, Donkey Kong) usando Claude come copilota. Non emulatori, non porting: codice JavaScript nuovo, su canvas HTML5, con la pretesa di ricreare il game feel dell'originale. Quello che ho imparato in questo processo vale più di qualsiasi corso di prompt engineering.

Vibecoding non è quello che pensi

Il termine “vibecoding” gira molto nel 2026, di solito con un'accezione negativa: gente che butta prompt a un LLM e incolla l'output senza capirlo. Quello non è vibecoding. Quello è copia-incolla con più passaggi.

Il vibecoding vero, quello che faccio su PixelPrompt, è più vicino al pair programming. Io conosco il gioco: ci ho giocato da bambino, so come deve suonare il salto di Mario, so che le botti di Donkey Kong devono avere quel rimbalzo specifico sulle scale. Claude conosce il codice: sa scrivere un game loop, sa implementare il collision detection, sa generare una tile map. Il punto di incontro è dove nasce qualcosa di interessante.

Abbiamo un principio su PixelPrompt: l'AI è lo scalpello, non lo scultore. Io decido il design. Io decido che la gravità di Tetris deve accelerare del 15% ogni livello e non del 20%. Io decido che il fantasma rosa di Pac-Man deve puntare a due tile davanti al giocatore, non quattro. Claude scrive il boilerplate, genera le alternative, mi fa risparmiare ore di syntax lookup. Ma le decisioni di game design sono mie.

Il processo reale, senza filtri

Ogni gioco su PixelPrompt segue lo stesso ciclo. Non è lineare e non è pulito.

Fase 1: la bozza che funziona (ore 0-2). Chiedo a Claude la struttura base. Game loop, canvas, sprite rendering, input handler. In due ore ho qualcosa che si muove sullo schermo. È brutto, è impreciso, ma si muove. Questa è la fase in cui l'AI brilla: il boilerplate esce veloce e quasi sempre corretto.

Fase 2: il game feel che manca (ore 2-8). Qui inizia il lavoro vero. La pallina di Pong rimbalza, ma non ha peso. Il salto di Mario è lineare, quando dovrebbe avere accelerazione gravitazionale. Le sprite di Space Invaders si muovono a scatti invece di scorrere fluide. È in questa fase che l'AI fatica di più, perché il game feel non si descrive con un prompt. Si sente. Ho passato un pomeriggio intero a dire a Claude “il salto è troppo leggero”, “ancora troppo leggero”, “adesso è troppo pesante”, “torna indietro di mezzo punto”. Iterazione pura.

Fase 3: il bug che ti insegna l'originale (ore 8-20). Ogni gioco ha avuto almeno un bug che mi ha costretto a studiare la ROM originale. Per Pac-Man, i fantasmi attraversavano i muri del labirinto perché il collision detection controllava il centro della sprite ma non i bordi. Per Tetris, il sistema di rotazione SRS richiedeva una tabella di wall kick che Claude non conosceva e che ho dovuto passargli pezzo per pezzo. Per Donkey Kong, le botti sulle scale: tre giorni per una state machine a tre stati.

Fase 4: il polish infinito (ore 20+). L'input lag di un frame fa la differenza tra un gioco che “si sente giusto” e uno che sembra una copia scadente. Un pixel di offset sulla hitbox cambia completamente la difficulty curve. Questa fase non finisce mai. Ma è quella che trasforma un esercizio tecnico in un gioco a cui la gente torna.

Dove l'AI sbaglia (sempre)

Dopo sette giochi, ho una lista precisa di dove Claude fallisce sistematicamente.

• I numeri magici. Velocità, gravità, accelerazione, tempi di spawn. Claude tira fuori valori ragionevoli ma quasi mai corretti. La velocità della pallina di Pong? Troppo alta. La gravità di Tetris? Troppo lenta. Il frame rate dei fantasmi di Pac-Man al livello 1? Troppo veloce. Ogni volta devo testare, aggiustare, ritestare. I numeri magici sono l'ultima frontiera del game design e l'AI non li azzecca perché non ha mai giocato al gioco.
• Il timing degli effetti sonori. Claude genera la logica per triggerare un suono, ma il momento esatto in cui il suono parte (al frame dell'impatto? un frame prima? due frame dopo?) cambia completamente la percezione. Questo lo trovi solo con le cuffie addosso e il dito sul tasto play.
• I casi limite. Cosa succede quando due botti si sovrappongono sulla stessa scala? Quando il pezzo I di Tetris ruota contro il bordo destro al livello 19? Quando Pac-Man cambia direzione nell'esatto frame in cui un fantasma inverte la sua? Claude gestisce il caso base. I casi limite li trovo io, giocando.

Dove l'AI ti sorprende (quando meno te lo aspetti)

Non è tutto debugging e frustrazione. Ci sono momenti in cui Claude fa qualcosa che non mi aspettavo.

Stavo lavorando su Space Invaders e ho chiesto di implementare il sistema di scudi degradabili. Mi aspettavo una griglia di rettangoli che scompaiono al contatto. Claude ha proposto un sistema a pixel singoli: ogni proiettile rimuove esattamente i pixel che attraversa, creando buchi irregolari nello scudo. Come l'originale. Non glielo avevo chiesto. Ha riconosciuto il pattern dalla sua conoscenza del gioco e ha implementato la versione corretta senza che io specificassi il dettaglio.

Un altro momento: la coda di input per Snake. Ho descritto il problema (“se il giocatore preme due frecce in rapida successione nello stesso frame, la seconda sovrascrive la prima e il serpente muore”) e Claude ha suggerito un buffer FIFO di input con consumo a ogni tick del game loop. Soluzione pulita, tre righe di codice, funzionava al primo tentativo. Ci sono momenti in cui il vibecoding funziona davvero come pair programming con un collega senior.

Sette giochi dopo

Dopo sette giochi riscritti da zero, ecco cosa ho capito del coding con AI applicato allo sviluppo di giochi:

• L'80% del tempo va nel 20% del codice. La struttura base di un gioco arcade esce in ore. Il game feel richiede giorni. L'AI copre il primo pezzo alla velocità della luce; il secondo lo fai tu, a mano, pixel per pixel.
• Devi conoscere il gioco meglio dell'AI. Se non hai mai giocato all'originale, non puoi giudicare se la ricostruzione è fedele. La memoria muscolare conta più della documentazione tecnica.
• I bug più educativi sono quelli dell'originale. La difficoltà progressiva di Space Invaders nacque da un bug di rendering: meno alieni sullo schermo significava meno sprite da disegnare, quindi il frame rate saliva e gli alieni si muovevano più veloce. Un bug diventato meccanica. Ricostruire questi “errori” intenzionalmente è la parte più affascinante del processo.
• L'AI è lo scalpello, non lo scultore. Ogni volta. Senza eccezioni.

Se questo pezzo ti ha incuriosito, su PixelPrompt ogni settimana riscriviamo un classico e raccontiamo cosa abbiamo imparato. Codice, pixel, zero fuffa. Entra nella crew.