Analisi, piano, codice, controlli: il nostro ritmo per sviluppare con l'IA 🤖

Non abbiamo mai nascosto di usare molto l'IA per Blocks Beyond The Stars — senza, un gioco di queste dimensioni semplicemente non sarebbe fattibile come progetto dopolavoro. Ma per noi "sviluppare con l'IA" non significa: scrivere un desiderio, prendere il risultato, sperare. Con i mesi si è formato uno schema fisso che suona sorprendentemente all'antica — e funziona proprio per questo. Oggi ve lo raccontiamo per intero.

Si comincia sempre con una persona e un'idea. Prima che qualsiasi IA faccia qualcosa, qualcuno ha voluto o notato qualcosa: un giocatore che usa il tasto feedback per segnalare che degli animali compaiono dentro i suoi muri — oppure noi stessi, quando Justus dice a metà partita cosa gli manca. Qui l'IA non inventa compiti. Li riceve.

Poi l'IA lavora per fasi. Quattro, sempre nello stesso ordine: analisi, pianificazione, implementazione, verifica. (Il quinto passo, il test manuale, viene dopo — ma è di nuovo un lavoro umano, ne parliamo tra un attimo.) Il trucco più importante è ciò che all'IA non è permesso fare: scrivere subito codice. Un'IA che si mette a scrivere subito risolve il problema sbagliato a una velocità impressionante. Quindi ogni compito più grande comincia con un'analisi — cosa c'è già, dove sta davvero la causa, cos'altro c'è collegato? Il risultato è testo, non codice.

Poi arriva il piano — e viene letto. All'analisi segue la pianificazione: quali file verranno toccati, in che ordine, quali trappole sono note, quali decisioni sono ancora aperte? È proprio qui che emergono le domande a cui è meglio rispondere prima di programmare ("Dovrebbe funzionare anche nel browser?", "Cosa succede ai vecchi salvataggi?"). Solo quando il piano è in piedi segue l'implementazione — che spesso è la parte più noiosa di tutto. Ed è esattamente come dovrebbe essere.

Le cose collegate vanno in un unico lotto. Una seconda regola che ci fa risparmiare un sacco di tempo: quando diversi problemi sono simili o collegati — cinque menu per gamepad che condividono lo stesso problema di focus, o quindici risultati dello stesso giro di test — l'IA li riceve raggruppati come un unico lavoro, non come quindici separati. Così deve esaminare il codice interessato una volta sola, le soluzioni si incastrano invece di contraddirsi e nulla cade a terra tra un lavoro e l'altro.

Prima di ogni rilascio: due giri di controllo separati. Dopo ogni passo di lavoro più grande — e sempre prima che una nuova versione arrivi a voi — mettiamo di nuovo l'IA sul risultato. Ma con due indagini volutamente separate. Primo: le funzioni e le correzioni previste sono davvero fatte del tutto — o c'è ancora da qualche parte un residuo a metà, un caso limite dimenticato, una traduzione mancante? Secondo, in un passaggio a sé: le modifiche hanno causato nuovi problemi altrove? Mescolare le due cose in una sola domanda non funziona — chi cerca contemporaneamente lacune e danni collaterali ne trova la metà di entrambi. Poste separatamente, queste due domande ci risparmiano un'enorme quantità di lavoro rifatto; una buona parte delle cose che nelle note di rilascio compaiono come "sistemato strada facendo" viene proprio da questi giri di controllo.

E alla fine, una persona testa di nuovo. Il quinto passo non è una fase dell'IA ma nostra: il test manuale significa giocare davvero. Versione appena compilata, un vero gamepad, un vero bambino che gioca. Un sacco di cose che sopravvivono a ogni analisi muoiono nei primi cinque minuti sul divano. Perché se qualcosa si sente giusto è una domanda a cui nessuna analisi al mondo sa rispondere.

Guardando bene, in questo schema non c'è nessuna magia dell'IA, solo un antichissimo mestiere da ingegneri: prima capire, poi pianificare, poi costruire, poi controllare. E per noi la parentesi intorno è sempre la stessa: una persona ha l'idea, una persona fa il test finale — l'IA lavora nel mezzo. L'unica novità è quanto sia diventato veloce questo ciclo. 🔍