Diario di una troupe di agenti AI che fa cinema

Episodio 3 — Dove finiscono le scene scomparse

Cinque scene in entrata. Quattro in uscita. Nessun errore.

Se hai mai programmato qualcosa, sai che questo è il tipo di bug che ti toglie il sonno. Un programma che esplode con un errore rosso fiammante è quasi un sollievo: ti dice dove ha sbagliato, lo aggiusti, vai avanti. Ma un programma che perde una scena per strada e prosegue tranquillo, fischiettando, come se nulla fosse — quello è il male. Perché non te lo dice. Lo scopri tre settimane dopo, quando il film ha un buco, e devi risalire la corrente per capire in quale punto della catena la scena ha deciso di andarsene.

Questo episodio è la caccia a quelle scene.

Un piccolo ripasso, per chi non vive di codice

Gli agenti della mia troupe si passano il lavoro sotto forma di JSON. Il JSON è il modo standard con cui i programmi si scambiano dati strutturati: parentesi, virgolette, due punti, tutto incolonnato secondo regole precise. È pignolo come un notaio. Una virgoletta fuori posto e l’intero documento, per la macchina, diventa carta straccia illeggibile.

Ora, il problema è questo: i modelli linguistici sono fenomenali a scrivere linguaggio, ma sono dattilografi mediocri. Gli chiedi un documento perfettamente formattato e nel 95% dei casi te lo danno impeccabile. Nel restante 5% ci infilano un errore di battitura che manda tutto a gambe all’aria. E il 5% di una catena lunga, su un film intero, significa che qualcosa si rompe quasi sempre.

L’italiano peggiora le cose. È una lingua piena di apostrofi — l’orco, c’è, un’ombra, dell’accetta — e ogni apostrofo è una potenziale mina per un dattilografo distratto.

L’arma del delitto

Quando finalmente ho rintracciato il punto in cui le scene sparivano, ho trovato il colpevole, ed era una mia riga di codice.

Senza entrare nel tecnicismo: avevo scritto un meccanismo che, quando incontrava una scena con il JSON malformato, la saltava in silenzio e passava alla successiva. L’avevo programmato io, con le mie mani, probabilmente convinto di essere prudente. In pratica avevo costruito una troupe in cui, se un membro consegnava un foglio con un refuso, il foglio veniva cestinato senza dire niente a nessuno — e la produzione andava avanti con una scena in meno, allegramente.

Il bug non era nel modello. Era nella mia idea di “gestione dell’errore”. Avevo confuso non far crashare il programma con gestire il problema. Sono due cose diversissime.

La prima vera lezione: rompiti rumorosamente

Da qui è nato uno dei principi portanti di tutto il progetto: i fallimenti silenziosi sono i peggiori. Meglio un sistema che urla.

Ho ribaltato l’approccio. Invece di saltare in silenzio la scena rotta, adesso il sistema produce un oggetto-errore ben visibile che dice, in chiaro: la scena tre si è rotta, ecco perché, ecco il pezzo di testo incriminato. Non nasconde niente. Se qualcosa va storto, lo voglio sapere subito, a voce alta, non scoprirlo a film finito.

È un cambio di mentalità più che di codice. Smetti di proteggere il programma dagli errori e cominci a proteggere te stesso dalla loro invisibilità.

Lo strato più profondo: insegnare a scrivere

Sistemato il codice, restava il dattilografo. Perché continuare a raccogliere gli errori va bene, ma se il modello sbaglia a ogni giro, passi la vita a tappare buchi.

Studiando come sbagliava, ho notato che i modelli producevano JSON malformato sempre negli stessi modi ricorrenti: ogni tanto andavano a capo dentro una frase rompendo la struttura; ogni tanto, dopo un valore vuoto, ci aggiungevano una nota tra parentesi come per spiegarsi meglio (gentilissimi, e devastanti); ogni tanto mettevano o toglievano virgolette nei punti sbagliati; ogni tanto impacchettavano tutto dentro la formattazione che si usa per il codice, mandando in confusione il lettore automatico.

La contromossa è stata insegnare a ogni agente della troupe la stessa manciata di regole di battitura — un piccolo galateo del JSON, identico per tutti. Non ti svelo il testo (sono i miei prompt), ma il concetto è semplice: stabilire una volta per tutte quali sono i delimitatori validi, lasciare in pace gli apostrofi, mettere in salvo le virgolette interne, vietare le notine dopo i valori vuoti, e bandire la formattazione-codice. Più, sotto a tutto, una rete di sicurezza: uno strato di codice che ripara i piccoli refusi prima che facciano danni. Cintura e bretelle.

Il collega smemorato

C’è un’altra trappola che ho incontrato qui e che vale la pena raccontare, perché è controintuitiva. Nel mio sistema di automazione, quando un agente finisce il suo turno, dimentica i dati di contesto con cui era entrato. È fatto così: il modello ti restituisce il suo lavoro, ma si “scorda” l’etichetta che diceva questa è l’inquadratura SC03_SH06.

Il rimedio ovvio è riattaccare l’etichetta dopo. Ma qui scatta la trappola: se la riattacchi per posizione — il quinto risultato deve essere la quinta inquadratura — e nel frattempo una scena è sparita in silenzio (vedi sopra), allora tutto slitta di uno. Da quel punto in poi ogni inquadratura porta l’etichetta sbagliata. Un singolo elemento perso e mezzo film prende il nome di quello accanto.

La soluzione è non fidarsi mai della posizione. Riattacchi l’identità tramite una chiave univoca, non tramite “il quinto della fila”. Così, anche se qualcuno sparisce, gli altri restano sé stessi.

I gremlin dei nomi

Ultimo della collezione, il più subdolo per la sua banalità: la deriva dei nomi. Un modello, lungo un’esecuzione, ti scrive “Volpe” per dieci inquadrature e poi, senza motivo, “Volve”. Oppure trasforma padre_accetta in padre_accenta. Sono refusi minuscoli, ma per la macchina sono due personaggi diversi: gli agenti a valle trattano Volpe e Volve come due entità separate, e di colpo nel tuo film c’è un sosia fantasma.

La cura è ancorare gli identificativi dei personaggi come token immutabili — scolpiti nella pietra all’inizio e mai più toccati — e affidare i compiti più delicati al modello più sveglio, non a quello economico. Ogni reparto al modello giusto: anche questo è un principio che tornerà.

Cosa mi ha insegnato la caccia

La morale di questo episodio non è tecnica, è quasi filosofica. Per settimane avevo creduto di avere un sistema funzionante, perché sembrava funzionare: girava, non crashava, sfornava file. Solo che mentiva. La distanza tra “sembra funzionare” e “funziona davvero” è fatta esattamente di questi bug invisibili, ed è la distanza più lunga di tutto il progetto.

Una volta che le scene hanno smesso di sparire, ho potuto finalmente fare la cosa per cui avevo costruito tutto: generare le immagini.

E lì ho conosciuto una delusione di tutt’altro tipo. Le facce.

Prossimo episodio: generare immagini. Le facce sbagliate (e chi decide cosa puoi disegnare).

Sono Massimo, di Mondo Digitale, Bologna. Progetto e orchestro sistemi multi-agente su n8n per la produzione audiovisiva. Se è il tuo campo – o cerchi qualcuno che lo faccia – scrivimi: info@mondodigitale.com