Il 2 ottobre 2026 Andrej Karpathy ha pubblicato un appunto operativo: una parte crescente del lavoro con i modelli linguistici non è generare testo, ma capire il testo già generato. La scala che propone sale di astrazione. Prima una prosa vincolata, poi un diagramma, poi una pagina HTML, infine un video explainer costruito su quel singolo tema.
Il post, alle 00:37 UTC, ha raccolto circa 54.500 like, 6.400 repost, 80.664 bookmark e 7,6 milioni di view. Non annuncia un modello. Descrive un cambio di ruolo: più i modelli fanno da soli il lavoro basso, più il controllo umano si sposta su oversight e comprensione.
La scala, dal testo al video
Karpathy ordina i formati con un «ma ancora meglio» ripetuto. Non sono alternative equivalenti. Sono livelli diversi di carico cognitivo.
- Scrittura in ASD-STE100, oppure all’80% della specifica, se il vincolo pieno rende il testo troppo rigido.
- Diagrammi e immagini al posto di un altro paragrafo.
- Una pagina HTML interattiva, chiesta in output diretto.
- Un video explainer su misura, lo stile che indica è quello di 3Blue1Brown, con narrazione via API ElevenLabs o un sostituto locale. La chiusura del post è la parte che conta per chi costruisce sistemi. Intelligenza e codice diventano abbondanti, quindi ha senso chiedere artefatti software grandi, custom e usa-e-getta: una web app o un video che ieri non si giustificava. Servono a capire un output, poi si buttano.
Perché tira in mezzo un manuale aeronautico
ASD-STE100 è Simplified Technical English, lingua controllata di ASD, l’associazione europea dell’aerospazio, della sicurezza e della difesa. Nasce alla fine degli anni Settanta come AECMA Simplified English, per chi legge manuali di manutenzione con un inglese solo di base. La guida esce nel 1986. Dal 15 gennaio 2025 è Issue 9, e STEMG la presenta come standard internazionale.
La struttura è in due parti: regole di scrittura e dizionario controllato. Sul sito STEMG la specifica conta 53 regole in 9 sezioni e un dizionario di circa 900 parole approvate, ciascuna con un solo significato e una sola parte del discorso, più circa 1.200 parole sconsigliate con l’alternativa. I termini di progetto restano ammessi come nomi e verbi tecnici, dentro regole precise.
Le regole pubbliche più citate sono operative, non stilistiche. Nelle procedure, frasi entro le 20 parole. Nei testi descrittivi, entro le 25. Un’istruzione per frase. Voce attiva e imperativo. Niente contrazioni. Niente punto e virgola. Grappoli di nomi entro tre parole. Una parola, un significato: «fall» è cadere per gravità, non «diminuire».
Karpathy dice di aver avuto risultati migliori chiedendo l’80% della strada verso ASD-STE100. La specifica è stringente, e un modello che la imita al 100% può suonare da checklist anche quando il lettore voleva una spiegazione. L’80% tiene i vincoli che puliscono — frasi corte, un’idea, voce attiva — e lascia un margine di tono.
C’è un limite da non saltare. La copia ufficiale si richiede a STEMG. Un LLM non ha il dizionario proprietario in contesto, a meno che non glielo si dia. Può imitare le regole note. Non certifica conformità Issue 9.
Diagrammi e HTML, quando la prosa non basta
Il secondo gradino è chiedere un diagramma invece di un altro blocco di testo. Karpathy lo motiva in modo semplice: un disegno si scorre, si parsifica e si capisce con meno sforzo di un paragrafo denso. In risposta, Grady Booch ha ricordato che il problema non è nuovo e ha un nome, UML. Il punto di Karpathy non è sostituire una notazione. È smettere di usare la prosa come unico canale quando la relazione tra i pezzi è il vero contenuto.
Il terzo gradino è l’output «in HTML». Non un Markdown da incollare in un renderer. Un file che il modello compone come interfaccia: sezioni, confronti, animazioni leggere. Ha senso quando l’output da controllare ha stati, alternative o numeri che cambiano. Una pagina usa-e-getta batte un thread di chat nel momento in cui due persone devono guardare la stessa cosa.
Anche qui il rischio è noto. Un frontend pulito non rende vero un claim. Rende solo più facile vedere dove il claim sta.
Il video explainer, e cosa non promette
Il formato su cui Karpathy è più esplicito è il video bespoke, su un tema qualsiasi. L’esempio che dà è diretto: un explainer stile 3Blue1Brown, con la chiave API ElevenLabs per la narrazione, oppure un TTS locale se la chiave non c’è. La frase che chiude quel paragrafo è misurata: sta iniziando a funzionare. Non è un prodotto, non è un benchmark.
Nelle risposte, un utente ha mostrato un video sullo stochastic calculus costruito seguendo il suggerimento. È un aneddoto, non una misura di qualità. Dice solo che il percorso prompt → storyboard → narrazione è già percorribile da chi non fa video di mestiere. Il video è il gradino più costoso e il più facile da sopravvalutare. Una formula animata bene può nascondere un passaggio saltato. Per questo resta un artefatto di comprensione, non una fonte. Se il tema è tecnico, lo storyboard va letto prima del rendering: scene, cosa appare a schermo, cosa la voce non deve inventare.
Cosa cambia nel lavoro di review
La tesi utile non è «chiedi sempre un video». È che il formato va scelto sul tipo di opacità.
- Procedura o policy: STE all’80%, poi un controllo umano sulle frasi che il modello ha accorciato troppo.
- Dipendenze e rami: diagramma, con i salti logici segnati.
- Review a due: una pagina HTML con claim, evidenza e buchi.
- Un concetto che ancora non torna: storyboard, poi video, solo su quel pezzo.
Il resto del messaggio è una previsione di allocazione del tempo. I modelli faranno più lavoro basso in autonomia. La quota umana sale verso il controllo. Gli stessi modelli possono costruire gli strumenti di quel controllo, a patto di trattarli come scartabili. Una pagina che spiega una pull request non deve diventare un prodotto. Deve rendere visibile se la pull request è capibile.
Fonti
Testo: assistito da AI · revisionato da Carlos H. P. Ross
