All'improvviso, il tuo buon senso crollerà oggi. Onestamente, il 99% delle persone usa ancora Markdown con Claude Code. Quello che un insider del team Claude Code di Anthropic ha detto è: «Fermati». Ha detto: «È enormemente meglio produrre output in HTML invece che in Markdown».
Perché man mano che l'output di Claude Code diventa più avanzato, Markdown è difficile da leggere, non riesce a comunicare e non viene condiviso.
D'altra parte, con HTML:
- Puoi illustrare
- Puoi codificare a colori
- Puoi organizzare con schede
- Puoi persino creare slider e pulsanti
- Puoi condividere direttamente nel browser
In altre parole, per far emergere il vero valore di Claude Code, non solo «cosa produci» ma «in quale formato produci» diventa incredibilmente importante.
Lo affermo.
La soluzione ottimale nell'era di Claude Code non è solo Markdown, ma HTML-first.
In effetti, anche prima che questo articolo uscisse, ClaudeCodeStudio ha utilizzato questo metodo, assicurando che i materiali delle slide vengano fuori con questa qualità in un colpo solo 👇
A proposito, hai mai avuto un'esperienza del genere?
- Hai fatto scrivere un piano a Claude Code, ma hai perso interesse dopo che ha superato le 100 righe.
- Hai condiviso una specifica Markdown con il team, ma nessuno l'ha letta fino alla fine.
- Hai guardato un diagramma ASCII art e hai pensato: «...Cos'è questo?»
- Volevi organizzare le informazioni con colori o layout, ma non potevi esprimerlo in Markdown.
- Hai incollato un piano in Slack, ma è stato sepolto come allegato.
Tutto questo era un «problema di formato di output».
Un articolo intitolato «Using Claude Code: The Unreasonable Effectiveness of HTML» scritto da Thariq (@trq212), un membro del team di sviluppo di Claude Code, sta attualmente diventando virale su X con oltre 11 milioni di visualizzazioni 😳
Thariq è un membro del team Claude Code di Anthropic e un ingegnere di YC W20. In altre parole, è un articolo in cui qualcuno che usa Claude Code in prima linea ogni giorno ha dichiarato: «Ho smesso di usare Markdown».
Questa volta, spiegherò il contenuto in modo facile da capire, includendo esempi di prompt specifici 👇
Post originale qui: https://x.com/trq212/status/2052809885763747935
■ Qual è il problema con Markdown?
Markdown è stato usato per anni come mezzo di comunicazione tra agenti AI e umani. È semplice, può essere usato ovunque e può scrivere testo ricco in una certa misura. Claude Code, ovviamente, produce output in Markdown per impostazione predefinita.
Ma onestamente, non ti sembra familiare?
Man mano che Claude Code diventa in grado di gestire compiti più complessi, i piani e le specifiche che produce diventano più lunghi. Leggi davvero fino alla fine un file Markdown che supera le 100 righe?
Thariq scrive nell'articolo: «Trovo difficile leggere un file markdown di più di cento righe».
Inoltre, oggigiorno, modifichiamo noi stessi i file sempre meno spesso. Li usiamo come riferimenti per specifiche o come output per brainstorming. Anche quando modifichiamo, chiediamo a Claude di «sistemare questo». In altre parole, il più grande vantaggio di Markdown—che è «facile da modificare a mano per gli umani»—non è più significativo.
Questo verbalizza brillantemente un problema che molti utenti di Claude Code hanno sentito inconsciamente.
■ Perché l'opzione HTML è «irragionevolmente efficace»
Ciò che Thariq propone è cambiare il formato di output di Claude Code da Markdown a HTML.
Potresti pensare: «L'HTML non è per fare pagine web?» Ma il potere espressivo dell'HTML è incomparabile a Markdown.
Diamo un'occhiata a cosa può essere specificamente espresso con HTML:
- Dati strutturati usando tabelle
- Design e colorazione usando CSS
- Illustrazioni e diagrammi usando SVG
- Frammenti di codice usando tag script
- Interazione usando JavaScript e CSS
- Diagrammi di flusso combinando SVG e HTML
- Dati spaziali usando posizionamento assoluto o canvas
- Incorporamento di immagini usando tag immagine
Thariq afferma: «Oserei dire che non esiste quasi nessun insieme di informazioni che Claude possa leggere che tu non possa rappresentare abbastanza efficientemente con HTML».
Chiunque abbia provato a far disegnare a Claude un diagramma ASCII o a esprimere colori con caratteri Unicode capirà il peso di queste parole. Sarai liberato da quella inefficienza, come «guidare una Ferrari fino a un minimarket».
■ La densità informativa è enormemente diversa
Il più grande punto di forza dell'HTML è la «densità informativa».
Quando lo stesso contenuto è scritto in Markdown e HTML, l'HTML può trasmettere molte più informazioni in modo molto più leggibile. Puoi passare da una scheda all'altra, codificare a colori o incorporare diagrammi.
Anche se non hai voglia di leggere 100 righe di Markdown, la stessa quantità di informazioni organizzata con schede e colori in HTML ti entrerà direttamente in testa.
Non è solo una «questione di apparenza». Una specifica che non viene letta è uguale a una che non esiste. Produrre output in un formato che viene letto si collega direttamente alla qualità del lavoro stesso.
■ Facilità di condivisione
Quando provi a condividere un file Markdown con qualcuno, di solito va così:
- Allegare come file a Slack → Nessuno lo apre
- Allegare a un'email → Nessuno lo apre
- Metterlo su GitHub → I non ingegneri non possono accedervi
Con HTML, basta caricarlo su S3 e inviare un link. Chiunque abbia un browser può leggerlo. Puoi persino renderlo responsive in modo che possa essere letto su mobile.
Testo originale di Thariq: «La probabilità che qualcuno legga effettivamente la tua specifica, report o descrizione di PR è molto più alta se è in HTML».
Questo è un punto sottile ma criticamente importante nella pratica.
■ La rivoluzione dell'interazione bidirezionale
Qui è dove l'HTML brilla veramente.
L'HTML non è solo qualcosa da «leggere». Può essere operato.
Per esempio, mettere a punto un design. Se chiedi a Claude Code di «creare un file HTML con uno slider», produrrà un file in cui puoi regolare velocità di animazione, easing e colori in tempo reale. Una volta trovati i parametri che ti piacciono, premi un pulsante «copia» e li incolli di nuovo in Claude Code.
Questa interazione bidirezionale consente regolazioni con un livello di precisione che i soli prompt testuali non potrebbero mai raggiungere.
Sei liberato dallo stress di comunicare «un po' più a destra», «un po' più veloce» o «non questo colore» a parole. Basta muovere lo slider.
■ Casi d'uso specifici (con esempi di prompt)
Nell'articolo, Thariq introduce modelli di utilizzo dell'HTML con esempi di prompt specifici. Sono così pratici che li introdurrò così come sono.
𝟭. Design, Pianificazione ed Esplorazione
«Non riesco a decidere quale direzione prendere per la schermata di onboarding. Genera 6 approcci completamente diversi, variando layout, tono e densità, e disponili in una griglia in un unico file HTML in modo che io possa confrontarli. Scrivi i compromessi per ciascuno su etichette.»
«Crea un piano di implementazione dettagliato in un file HTML. Includi mockup, flussi di dati e frammenti di codice importanti da revisionare. Rendilo leggibile e facile da digerire.»
𝟮. Revisione del codice e Comprensione
Puoi creare revisioni del codice più facili da leggere della schermata diff di GitHub.
«Crea un artefatto HTML per revisionare questa PR. Non ho familiarità con la logica di streaming/backpressure, quindi concentrati su quella. Mostra il diff effettivo con annotazioni a margine inline, codificate a colori per importanza.»
Thariq scrive: «Ora allego una spiegazione del codice in formato HTML a ogni PR».
𝟯. Design e Prototipazione
Proprio come il fondamento di Claude Design è HTML, l'HTML è estremamente bravo nell'espressione del design. Anche se l'implementazione finale è React o Swift, un flusso di lavoro di schizzo prima in HTML e poi riscrittura è efficace.
«Voglio creare un prototipo per un nuovo pulsante di checkout. Dovrebbe animarsi e diventare viola quando cliccato. Crea un file HTML in cui posso provare ogni parametro di animazione con slider e opzioni. Includi un pulsante per copiare i parametri che hanno funzionato bene.»
𝟰. Report, Ricerca e Apprendimento
Claude Code è bravo a sintetizzare informazioni da più fonti di dati e a riassumerle in un report leggibile. Puoi fargli cercare Slack, il codebase, la cronologia git e internet per creare report per la leadership o report di incidenti.
«Non capisco come funzioni il rate limiter. Leggi il codice pertinente e crea una pagina HTML di spiegazione. Includi un diagramma di flusso del token bucket, 3-4 frammenti di codice importanti con annotazioni, e infine una sezione "insidie". Ottimizzala in modo che io possa capirla in una lettura.»
𝟱. Interfacce di modifica personalizzate
Questo è stato il caso d'uso più scioccante per me personalmente. Realizzare operazioni difficili da comunicare in una casella di testo con un editor HTML usa e getta.
«Voglio riorganizzare la priorità di 30 ticket Linear. Crea un file HTML in cui ogni ticket è una carta trascinabile e disponili in quattro colonne: Now / Next / Later / Cut. Disponili inizialmente in base alla tua ipotesi. Includi un pulsante "Copy as Markdown" per esportare l'ordine finale con una riga di motivazione per ogni gruppo.»
«Sto modificando questo system prompt. Crea un editor affiancato. A sinistra, un prompt modificabile (evidenziando gli slot delle variabili), e a destra, tre input di esempio in modo che il template si rifletta in tempo reale. Includi un contatore di caratteri/token e un pulsante di copia.»
Non è fantastica questa idea? Generare l'UI necessaria sul momento, solo per quel compito. Non deve essere riutilizzata. Non deve essere perfetta. Ma è 100 volte più efficiente che farlo solo con testo.
■ Risposte alle domande comuni
Nell'articolo, Thariq risponde anche a domande comuni sull'HTML.
«Non è inefficiente in termini di token?»
→ È vero che usa più token di Markdown. Ma considerando il potere espressivo e la «probabilità di essere effettivamente letto», è efficiente in totale. Con il contesto da 1 milione di token di Opus 4.7, l'aumento è a un livello che non ha importanza.
«Non ci vuole tempo per generarlo?»
→ Ci vuole 2-4 volte più tempo di Markdown. Ma Thariq stesso sente che il risultato vale quel tempo.
«E il controllo versione?»
→ Questo è onestamente uno svantaggio. I diff HTML hanno più rumore di Markdown e sono più difficili da revisionare. Attualmente, questo è uno dei più grandi punti deboli dell'HTML.
«Il design finisce per sembrare pacchiano?»
→ Migliora se usi il plugin di design frontend di Claude Code. Inoltre, se fai leggere a Claude Code il codebase della tua azienda per creare un «file HTML del sistema di design» e lo usi come riferimento in seguito, puoi unificarlo con lo stile della tua azienda.
■ Perché HTML «adesso»?
Il motivo per cui questo articolo risuona è il tempismo.
Ora che Claude Code può gestire compiti complessi, gli output sono lunghi e densi. Continuare a riceverli in Markdown, un formato che è solo «testo con un po' di stile», è ora un collo di bottiglia.
La conclusione di Thariq è questa: «Mi sento molto più coinvolto che mai quando uso HTML».
Invece di lasciare tutto a Claude Code, producendo output HTML, si attiva un ciclo di «comprensione umana, giudizio e feedback». Questa è l'essenza della collaborazione con l'AI.
■ Riepilogo dei punti pratici
- Nessuna abilità o impostazione difficile richiesta. Basta dire a Claude Code di «creare un file HTML».
- Non cercare di creare un file di skill dall'inizio. Prima, prova con prompt grezzi.
- Inizia con «cose che vuoi che le persone leggano», come piani, revisioni, report e prototipi.
- L'effetto raddoppia quando sei consapevole dell'«interattività», come slider e pulsanti di copia.
- Apri l'HTML generato in un browser o caricalo su S3 per condividerlo.
Markdown non è male. Ma ora che l'output di Claude Code è diventato così avanzato, è arrivato il momento di aggiornare anche il formato del ricevente.
La prossima volta che fai creare un piano a Claude Code, prova ad aggiungere una riga: «Fallo in HTML». Rimarrai sorpreso dalla differenza.
A coloro che hanno trovato questo articolo anche solo leggermente utile:
𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗦𝘁𝘂𝗱𝗶𝗼 @ 𝗝𝗮𝗽𝗮𝗻 (@ClaudeCode_love) è un account gestito da tre appassionati di Claude Code.
Pubbliciamo quotidianamente sull'utilizzo pratico della CLI e sull'automazione.
Attualmente stiamo co-sviluppando un agente AI con un'azienda quotata.
I nostri post abituali 👇
- Casi reali di sviluppo prodotto usando Claude Code e Claude
- Organizzare l'utilizzo di Claude Code / Vibe Coding / tendenze di sviluppo
- Ultime informazioni su Claude Code dall'estero
Dalla filosofia di sviluppo al design, implementazione e miglioramento, riassumiamo informazioni dall'estero e primarie fino al punto di mettere un prodotto funzionante nel mondo, non solo «finire la build».
Se sei interessato, seguici e dacci un'occhiata 👀 Penso che sarà vantaggioso!
