Peter Gostev ha costruito DOOMQL usando GPT-5.6 Sol: un piccolo gioco Doom-like in cui SQLite è il motore grafico, non il posto dove salvare i dati. Movimento, collisioni, nemici, combattimento e ogni pixel RGB vivono dentro query SQL, compreso un ray tracer completo implementato come recursive CTE.

Il database si può ispezionare con Datasette: una demo pubblica mostra un’app HTML+JavaScript che legge la vista frame_pixels in tempo reale mentre il gioco gira nel terminale, con una minimappa aggiunta con Claude Fable 5 in pochi minuti.

Perché ti riguarda. Non è un tool pronto, è un caso di studio su cosa succede quando dai a un modello un obiettivo tecnico preciso e lo spazio per lavorarci. Il codice è pubblico su GitHub, si clona e si esegue in cinque minuti (uv run host/doomql.py). Non è la fattibilità che conta — SQL non è fatto per renderizzare frame — è il processo: un problema irrealistico decomposto in passi eseguibili, con il modello che scrive codice che gira davvero.

Se stai sperimentando con agenti di coding, questo è il tipo di esperimento che mostra i limiti pratici: dove il modello risolve, dove hai bisogno di verificare, e quanto lontano puoi spingerti prima che l’output diventi troppo fragile.

Nel dettaglio

Il contesto. I modelli frontier come GPT-5.6 Sol, Claude Fable 5 e Muse Spark 1.1 hanno cambiato la scala dei progetti che puoi affidare a un assistente di coding: da “scrivi questa funzione” a “costruisci questo sistema”. DOOMQL è un esperimento al limite di quella capacità: un sistema completo dove il modello ha dovuto capire come rappresentare grafica 3D, fisica basilare e logica di gioco dentro un motore che non è fatto per nessuna di quelle cose.

Come funziona. Il gioco è uno script Python terminale che crea un database SQLite. Ogni frame è una query: una recursive CTE implementa il ray casting (proiezione dei raggi dal punto di vista del giocatore), calcola le distanze dalle pareti, determina l’altezza delle colonne sullo schermo e genera i valori RGB per ogni pixel. Il risultato finisce in una vista frame_pixels(x, y, r, g, b) che puoi interrogare o visualizzare.

Il database si ispeziona con Datasette e il plugin datasette-apps, che permette di creare interfacce HTML+JavaScript dentro Datasette stesso. Nella demo, un prompt a Claude (“costruisci un’app che mostri lo stato dello schermo dalla vista frame_pixels, aggiorna ogni secondo”) ha prodotto in un giro un visualizzatore funzionante. La minimappa è arrivata con “aggiungi una minimap”, senza dover riscrivere l’app.

Cosa dice davvero. L’esperimento non dimostra che SQL è un buon motore grafico — non lo è. Dimostra che un modello forte può tradurre un problema assurdo in codice eseguibile, se gli dai:

1. Un obiettivo tecnico preciso (“SQL come motore grafico”).
2. Un linguaggio con semantica rigorosa (SQL, dove una query corretta fa sempre la stessa cosa).
3. Uno spazio di lavoro isolato dove provare e correggere (il database locale).

Il codice prodotto è leggibile e pubblico: puoi seguire la logica del ray tracer dentro la CTE, vedere come rappresenta lo stato del gioco e dove il modello ha fatto scelte di design (per esempio, come gestisce le collisioni con query ricorsive invece di un ciclo imperativo).

I limiti. Non sappiamo quanti tentativi ci sono voluti prima di arrivare a una versione funzionante, né quanta supervisione umana è servita per correggere errori logici o prestazioni. Un progetto come questo richiede molti giri di verifica: SQL è preciso ma non perdona, e un bug in una CTE ricorsiva è difficile da isolare anche per un umano. Il repo non documenta il processo di sviluppo, solo il risultato finale.

Inoltre, l’esperimento è volutamente piccolo: un livello, nemici basilari, nessuna IA avversaria complessa. Aggiungere complessità (più livelli, interazioni più ricche) potrebbe portare il sistema oltre il limite di ciò che SQL può gestire con prestazioni accettabili.

Cosa farne. Se lavori con coding agents, questo caso è utile per due motivi:

1. Ti mostra dove guardare quando valuti un output. Il codice di DOOMQL è verificabile: puoi eseguirlo, ispezionare il database, leggere le query. Un assistente che produce codice su questa scala deve generare artifact che puoi eseguire e capire, non solo incollare.
2. Ti dà un esempio di problema irrealistico risolto bene. Costruire un gioco in SQL è un problema con vincoli forti e una soluzione non banale. Se stai testando un modello su task non standard, scegli problemi con questa struttura: obiettivo chiaro, verifica immediata (gira o non gira), e abbastanza complessità da far emergere i limiti.

Per provarlo, clona il repo e segui il README: cinque minuti per avere il gioco che gira, altri cinque per aprire il database in Datasette e vedere cosa c’è dentro. Non è un tool che userai in produzione, ma è un buon esempio di cosa puoi chiedere a un modello quando sai cosa verificare.