HTML batte Markdown: cosa cambia quando l’output dell’AI smette di essere un testo
Il 20 maggio Thariq Shihipar, membro del team Claude Code di Anthropic, ha pubblicato un articolo dal titolo curioso, The unreasonable effectiveness of HTML, in cui spiega perché lui e altri colleghi hanno smesso di chiedere a Claude di produrre file in Markdown e hanno cominciato a chiedergli, invece, file in HTML. È un articolo che a una prima lettura sembra una scelta di formato, una preferenza personale tra due linguaggi di markup, e a una seconda lettura diventa qualcosa di molto più grande, perché tocca la domanda che mi gira in testa da quando ho iniziato a lavorare seriamente con questi modelli: quale forma deve avere ciò che l’AI ci restituisce, ora che ci restituisce sempre di più?
La tesi di Shihipar è semplice. Markdown è nato per essere leggibile umanamente in formato grezzo, scritto a mano da un developer, editato in un editor di testo, convertito poi in HTML per la lettura finale. Era un compromesso tra leggibilità della sorgente e formattazione del risultato. Ma quando la sorgente non la scrive più una persona, quando la scrive un modello che produce in pochi secondi migliaia di righe, il compromesso non ha più ragione di esistere, perché la sorgente nessuno la legge davvero. Si legge il risultato. E allora tanto vale generare direttamente l’output finale, già navigabile e già pronto a essere condiviso.
Cosa Markdown lascia fuori
Shihipar elenca i limiti pratici di Markdown in modo molto concreto, quasi domestico. I file più lunghi di cento righe non li legge più nessuno, neanche lui che li ha chiesti. Le immagini, i grafici, le tabelle complesse, le animazioni, i widget interattivi non ci stanno dentro. I diff, i flowchart, i mockup, le annotazioni a margine non ci stanno dentro. Per ovviare, Claude finisce per fare cose buffe come disegnare diagrammi in ASCII art o approssimare i colori con caratteri unicode. Stupendo come tentativo, evidentemente insufficiente come soluzione.
HTML, scrive Shihipar, può rappresentare praticamente qualsiasi tipo di informazione che il modello sappia produrre: dati tabellari, design via CSS, illustrazioni via SVG, interazioni via JavaScript, layout responsive che si adattano al mobile, posizionamento spaziale assoluto. Si scrive una volta, si apre nel browser, si condivide con un link. Una persona del team che riceve un report in HTML lo legge davvero, un report in Markdown da 200 righe finisce in un thread Slack ignorato.
C’è poi il punto che a me interessa di più, quello che Shihipar chiama two-way interactions. L’HTML non è solo un contenitore, può ospitare slider, knob, form, bottoni che restituiscono parametri da copiare e incollare di nuovo in Claude Code. L’output del modello smette di essere un blocco di testo da leggere e diventa uno strumento monouso da usare, da manipolare, da modificare. Una cosa che si fa, non una cosa che si guarda.
Software che si butta via
C’è una sezione dell’articolo che ho riletto tre volte, quella sui custom editing interfaces. Shihipar racconta di chiedere a Claude di costruirgli un editor HTML ad hoc per riordinare trenta ticket di Linear in colonne Now/Next/Later/Cut, con tanto di drag-and-drop e bottone copy as Markdown finale. Non un’app vera. Non un tool riusabile. Un singolo file HTML, fatto per quel preciso problema, da buttare via dopo. Un altro esempio: tunare un system prompt vedendo in tempo reale come tre input campione riempiono il template. Un altro ancora: un form-based editor per i feature flag con warning sulle dipendenze.
Qui sta avvenendo qualcosa che fino a due anni fa avrebbe richiesto un team di prodotto, un designer, almeno una settimana di sviluppo. Adesso lo chiedi, esce in trenta secondi, lo usi una volta, lo chiudi. È software usa-e-getta. Una categoria nuova, che non va confusa con una versione povera del software vero, perché si forma e si dissolve attorno al singolo problema, senza overhead di mantenimento e senza utenti oltre chi l’ha richiesto.
In Pelle Digitale ragionavo sul fatto che lo strato di mediazione tra noi e le macchine si stesse facendo più sottile, più aderente, più reattivo, fino a perdere i propri confini visibili. Lì pensavo a interfacce conversazionali, ad agenti, a wearable. Non avevo previsto questo, ovvero che lo strato di mediazione potesse diventare effimero, che ogni interazione potesse generarsi la propria interfaccia su misura e poi dissolverla. La pelle, in questa accezione, è anche questo: una superficie che si forma quando serve, esattamente come la chiediamo, e che non ha più bisogno di esistere quando non serve più.
Un milione di token cambia le abitudini
C’è un dato tecnico che Shihipar tratta come un dettaglio e che secondo me è il cuore della questione. Markdown spesso usa meno token di HTML, dice, ma con la finestra di contesto da un milione di token di Opus 4.7 la differenza è ormai trascurabile. Quindi tanto vale chiedere al modello di produrre l’output più espressivo possibile, perché tanto la spesa marginale è prossima allo zero.
Questo va letto bene, perché segna una soglia. Per anni la conversazione sull’AI generativa è stata tirata da due forze opposte: da una parte la spinta verso output più ricchi e contestualizzati, dall’altra il vincolo dei costi di inferenza e della lunghezza del contesto. Adesso la seconda forza si sta indebolendo, e quando un vincolo cade, le abitudini che si erano formate attorno a quel vincolo iniziano a sembrare assurde. Markdown era una di queste abitudini. Era buona quando i contesti erano corti e i token costavano. Lo è meno adesso che possiamo permetterci di chiedere al modello di costruire una pagina HTML completa con SVG vettoriali, animazioni CSS e logica JavaScript embedded, e di farlo in tempi e con costi accettabili.
La conseguenza, secondo me, è che il modo in cui consumiamo l’output dei modelli sta divergendo dal modo in cui scriviamo l’input. L’input resta testo, anzi resta sempre più conversazionale e disordinato. L’output, invece, si fa multiforme: pagine interattive che fungono da dashboard, diagrammi navigabili, oggetti da manipolare con le mani. Si rompe la simmetria. E quando si rompe la simmetria tra ingresso e uscita di un sistema, di solito è il segnale che la categoria che li conteneva entrambi, in questo caso “la chat con il modello”, sta diventando troppo stretta.
“Ho smesso quasi del tutto di usare Markdown”
Mi ha colpito una frase che Shihipar lascia cadere quasi senza enfasi: “ho smesso quasi del tutto di usare Markdown”. Una persona che lavora dentro Anthropic, dentro il team che costruisce Claude Code, dice che il formato di scambio più diffuso degli ultimi quindici anni tra umani e macchine non gli serve più. Va presa come quello che è, una testimonianza dal centro della trasformazione, non come una previsione di mercato. Però è interessante.
L’argomento più forte che porta riguarda il piano cognitivo, prima ancora del piano tecnico. Dice che con HTML si sente più “in the loop” rispetto al lavoro del modello. Quando Claude diventa sempre più capace e gli affidi compiti sempre più grandi, il rischio di perdere il controllo, di firmare in bianco quello che ha prodotto, diventa serio. Markdown lungo e denso favoriva la firma in bianco, perché era troppo faticoso da leggere. HTML, organizzato visivamente, con tab e ancore, con diagrammi al posto delle descrizioni testuali, riporta dentro il loop la persona che ha delegato il lavoro.
Questo è un punto che merita di essere ascoltato anche fuori dal contesto Claude Code. Tutta la conversazione sull’AI agentica, sui modelli che agiscono autonomamente, sui workflow automatizzati, gira attorno alla stessa tensione: quanto vuoi delegare, quanto vuoi vedere, dove vuoi essere consultato. Il formato di output non è un dettaglio cosmetico in questa tensione, ne è uno degli assi principali. Se l’output è leggibile e navigabile in venti secondi, resti dentro. Se è impenetrabile, scivoli fuori, e prima o poi smetterai di controllarlo.
Dove stiamo andando
Provo a tirare due fili. Il primo: gli output dei modelli non sono più documenti, sono interfacce. Smettono di essere artefatti statici da leggere e diventano superfici da usare, monouso, generate al momento, costruite attorno al singolo task. Il secondo: la finestra di contesto larga libera il modello dalla costrizione di essere economico nel formato, e questo cambia il tipo di artefatto che ha senso produrre. Messi insieme i due fili, il quadro è che la produzione di software piccolo ed effimero, cucito attorno al singolo task, diventa una commodity, e questo ridisegna sia come usiamo Claude sia come pensiamo al lavoro intellettuale che gli affidiamo.
In Spatial Shift parlavo di come la frontiera dell’interazione si stia spostando dal piano del testo verso lo spazio, il gesto, l’ambiente. Quella che Shihipar descrive è una variante interessante di questo spostamento, perché non avviene nel mondo fisico, avviene dentro al browser, ma con le stesse caratteristiche: lo strumento si materializza attorno al compito, dura il tempo del compito, scompare. Non c’è installazione, non c’è apprendimento, non c’è curva di adozione. C’è solo la cosa da fare, e attorno a quella la cosa giusta per farla.
Senza dubbio è un cambio di abitudine piccolo, quasi invisibile, scegliere HTML invece di Markdown quando chiedi a un agente di produrre un report. Quanti di noi, fra sei mesi, staremo ancora chiedendo file di testo a Claude quando potremmo chiedergli pagine interattive che facciano una cosa sola, esattamente quella che ci serve, e poi le butteremo via?
Articolo di riferimento: Thariq Shihipar, Using Claude Code: The unreasonable effectiveness of HTML, claude.com/blog, 20 maggio 2026.
