Le idee migliori nascono dai progetti più assurdi

A volte le scoperte più interessanti arrivano quando smetti di cercarle.

Immagina di essere un developer appena licenziato. Settimane di colloqui che non portano a nulla. Frustrazione che si accumula. Poi, un giorno, qualcosa scatta. Decidi di costruire qualcosa invece di lamentarti. Qualcosa di ambizioso. Qualcosa che ti costringa a imparare strumenti nuovi.

È successo proprio a me. E ho creato un MMO dove ogni NPC è controllato da un LLM, trattato esattamente come un giocatore. Il nome? SAO: Slop Art Online. (Sì, è un riferimento. No, non chiedo scusa.)

Il dilemma tecnologico

Per questo progetto ho scelto strumenti che non esattamente "beginner friendly": Rust, Bevy, e SpacetimeDB. Framework incredibili, non fraintendermi. Ma non sono il punto di partenza più ovvio per un gioco.

Era intenzionale, però. Volevo attrito. Volevo costringermi a capire cosa succedeva realmente sotto il cofano.

L'idea era semplice ma ambiziosa: NPC e giocatori indistinguibili a livello architetturale. L'unica differenza? Gli NPC prendono decisioni dagli LLM invece che da cervelli umani. Mercanti, guardie, politici, mostri—tutti governati dagli stessi sistemi.

Il mio approccio iniziale era naif ma funzionava: snapshot del mondo osservabile, azioni disponibili, invio a un LLM, attesa risposta. Funzionava. Finché non ha smesso di funzionare.

Il problema del tempo reale

Ecco il problema con i MMO: non aspettano. Il combattimento è in tempo reale. I giocatori si aspettano reazioni istantanee, non dopo una chiamata a un LLM. Per quanto ottimizzassi l'inferenza, quella latenza non sarebbe mai scomparsa.

Ho pensato di fare fine-tuning di un modello più piccolo. Ma costava troppo e sarebbe stato rigido. Le meccaniche di gioco non erano nemmeno definitive—allenare un modello su obiettivi mobili sembrava contorto.

Poi è arrivata la svolta: un'architettura ibrida.

Invece di basarmi solo sugli LLM per le decisioni, ho implementato behavior tree come fondamento. Ogni tipo di NPC ha un tree di default basato sul suo ruolo. L'LM diventa un "rigeneratore" che aggiorna questi tree in base a ciò che l'NPC "sperimenta". Esecuzione deterministica e istantanea incontra adattabilità situazionale.

[Stato SpacetimeDB] → [Behavior Tree Dispatch] → [Esecuzione Azione]
                          ↑
                          | (decisioni rare)
                    [LLM Bridge]

La magia funzionava grazie all'architettura push-based di SpacetimeDB. Il bridge LLM riceve sempre uno stato di gioco fresco e contestualizzato. Non una lista piatta di tools. Non un prompt statico. Una proiezione viva del mondo così come esiste adesso, con azioni connesse semanticamente alla situazione corrente.

La domanda che ha cambiato tutto

A quel punto architetturale, è emerso un pensiero strano:

Perché non esistono già protocolli AI fatti così?

Perché esponiamo liste piatte di tools agli LLM? Perché usiamo interfacce pensate per occhi umani? Cosa succederebbe se progettassimo sistemi specificamente per agent AI—macchine che hanno bisogno di stato push-based, azioni contestualizzate, e framework decisionali strutturati?

Il pattern del behavior tree non è solo per i giochi. È un modello collaudato per il decision-making AI. Il concetto di spingere stato rilevante invece di far pollare gli agenti? Non è miglioramento incrementale—è un cambio di paradigma.

Cosa significa davvero Agent-First Design

Qui le cose si fanno interessanti per chiunque costruisca con AI. Siamo ancora nell'era dell'adattare interfacce umane per macchine. Ma cosa succederebbe se invertissimo?

Un protocollo agent-first potrebbe essere:

• Stato push-based: i sistemi spingono contesto rilevante agli agent, non il contrario
• Azioni contestualizzate: tools che capiscono la loro rilevanza attuale basata sullo stato
• Spazi decisionali strutturati: gerarchie chiare per le decisioni, non scelta illimitata
• Validazione integrata: reducer che assicurano consistenza dello stato prima e dopo le azioni

Pensa a quanto dello sviluppo AI attuale riguarda prompt engineering solo per far capire ai modelli quali azioni sono possibili e quando. Ora immagina un protocollo dove quel contesto è inerente, sempre fresco, sempre rilevante.

La lezione inaspettata

Ecco cosa mi ha insegnato il vibe coding: a volte le intuizioni più preziose arrivano costruendo qualcosa di ambizioso con strumenti nuovi. Sono partito per fare un gioco con NPC AI. Sono finito a mettere in discussione assunzioni fondamentali su come gli agent AI dovrebbero interagire con i sistemi.

Il protocollo che sto abbozzando non è solo teorico. Nasce da vincoli reali, decisioni architetturali reali, e lezioni apprese spingendo gli LLM in territori dove non erano stati progettati.

Se stai facendo vibe coding adesso—che sia un gioco, un'app, o un esperimento folle—fai attenzione ai momenti in cui pensi "non dovrebbe funzionare così". Quei punti di attrito rivelano spesso di più sul futuro dell'AI di qualsiasi roadmap.

Il meglio? Non avrei mai trovato queste intuizioni giocando sul sicuro. A volte devi costruire Slop Art Online per scoprire cosa viene dopo.

Hai una storia di vibe coding? I progetti più stupidi portano alle scoperte più interessanti. Condividi la tua esperienza nei commenti—sono genuinamente curioso di vedere quali percorsi inaspettati hanno seguito gli altri.