Passa al contenuto principale

Video esplicativi con l'AI: la pipeline guidata dal codice

Intermedio

Un post intitolato "Opus 5.5 is good at explainer videos" è rimasto in cima a Hacker News con 319 punti e 175 commenti — e leggendo il thread, la cosa più interessante è quante persone abbiano frainteso il meccanismo. Davano per scontato un modello video. Non lo è.

Quello che succede è più strano e molto più utile: un modello di coding scrive un programma di animazione deterministico, e un renderer separato trasforma quel programma in frame. Il modello non vede mai un pixel dell'output. Il che significa che il tutto si comporta come software — diffabile, ri-renderizzabile, parametrizzabile e debuggabile — invece che come una slot machine da ri-promptare finché non viene bene.

Questa pagina è la guida pratica che mancava a quel thread: come funziona la pipeline, quale dei tre motori di render scegliere (e su quale i modelli sono misurabilmente scarsi), le due modalità di fallimento che rompono in silenzio il codice di animazione scritto dagli agent, l'aritmetica del ritmo che separa un esplicativo guardabile da uno illeggibile, e dove finiscono davvero i soldi.

What you'll learn
  • Spiegare perché un modello di coding batte un modello video sugli esplicativi — e a cosa rinuncia
  • Indicare il motivo per cui Math.random() è vietato in un'animazione renderizzata frame per frame, e cosa lo sostituisce
  • Scegliere tra Remotion, Motion Canvas e Manim in base alla licenza e a quanto bene i modelli li scrivono
  • Riconoscere le due trappole nel codice di animazione scritto dagli agent: lo split dei fork di Manim e l'API Remotion obsoleta
  • Calcolare un tempo minimo di permanenza per slide invece di tirare a indovinare, così chi guarda riesce davvero a leggere
  • Prevedere quale voce domina il conto (di solito non è l'LLM)

Il meccanismo: il modello scrive un programma, non un video​

Due cose completamente diverse vengono chiamate "video AI".

I modelli video a diffusione (la famiglia trattata in media generativi) prendono un prompt ed emettono pixel direttamente. Eccellenti per il b-roll, una ripresa da drone, una texture, un'atmosfera. Pessimi su qualsiasi cosa debba essere esattamente giusta: testo leggibile, un diagramma di architettura corretto, la UI reale del tuo prodotto, un numero che deve dire 40%.

L'animazione guidata dal codice fa il contrario. Un modello di coding scrive il sorgente di un'animazione — componenti React, uno scene graph TypeScript, o Python — e un renderer lo esegue. Il testo è testo, quindi è nitido e scritto correttamente. Un diagramma è un layout, quindi è accurato. Il tuo logo è il tuo file di logo.

Questa distinzione spiega il workflow più ricorrente riportato nel thread di HN: il modello "crea una pagina HTML e usa animazioni JS temporizzate a mano", poi i frame vengono catturati e assemblati con ffmpeg. Spiega anche a cosa rinuncia l'approccio — non può inventare immagini fotografiche, quindi quasi tutte le pipeline reali chiamano un modello di immagini o un modello video per il b-roll e lo compositano.

La conseguenza da interiorizzare: il tuo esplicativo diventa un repository. Cambi il prezzo sulla slide 4, ri-renderizzi, fatto. Localizzi il voiceover, ri-renderizzi dodici lingue dalle stesse scene. Non è una proprietà che ti dia nessun modello prompt-to-video.

Perché il determinismo è tutto il trucco​

Ecco il dettaglio che in silenzio decide se la tua pipeline produce video pulito o un pasticcio che sfarfalla, e che quasi nessuno menziona scrivendone.

Un renderer come Remotion non registra lo schermo della tua animazione. Apre la composizione in Chrome headless, imposta l'orologio al frame 0, fa uno screenshot, imposta l'orologio al frame 1, screenshot, e così via — e lo fa su più thread, aprendo la pagina più volte. I frame vengono prodotti fuori ordine, in parallelo, in contesti browser separati.

Da lì discende tutto:

  • L'animazione deve essere una funzione pura del numero di frame. In Remotion è letteralmente l'API: useCurrentFrame() ti dà il frame, interpolate() lo mappa su un valore. Niente timer, niente requestAnimationFrame, nessuna transizione CSS guidata dal tempo di orologio. Una transizione CSS renderizza qualunque valore si trovasse a metà strada quando è scattato lo screenshot.
  • Math.random() è rotto per costruzione. Restituisce un valore diverso in ogni thread e a ogni caricamento della pagina, quindi una particella "random" sobbalza in una nuova posizione a ogni frame. Remotion include random(seed) — un PRNG mulberry32 con seed — esattamente per questo: random(1) restituisce sempre 0.07301638228818774. Lo stesso vale per spring(), che è un calcolo puro in cache indicizzato su (frame, fps, config).
  • I frame persi smettono di essere possibili. Una registrazione dello schermo di un'animazione pesante perde frame quando la CPU non regge. Il rendering frame per frame semplicemente ci mette di più. È per questo che un render di 5 minuti su un laptop può produrre un video che scorre perfettamente fluido.
Watch out
  • Se di tutte le regole per promptare un agent a scrivere codice di animazione ne ricordi una sola: vieta il tempo di orologio. Niente setTimeout, niente transizioni CSS, niente Date.now(), niente Math.random(). Ogni valore visivo deve derivare dal numero di frame corrente. I modelli tenderanno a usare le transizioni CSS, perché è di quello che è pieno il corpus web.

I tre motori​

Tutti e tre sono progetti veri, mantenuti attivamente, e producono output di qualità broadcast. Differiscono per linguaggio, per licenza e — cosa importante — per quanto affidabilmente un modello li scrive.

RemotionMotion CanvasManim
LinguaggioReact / TypeScriptTypeScript (generator)Python
Reporemotion-dev/remotionmotion-canvas/motion-canvas (~19,2k stelle)ManimCommunity/manim (~41k) · 3b1b/manim (~94k)
LicenzaSource-available + Company LicenceMITMIT
Punto di forzaVideo di prodotto/lancio, UI, esplicativi ricchi di testoMotion graphics precise sulla timelineVisualizzazione matematica e algoritmica
Qualità del codice scritto dai modelliForte — e include agent skill ufficialiDiscretaLa più debole dei tre (vedi sotto)

Due voci di quella tabella meritano più di una riga.

Il trabocchetto di Remotion è la licenza, non il codice​

Remotion non è MIT. È source-available con una licenza commerciale a due livelli, e la soglia è abbastanza bassa da colpire quasi tutti i team: gratis per individui, no-profit, valutazione e aziende for-profit fino a 3 dipendenti; una Company Licence a pagamento per le organizzazioni for-profit con più di tre.

La seconda distinzione conta di più se stai costruendo un prodotto e non un video:

  • Remotion for Creators — a postazione, pensata per rendering a basso volume dentro e per la tua azienda, esplicitamente non per servire video personalizzati ai tuoi utenti finali.
  • Remotion for Automators — a render, ed è il livello in cui finisci nel momento in cui un agent renderizza video per i clienti. Dalla versione 5.0 comporta reporting di telemetria obbligatorio con una license key.

Quindi "il mio agent genera un video per ogni iscrizione" non è un caso d'uso Creators. Mettilo a budget come Automators prima di rilasciarlo. Se la cosa è un dealbreaker, Motion Canvas è MIT e copre buona parte dello stesso terreno.

La trappola di Manim: due fork, un solo nome di import​

Questa frega chi non ne ha mai sentito parlare, e spiega anche un'osservazione dal thread di HN — che i modelli di coding forti scrivono Manim peggio di quanto ti aspetteresti, con segnalazioni dalla community secondo cui al momento Gemini se la cava meglio di Opus 5.5.

Esistono due Manim:

  • 3b1b/manim — l'originale di Grant Sanderson, quello dei video famosi, ~94k stelle, installato come manimgl.
  • ManimCommunity/manim — il fork della community, ~41k stelle, quello effettivamente documentato e mantenuto per un uso generale, installato come manim.

Sono API-incompatibili ed entrambi si importano con from manim import *. Ogni tutorial, risposta su StackOverflow e blog post nel corpus di training riguarda l'uno o l'altro, senza etichetta. Così il modello scrive codice plausibile che mescola i due dialetti, e Python solleva un errore su un metodo che esiste nell'altro fork. Non è un fallimento di ragionamento; è un fallimento da namespace avvelenato.

La soluzione è noiosa e funziona: fissa il fork nel prompt e nell'ambiente, e passa all'agent la superficie API reale della versione invece di lasciare che se la ricordi.

Fissa il dialetto Manim prima che l'agent scriva una riga

Use ManimCommunity Manim (the "manim" package on PyPI), NOT 3b1b/manimgl.
Before writing any scene, run:
python -c "import manim; print(manim.__version__)"
and confirm the version. If a class or method you want is not in that
version's API, do not use it — check with:
python -c "import manim; print([n for n in dir(manim) if 'Text' in n])"
Never mix manimgl APIs (e.g. ShowCreation) with community APIs (Create).

La trappola dell'API obsoleta (edizione Remotion)​

Lo stesso problema di corpus avvelenato colpisce Remotion per un motivo diverso: la libreria si è mossa più in fretta dei dati di training.

Nel Remotion attuale, i componenti media vivono in @remotion/media, e le prop di trimming sono trimBefore / trimAfter. Preview e render possono persino usare componenti diversi di proposito — Html5Audio da remotion in preview, Audio da @remotion/media in fase di render, commutati su useRemotionEnvironment(). Un modello addestrato per lo più su materiale più vecchio scrive import {Audio} from 'remotion' con startFrom, che è la forma vecchia.

Quel codice potrebbe comunque girare. Potrebbe anche, in silenzio, non fare nulla di utile, il che è peggio.

È esattamente per questo che Remotion pubblica Agent Skill ufficiali — un set di dodici skill che passano all'agent le best practice attuali invece di sperare che se le ricordi. Sono pensate per Claude Code, Codex, Cursor e affini, e seguono lo stesso formato aperto trattato in SKILL.md come standard aperto.

Installa le agent skill ufficiali di Remotion

npx skills add remotion-dev/skills

Le skill sono granulari, ed è proprio il punto — invochi quella che corrisponde alla fase di lavoro: /remotion-create per lo scaffold, /remotion-markup per animazione e tipografia, /remotion-studio per la preview, /remotion-render per renderizzare, /remotion-captions per i sottotitoli, più remotion-best-practices come ombrello quando non sei sicuro. Le skill mantenute dal vendor sono la soluzione più economica disponibile alla conoscenza obsoleta che un modello ha di una libreria che si muove in fretta: una installazione, e l'agent smette di tirare a indovinare.

La pipeline che funziona davvero​

La leva di qualità più grande non è un prompt migliore per l'intero video. È dividere il lavoro in modo che il modello faccia il lavoro di giudizio e il renderer quello di determinismo — con in mezzo un artefatto leggibile da un umano.

Guided walkthrough1 of 7
  1. Chiedi prima una lista di scene in JSON: per ogni scena un titolo, il testo a schermo, l'intento visivo e una durata in secondi. È il passaggio economico e revisionabile. Leggi dodici scene in trenta secondi e sistemi la narrazione prima che esista un solo componente — e sistemare la storia è la modifica che migliora di più il video. Inoltre, il codice generato da uno storyboard già revisionato è molto più coerente di quello generato da un paragrafo di vibes.

Renderizza da CLI, poi trova la tua concorrenza reale

# deterministic render, reproducible in CI
npx remotion render src/index.ts MyExplainer out/video.mp4

# stop guessing --concurrency: measure it
npx remotion benchmark src/index.ts MyExplainer --concurrencies=2,4,8 --runs=3

Ritmo: il motivo per cui la maggior parte degli esplicativi AI è inguardabile​

La lamentela più costante nel thread di HN non era che i video fossero brutti. Era che andavano troppo veloci per leggerli. Le slide compaiono, il testo entra in animazione, e sparisce prima che un umano finisca la frase.

È un bug con una formula, non una questione di gusti. La velocità di lettura di un adulto su testo a schermo non familiare si aggira sulle 200–250 parole al minuto, e chi guarda ha anche bisogno di tempo per trovare il nuovo testo prima di iniziare a leggerlo. Quindi:

# minimum dwell time for a text block, in frames
words        = number of words in the block
wpm          = 200          # conservative for unfamiliar on-screen text
settle       = 0.4          # seconds to notice and locate the new text
exit         = 0.3          # seconds of breathing room before it leaves

dwell_seconds = settle + (words / wpm) * 60 + exit
dwell_frames  = ceil(dwell_seconds * fps)

# worked example: a 14-word bullet at 30 fps
# 0.4 + (14 / 200) * 60 + 0.3 = 4.9 s  ->  147 frames

Due note che rendono tutto questo davvero utile:

  • Entra veloce, tieni a lungo. La transizione d'ingresso dovrebbe durare 200–400 ms; è nella permanenza che va il budget di dwell. I modelli tendono a fare il contrario — una dissolvenza lunga ed elegante, poi una permanenza corta.
  • Se c'è la narrazione, il minimo di dwell è la durata della narrazione. Il testo deve restare a schermo almeno quanto la frase che lo descrive. Ed è per questo che ricavare la durata della scena dall'audio sintetizzato (passo 4 qui sopra) sistema il ritmo quasi gratis.

Limita ogni scena a max(dwell_frames, narration_frames) e una buona fetta della sensazione da "video AI slop" sparisce, senza cambiare nulla nella parte visiva.

Quanto costa, e quale voce domina​

Le segnalazioni della community dal thread di HN collocano un esplicativo generato completo attorno ai 3–4 $ di spesa in API, con il dettaglio notevole che il costo era dominato dalle chiamate ai modelli di immagini, non dal modello linguistico. Un commentatore ha riferito di aver generato un video di 5 minuti su un MacBook Air M4 in circa 5 minuti di tempo reale usando una pipeline orchestrata.

Tratta i numeri assoluti come deperibili, ma la forma è strutturale e vale la pena pianificarci sopra:

  • Qui l'LLM costa poco. Uno storyboard più qualche centinaio di righe di codice di animazione sono pochi token. Anche a prezzi da flagship sono centesimi. Vedi quanto costa l'AI tra i vari provider.
  • Dominano le chiamate generative per asset. Ogni immagine generata o clip di b-roll è una chiamata a pagamento a sé, e si moltiplicano per il numero di scene. È questa la voce da mettere a tetto.
  • Il compute è tuo. Il rendering gira sulla tua macchina o sulla tua CI, quindi è tempo ed elettricità più che spesa in API — finché non lo sposti su un renderer serverless, momento in cui diventa entrambe le cose.
  • I ri-render sono quasi gratis, ed è tutto il vantaggio strutturale. Correggere un refuso sulla slide 4 costa un render, non una rigenerazione. Localizzare in dodici lingue costa dodici run di TTS e dodici render, non dodici video.

La mossa pratica di budgeting: genera le immagini una volta, committale come asset e tieni i ri-render senza generazione di asset. Una pipeline che rigenera le immagini a ogni render è quella che produce un conto a sorpresa.

Il problema dell'omologazione​

La critica più tagliente del thread è quella da prendere sul serio: nel giro di poche settimane dalla diffusione di questi strumenti, gli output sono diventati riconoscibili. Stessi sfondi a gradiente, stesse card che entrano con lo spring, stessi bullet da tre parole, stessa voce spedita. Diversi commentatori hanno segnalato anche testi ripetitivi e, in un caso, un video sicurissimo di sé ma sull'argomento sbagliato — un sito di riferimento su Twilight Imperium descritto come una startup AI di data.

Se lo usi seriamente, ecco le leve che de-omologano l'output in modo misurabile:

  • Fornisci il design system, non lasciare che se lo inventi. Passa la tua palette reale, la scala tipografica, la scala di spaziatura e il logo come costanti che i componenti importano. I prompt sotto-specificati sono esattamente il punto in cui si infiltra lo stile di casa del modello.
  • Scrivi tu i testi, oppure editali pesantemente. La parte visiva è quella in cui i modelli sono bravi. La narrazione è la parte che si legge come generata.
  • Usa le tue registrazioni dello schermo come asset principale. Riprese reali del prodotto compositate in una scena generata sono la mossa anti-omologazione più forte in assoluto, e sistemano anche il rischio di allucinazione — il video non può descrivere male il tuo prodotto se il prodotto è a schermo.
  • Verifica le affermazioni come faresti con la documentazione. Qualsiasi cosa fattuale in un esplicativo è un'affermazione fattuale pubblicata a tuo nome, senza nulla della facile via di correzione di una pagina di testo. Controllala prima di renderizzare, non dopo che è su YouTube.
  • Rompi una convenzione di proposito. Una scelta deliberata che il template di default non farebbe — un rapporto d'aspetto insolito, silenzio dove ci si aspetta la musica, un asset disegnato a mano — di solito basta a impedire che l'output si legga come un default da macchina.
Video guidato dal codice: il vocabolario
Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.
1 / 8

In cosa è forte, e in cosa no​

Vale la pena essere onesti, perché gli scettici di quel thread avevano ragione su un punto: buona parte di ciò che viene prodotto è una presentazione animata con un voiceover sopra. È un artefatto perfettamente valido per un changelog, un lancio, una release note o un percorso di onboarding — ed è un pessimo sostituto dell'insegnamento vero, che richiede un esempio svolto, una strada sbagliata e un motivo per interessarsene.

Scegli la pipeline guidata dal codice quando:

  • Il contenuto deve essere esattamente giusto — UI reali, numeri reali, diagrammi reali.
  • Dovrai modificarlo in seguito, o pubblicarlo in più lingue.
  • Lo stesso template produrrà molti video da dati diversi.

Scegli altro quando l'obiettivo sono riprese fotografiche (usa un modello video), o quando il valore sta in un umano che spiega un'idea difficile prima male e poi bene — che resta la cosa che nessuna pipeline produce.

Check yourself

0/5
  1. Un modello scrive un'animazione esplicativa usando transizioni CSS e setTimeout. La preview è perfetta. Cosa succede in fase di render?
  2. Il codice Manim del tuo agent continua a fallire su metodi che 'dovrebbero esistere'. Causa più probabile?
  3. Una startup di 3 persone costruisce un prodotto che renderizza un video Remotion personalizzato per ogni nuova iscrizione. Posizione rispetto alla licenza?
  4. I revisori dicono che il tuo esplicativo generato è 'troppo veloce'. Fix strutturale più economico?
  5. Ti aspetti che sia l'LLM a dominare il costo di un esplicativo generato. Cosa mostrano davvero le segnalazioni?

Fonti e approfondimenti​

Prossimi passi​