Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
Secondo di tre articoli sulla costruzione della mia video factory. Il primo racconta il pilota sulla CDP, il workflow locale della voce e la direzione visiva; questo racconta come il lavoro è passato tra Codex, Claude Cowork e me.
L’8 settembre Claude ha revisionato i tre master finali che Codex aveva prodotto per gli articoli su CDP, DMP e CEP, oggi tutti e tre pubblici sul mio canale YouTube insieme agli episodi successivi. La revisione ha misurato i file consegnati in modo indipendente: ha decodificato ogni fotogramma, li ha contati rispetto agli storyboard, ha misurato il loudness, ha campionato ogni transizione tra scene a metà dissolvenza e ha verificato che l’audio approvato fosse passato senza ricodifica. Tutti e tre hanno superato i controlli. La revisione ha però trovato anche un’etichetta che usciva dal suo riquadro nel video sul DMP, e dei buchi nei registri che descrivevano come i file fossero arrivati al loro stato finale.
La seconda revisione mi ha dato prove utilizzabili e ha trovato cose da cambiare, mentre ogni decisione su quei cambiamenti è rimasta mia, e nessun accordo tra due sistemi poteva sostituire il fatto di guardare il risultato.
Due collaboratori AI sono serviti davvero solo quando il secondo aveva qualcosa da verificare in modo indipendente. La cartella condivisa, i report di revisione e i limiti posti a ogni compito hanno fatto gran parte del lavoro che un’espressione come “collaborazione multi-agente” di solito lascia inspiegato.
Tre contributori su una sola produzione video
Avevo già usato Claude Cowork per questo sito e per la demo di Braze, e Codex è entrato nel mio modo di lavorare come secondo partner di sviluppo.
Codex ha fatto la maggior parte dell’implementazione: scrivere e rivedere il codice delle scene, collegare la narrazione alla timeline, lanciare i render e produrre i master finali con i relativi report di verifica. Claude Cowork ha contribuito con le revisioni, le correzioni al processo, le istruzioni riusabili e il lavoro che ha collegato i video finiti a YouTube e a questo sito. Io ho scelto la direzione, registrato il riferimento per la voce, contestato i risultati e deciso cosa fosse pronto per andare avanti.
In pratica entrambi scrivevano codice ed entrambi facevano controlli: una sessione di Claude che revisionava i problemi di transizione ha anche scritto un controllo apposito, e una sessione di Codex che implementava una correzione ha anche verificato il file che consegnava.
Il lavoro tra l’uno e l’altro lo portavo io. Riportavo una revisione nella sessione di implementazione, oppure chiedevo a un’altra sessione di ispezionare i file correnti, e la produzione non ha mai fatto finta che due cronologie di chat separate formassero una memoria comune. Perché una decisione sopravvivesse alla sessione in cui l’avevo presa, doveva essere scritta dove la sessione successiva l’avrebbe letta.
La cartella del job che portava ogni passaggio di consegne
Ogni video aveva la sua cartella di job, con l’articolo di partenza, il brief creativo, lo script, lo storyboard, l’audio e le prove delle revisioni. Un manifest registrava lo stato della produzione e puntava ai file correnti, e un registro delle approvazioni conservava le decisioni che permettevano a ogni fase di partire. La factory non ha un controllo di versione suo, quindi quei due file erano appunto la storia del job.
Servivano a rendere leggibile la produzione in corso. Chi riprendeva il video sul DMP doveva sapere quale narrazione era approvata, quale file di revisione era stato superato, cosa chiedeva l’ultimo feedback e se un altro render completo fosse autorizzato; senza quelle risposte, la cartella offriva più versioni plausibili di ognuna.
La copia dell’articolo di partenza risolveva un’altra ambiguità. Gli articoli continuano a cambiare sul sito mentre il video è in produzione, e conservare il testo esatto da cui un job era partito permetteva di capire da dove venisse lo script, senza dare per scontato che l’articolo online coincidesse ancora con la versione di qualche settimana prima.
A livello di progetto, istruzioni condivise raccoglievano le decisioni valide per tutti i video: il profilo vocale da riusare, il kit visivo da cui partire, dove stava il codice di produzione e quali controlli lanciare prima di chiedere un render costoso. Tengo un contesto scritto per il resto del sito per le stesse ragioni, ma il lavoro sui video metteva alla prova quei documenti molto più in fretta: quando il collaboratore successivo non sapeva quale fosse l’audio approvato, il problema si sentiva.
I file da soli non garantivano un passaggio di consegne corretto, e la revisione di settembre ha trovato registri rimasti indietro rispetto al lavoro. Un manifest rende esplicito lo stato, e quello stato va comunque verificato.
Quando una seconda revisione ha cambiato l’implementazione
Il problema delle transizioni è il caso più chiaro di una revisione che ha migliorato più di un file.
Diverse scene del video sulla CDP cambiavano stato facendo sparire un diagramma completo mentre compariva il successivo, sempre completo. A metà passaggio erano leggibili entrambi nella stessa zona dello schermo. Ogni stato fermo andava bene, ma il movimento tra l’uno e l’altro mostrava per un istante un’architettura che la narrazione non stava descrivendo, e la revisione finale del master sulla CDP, il 13 agosto, lo ha bloccato proprio per questo, in sei scene su quattordici.
Figura 1. Lo stesso momento del video sulla CDP in un master di agosto bloccato in revisione (1) e nella versione pubblicata (2). Nel primo si leggono due architetture complete, mentre il claim ne nomina una sola.
Era un difetto facile da perdere se si campionavano solo le scene ferme, e spiegava perché chiedere un video più animato potesse renderlo più difficile da seguire, finché il movimento non aveva regole su cosa restasse visibile.
Una volta corretto il difetto, il 29 agosto una sessione di Claude ha ripassato con me il lavoro rimasto. Volevo che i video successivi richiedessero meno giri di revisione e meno fatica, così Claude ha aggiunto un lint delle transizioni, che segnala lo schema di codice preciso dietro quel difetto (una dissolvenza in uscita scritta fuori dall’helper condiviso per i passaggi di stato), e ha scritto un brief di avvio che indirizza ogni nuova produzione verso quegli helper e verso il kit editoriale costruito per il DMP.
Il lint può segnalare uno schema di dissolvenza rischioso nel codice, ma non può dimostrare che ogni transizione si legga bene sullo schermo, quindi il workflow continua a campionare i fotogrammi ai confini tra gli stati, dove i diagrammi sovrapposti comparirebbero davvero. Così la sessione successiva parte da uno schema approvato, lancia un controllo gratuito e poi guarda i fotogrammi che contano.
Per lo stesso motivo si partiva dai componenti più recenti: il kit successivo conteneva le decisioni a cui il pilota della CDP era arrivato solo a forza di correzioni.
Verificare in modo indipendente il video consegnato
A inizio settembre avevamo tre master finali. Li aveva prodotti Codex, compresa una correzione nella scena 09 del DMP che dava più spazio a un titolo sopra la card sottostante. La revisione di Claude è partita dai file consegnati e ha trattato il report di implementazione come un’affermazione da verificare.
Alcuni controlli coprivano ogni fotogramma di ogni file: una decodifica completa alla ricerca di errori, il conteggio dei fotogrammi rispetto a ciascuno storyboard e il loudness misurato sul file consegnato. Altri erano campionati, cioè uno stato fermo per scena, tutti i 39 punti a metà transizione e una serie di punti lungo la timeline. Nessuno ha guardato di fila tutti i 22 minuti.
Il controllo più utile ha messo alla prova l’affermazione che la correzione del DMP restasse confinata nella scena 09. Claude ha decodificato 18 fotogrammi distribuiti su tutto il video, dal vecchio e dal nuovo master, e li ha confrontati pixel per pixel. I tre che cadevano dentro la scena 09 erano diversi, i quindici fuori erano identici ed anche le tracce audio estratte coincidevano esattamente con quelle approvate. Il risultato vale per i punti campionati, ed è così che lo descriveva il report.
Poi la revisione ha trovato un problema diverso nella scena 12. La parola FORMER usciva dal bordo destro del suo riquadro, e l’origine di un connettore cadeva sopra la lettera di troppo. Il fotogramma era identico nella versione approvata, quindi non l’aveva causato la correzione della scena 09: il difetto c’era già quando avevo approvato l’immagine. Il report diceva che lasciarlo com’era sarebbe stato difendibile. Ho scelto di correggerlo.
Figura 2. La scena 12 del video sul DMP nella versione che avevo approvato (1) e dopo la correzione (2). Pannello, connettori e tempi restano dov’erano; cambiano solo la dimensione dell’etichetta e il suo margine superiore.
La modifica è rimasta piccola. L’etichetta eredita il font Inter Variable, e misurata in quel font FORMER era larga 153,5 pixel a 36 pixel di corpo, contro un riquadro utile di 130, e 119,4 pixel a 28. La correzione ha ridotto il corpo e aggiustato il margine superiore, ha lasciato esattamente dov’erano la geometria del pannello e l’origine del connettore, ed è stata controllata su ritagli a risoluzione nativa prima che autorizzassi un ultimo render. Il render ha richiesto tre tentativi, i primi due fermati dal limite di utilizzo dell’account e da un errore di configurazione, e si è concluso nello stesso giorno. Dopo, lo stesso confronto su 18 fotogrammi con il master precedente ha mostrato differenze solo dentro la scena 12, e la traccia audio era identica byte per byte a quella approvata.
Claude ha trovato anche discrepanze meno visibili. La cronologia dei render non era stata aggiornata per le consegne finali, i registri delle approvazioni di DMP e CEP si fermavano al gate della voce benché entrambi i job avessero superato quelli successivi, e due master copiati riportavano una modalità che faceva pensare a un render mai avvenuto. Codex ha ricostruito i registri indicando la provenienza di ogni dato, e ha segnato come sconosciuti i tempi che non poteva recuperare, senza riempirli con stime di comodo.
Video e registro potevano essere sbagliati ciascuno per conto suo, e una seconda ispezione li ha controllati entrambi prima che qualcosa arrivasse su YouTube.
Le decisioni che restavano a me
Codex costruiva, Claude verificava e io approvavo alla fine, ma solo sulla carta: diverse mie decisioni hanno cambiato ciò che stavamo costruendo.
Ho scartato la prima direzione visiva completa e la versione successiva, più fitta di sincronizzazioni. Entrambi i file si riproducevano, ma i diagrammi non spiegavano abbastanza. Ho approvato la prova sul warehouse che ha fissato un approccio visivo più significativo, e ho preteso che ogni etichetta restasse dentro il suo simbolo. Quelle scelte hanno definito il prodotto più di quanto avrebbe fatto qualsiasi approvazione finale.
La voce richiedeva un giudizio altrettanto misto. Io potevo riconoscere la voce clonata e decidere se l’interpretazione fosse accettabile, e un controllo di trascrizione poteva segnalare le frasi probabilmente perse. Nessuno dei due risultati rispondeva alla domanda dell’altro, quindi il processo li ha tenuti entrambi.
Più avanti ho dovuto decidere se un problema scoperto giustificasse un altro render. L’etichetta del DMP sì. Una differenza ereditata nelle maiuscole dei claim, con la CDP in minuscolo e i video successivi in maiuscolo, non giustificava la riapertura di una produzione chiusa: abbiamo congelato la CDP come unica eccezione documentata e registrato il maiuscolo come standard per tutti i video successivi.
Il carico pratico è rimasto mio. Dovevo leggere ogni revisione, capire cosa coprissero davvero i suoi controlli, guardare o ascoltare il file in questione e mantenere la spiegazione fedele al mio argomento. Due collaboratori hanno aumentato quello che riuscivamo a fare, e hanno anche prodotto più materiale che arrivava con l’aria di essere finito prima che io me ne fossi fatto un’idea.
In L’anno in cui l’editor è tornato ho scritto dell’intensità di revisionare lavoro prodotto a quella velocità, e la video factory l’ha reso molto concreto: una voce approvata, una direzione visiva approvata e un master tecnicamente valido erano tre decisioni distinte, anche quando riguardavano lo stesso file di sette minuti.
Come ogni correzione ha facilitato il passaggio di consegne successivo
L’abitudine più utile che abbiamo preso è stata far sì che ogni sessione lasciasse alla successiva un punto di partenza migliore. Un esperimento fallito sulla voce ha lasciato un profilo sostitutivo approvato e un controllo di completezza. Una transizione confusa ha lasciato helper condivisi e un lint. L’etichetta del DMP ha lasciato nel kit condiviso un controllo che misura il testo renderizzato rispetto al suo riquadro, con i font veri caricati, e ferma il render quando un’etichetta esce; fallisce sulla versione originale a 36 pixel e passa su quella corretta.
Figura 3. Tre correzioni e quello che ciascuna ha lasciato alla produzione successiva.
Abbiamo anche imparato a raccogliere il feedback in un colpo solo. Ad agosto il DMP ha richiesto tre video di revisione sostitutivi per correzioni di posizionamento, e ogni giro voleva dire ricostruire il contesto, applicare una correzione e ripetere i controlli. Una revisione completa del video, raccolta prima di toccare qualsiasi cosa, è un compito di implementazione molto migliore che scoprire un problema di spaziatura dopo l’altro in sessioni separate, e il brief di avvio ora chiede proprio questo, un solo passaggio per gate.
Riconosco lo stesso schema nei progetti con team di persone. Chi riceve un passaggio di consegne ha bisogno della decisione, delle prove su cui si basa e dei limiti di ciò che può cambiare, e una lunga storia aiuta solo se permette di distinguere le istruzioni valide da quelle superate.
Il progetto mi ha dato anche un’estensione concreta dei fallimenti silenziosi di cui ho scritto in Agenti in produzione. Un secondo revisore può intercettare un errore, e il miglioramento più grande arriva quando la revisione cambia il modo in cui verrà rilevato il prossimo, perché altrimenti tutto dipende da qualcuno che si ricordi di notarlo di nuovo.
La revisione dell’8 settembre ha avuto valore perché si è chiusa con correzioni che potevamo specificare e verificare, comprese quelle al nostro stesso racconto di ciò che era successo. Il passaggio di consegne ha funzionato quando il collaboratore successivo poteva verificare il lavoro senza doversi fidare della sicurezza di quello precedente.
Il terzo articolo, From Article to YouTube: Making the Process Repeatable, racconterà come il pilota è diventato una routine di produzione e di pubblicazione, dai sottotitoli e i capitoli fino alle thumbnail e al caricamento. Nel frattempo, tutti gli episodi finiti sono sul mio canale YouTube.
Fonti
Contesto già pubblicato
- Andrea Veggiani, Dal blog al video: costruire la mia video factory. Il primo dei tre articoli, sul pilota della CDP, il workflow della voce e la direzione visiva.
- Andrea Veggiani, L’anno in cui l’editor è tornato. Il racconto precedente del passaggio dall’assistenza in chat al costruire con collaboratori AI.
- Andrea Veggiani, From Personal Site to Sales Tool: Building a Working Braze Demo with Claude Cowork, Part 2. La storia di costruzione citata qui, in inglese.
- Andrea Veggiani, Agenti in produzione: quello che le demo lasciano fuori. Le pratiche di contesto scritto e stato condiviso applicate a questo progetto.
- Andrea Veggiani, Agenti in produzione: come i sistemi agentici falliscono in silenzio. Il racconto dei fallimenti che superano i controlli superficiali.
Gli episodi di produzione di questo articolo sono ricostruiti dai miei file di progetto, dai report di revisione salvati e dalle decisioni registrate. La revisione indipendente dei master ha unito controlli tecnici sull’intero file a un’ispezione visiva campionata; non è stata una visione continua dei tre video. Le figure sono fotogrammi estratti dai render reali, senza renderizzare nulla di nuovo.
