Article-manifeste de Thariq Shihipar (équipe Claude Code chez Anthropic) qui annonce un changement de format de sortie par défaut pour les agents : remplacer Markdown par HTML. Markdown, format dominant depuis l'arrivée des agents (simple, portable, éditable), est devenu un goulot d'étranglement à mesure que les artefacts générés deviennent plus longs et plus riches. Au-delà de ~100 lignes, plus personne ne lit un fichier Markdown. HTML résout six limites simultanément : densité d'information, clarté visuelle, partage, interactivité bidirectionnelle, ingestion contextuelle native à Claude Code, et plaisir. Cinq usages canoniques détaillés (specs/plans, PR review, design, rapports, throwaway editors). Anti-pattern explicite : "don't turn this into a /html skill". FAQ honnête sur les downsides (génération 2-4× plus lente, diffs HTML bruyants).
Trois facteurs convergents motivent ce basculement :
"Almost no set of information that Claude can read that you cannot fairly efficiently represent with HTML." Privé de cette expressivité, le modèle fait des diagrammes ASCII et estime même les couleurs avec des caractères Unicode.
Au-delà de 100 lignes en Markdown, plus personne ne lit. HTML organise structurellement avec tabs, illustrations, liens. Lecture différenciée selon le form factor.
Markdown se partage mal (pas de rendu navigateur). HTML s'ouvre partout. "The chance of someone actually reading your spec is much much higher if it's in HTML."
Sliders pour régler une animation, knobs pour ajuster un algorithme, boutons "copy as JSON / copy as prompt" pour re-injecter les choix dans Claude Code.
Différenciation vs ClaudeAI ou Claude Design : agrégation codebase + MCP (Slack, Linear) + git history + Chrome → contexte large pour générer un artefact riche.
"Making HTML documents with Claude is just more fun and makes me feel more involved and invested in the creation, and that by itself is enough."
Au lieu d'un plan Markdown linéaire, faire émerger un web de fichiers HTML : brainstorm de 6 directions en grille comparative, expansion d'une option, mockups, code snippets, puis plan d'implémentation final.
HTML rend les diffs lisibles : annotations marginales inline, color-coding par sévérité, flowcharts. "I find this often works better than the default GitHub diff view, and I attach a HTML code explainer to every PR I make now."
Claude Design est déjà basé sur HTML. Prototyper animations avec sliders, exporter les paramètres réglés vers React/Swift/etc.
Synthèse multi-sources (Slack, codebase, git history, web) en un document HTML lisible. Format long, explainer interactif, slideshow. L'auteur a fait générer son article sur prompt caching depuis l'historique git.
Éditeur jetable single-file, purpose-built pour une donnée précise. "Not a product, or a reusable tool, but a single HTML file." Finit toujours par un export "copy as JSON/markdown/prompt" re-injectable dans Claude Code.
Patterns : drag-and-drop de tickets Linear en colonnes Now/Next/Later/Cut · éditeur de feature flags avec warnings de dépendances · prompt-tuner side-by-side avec compteur tokens · curation de datasets · pickers de couleurs/easing curves/cron schedules.
Mouvement notable venant d'un insider de l'écosystème qui pousse les Claude Skills. Shihipar refuse de canoniser sa pratique en skill : la pratique est trop contextuelle pour être figée. Le bon réflexe est de "prompter from scratch" jusqu'à trouver ses propres patterns.
Tension avec : Lattice (atoms/molecules/refiners), Vincent Superpowers, Karpathy skills-maxi. Position intermédiaire possible : skills pour les patterns stables (gem writing, design system), prompt nu pour les pratiques émergentes.
HTML utilise plus de tokens. Mais avec le 1MM context d'Opus 4.7, l'augmentation devient peu sensible dans la fenêtre de contexte. "The added expressiveness of HTML and the much higher likelihood of me reading it means I get overall better output."
2-4× plus longtemps que Markdown. Assumé : "the results are worth it."
Downside non résolu. "This is honestly one of the biggest downsides of HTML, HTML diffs are noisy and hard to review compared to Markdown."
Ouvrir localement dans un navigateur (on peut demander à Claude de l'ouvrir) ou uploader à S3 pour un lien partageable.
Utiliser le frontend design plugin. Pour matcher le style de votre boîte : créer un design system HTML unique en pointant Claude vers la codebase, puis le référencer comme blueprint pour les autres fichiers HTML générés.
"I have honestly stopped using markdown altogether for almost everything, but I'm probably far on the HTML maximalist side of things." Position assumée comme extrême par l'auteur lui-même.
Thariq Shihipar (équipe Claude Code chez Anthropic) publie un article-manifeste annonçant un changement de format de sortie par défaut pour les agents : remplacer Markdown par HTML. Le diagnostic : Markdown a régné comme format dominant entre humain et agent (simple, portable, éditable) mais est devenu restrictif à mesure que les agents produisent des artefacts plus longs et plus riches. Au-delà de ~100 lignes, plus personne ne lit un fichier Markdown — et comme l'auteur n'édite plus manuellement ses specs (il prompte Claude pour les éditer), l'avantage historique de Markdown disparaît.
Six raisons justifient le basculement vers HTML : (1) densité d'information — tableaux, CSS, SVG, scripts, canvas, images ; "almost no set of information that Claude can read that you cannot represent with HTML" ; (2) clarté visuelle — tabs, illustrations, responsive mobile ; (3) partage — upload S3 → lien direct, taux de lecture multiplié ; (4) interactivité bidirectionnelle — sliders, knobs, boutons "copy as prompt" pour reboucler ; (5) ingestion contextuelle native à Claude Code (codebase + MCP + git + Chrome) ; (6) plaisir — "it's joyful".
L'auteur formalise cinq usages canoniques : (a) specs/plans/exploration en grille comparative ; (b) PR review avec diff annoté inline et code-coloring par sévérité ; (c) design & prototypes avec sliders d'animation ; (d) rapports/recherche (son explainer sur prompt caching généré depuis l'historique git) ; (e) éditeurs jetables custom — single-file HTML purpose-built pour une donnée (drag-and-drop de tickets Linear, éditeur de feature flags, prompt-tuner side-by-side) finissant toujours par un export "copy as JSON/markdown/prompt" re-injectable.
Anti-pattern explicite : l'auteur refuse la skill-ification de sa pratique. "I'm a little bit afraid that people will read this article and turn it into a /html skill. You don't need to do much — just ask it to 'make a HTML file'." La pratique est trop contextuelle pour être figée.
FAQ honnête : HTML coûte plus de tokens mais le 1MM context d'Opus 4.7 absorbe ; génération 2-4× plus lente ; diffs HTML bruyants = downside non résolu, assumé.
Méta-thèse finale : HTML comme antidote au cognitive surrender. "I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I feel more in the loop than ever before when using HTML."
design.md (2026-05-06). Meng dit explicitement "HTML = finished dish, MD file = recipe, skills = ingredients". Shihipar valide la primauté HTML pour le plat fini livré à l'humain.| Sujet | Type | Prédicat | Objet | Type | Conf. | Temp. | Source |
|---|---|---|---|---|---|---|---|
| Thariq Shihipar | PERSONNE | travaille_chez | Anthropic | ORGANISATION | 0.97 | DYNAMIQUE | déclaré_article |
| Thariq Shihipar | PERSONNE | fait_partie_de | équipe Claude Code | ORGANISATION | 0.97 | DYNAMIQUE | déclaré_article |
| Thariq Shihipar | PERSONNE | recommande | HTML comme format de sortie par défaut | METHODOLOGIE | 0.98 | ATEMPOREL | déclaré_article |
| HTML | TECHNOLOGIE | remplace | Markdown pour artefacts agentiques longs | METHODOLOGIE | 0.95 | DYNAMIQUE | déclaré_article |
| Markdown | TECHNOLOGIE | est_devenu | restrictif au-delà de 100 lignes | CONCEPT | 0.92 | DYNAMIQUE | déclaré_article |
| HTML | TECHNOLOGIE | offre | densité d'information (tables, CSS, SVG, scripts, canvas) | CONCEPT | 0.97 | ATEMPOREL | déclaré_article |
| HTML | TECHNOLOGIE | permet | interactivité bidirectionnelle (sliders, copy as prompt) | CONCEPT | 0.96 | ATEMPOREL | déclaré_article |
| HTML | TECHNOLOGIE | améliore | taux de lecture des specs et rapports | CONCEPT | 0.93 | ATEMPOREL | déclaré_article |
| HTML | TECHNOLOGIE | est_antidote_à | cognitive surrender / comprehension debt | CONCEPT | 0.90 | ATEMPOREL | inféré |
| Claude Code | TECHNOLOGIE | ingère | codebase + MCP + git history + Chrome | CONCEPT | 0.95 | DYNAMIQUE | déclaré_article |
| Opus 4.7 | TECHNOLOGIE | dispose_de | 1MM context window | CONCEPT | 0.97 | STATIQUE | déclaré_article |
| 1MM context Opus 4.7 | CONCEPT | absorbe | coût tokens supplémentaire du HTML | CONCEPT | 0.93 | ATEMPOREL | déclaré_article |
| Throwaway HTML editor | METHODOLOGIE | termine_par | export copy as JSON / markdown / prompt | CONCEPT | 0.96 | ATEMPOREL | déclaré_article |
| Thariq Shihipar | PERSONNE | s_oppose_à | skill-ification prématurée du pattern HTML | CONCEPT | 0.95 | ATEMPOREL | déclaré_article |
| HTML diffs | TECHNOLOGIE | sont | bruyants et difficiles à reviewer (downside assumé) | CONCEPT | 0.92 | ATEMPOREL | déclaré_article |
| Génération HTML | METHODOLOGIE | est | 2-4× plus lente que Markdown | CONCEPT | 0.88 | ATEMPOREL | déclaré_article |
| Frontend design plugin | TECHNOLOGIE | aide | Claude à produire du HTML stylé | CONCEPT | 0.85 | ATEMPOREL | déclaré_article |
| Design system HTML unique | METHODOLOGIE | sert_de | référence pour cohérence cross-fichiers | CONCEPT | 0.88 | ATEMPOREL | déclaré_article |
| Article HTML effectiveness | EVENEMENT | s_articule_avec | design.md de Meng To (HTML = finished dish) | CONCEPT | 0.93 | ATEMPOREL | inféré |
| Article HTML effectiveness | EVENEMENT | répond_à | comprehension debt d'Osmani | CONCEPT | 0.90 | ATEMPOREL | inféré |
| Claude Code | TECHNOLOGIE | génère | artefacts HTML pour specs, PR, rapports, éditeurs jetables | METHODOLOGIE | 0.96 | ATEMPOREL | déclaré_article |
| Anthropic | ORGANISATION | emploie | Thariq Shihipar | PERSONNE | 0.97 | DYNAMIQUE | déclaré_article |
| Entité | Type | Attribut | Valeur | Action |
|---|---|---|---|---|
| Thariq Shihipar | PERSONNE | rôle | Engineer & serial entrepreneur, équipe Claude Code chez Anthropic, X @trq212 | AJOUT |
| HTML (format de sortie agent) | METHODOLOGIE | catégorie | Format préféré pour artefacts agentiques riches | AJOUT |
| Throwaway HTML editor | METHODOLOGIE | catégorie | Éditeur single-file purpose-built pour une donnée, finissant par export structuré | AJOUT |
| Anti-skill-ification | CONCEPT | catégorie | Refus de figer un pattern contextuel en skill prématurée | AJOUT |
| Cognitive surrender (réponse) | CONCEPT | catégorie | Pratique de rester dans la boucle décisionnelle via lisibilité HTML | AJOUT |
| html-effectiveness gallery | TECHNOLOGIE | catégorie | Site exemples de Shihipar (thariqs.github.io/html-effectiveness) | AJOUT |
| Diff HTML bruyant | CONCEPT | catégorie | Downside assumé du basculement Markdown → HTML | AJOUT |
| Design system HTML de référence | METHODOLOGIE | catégorie | Fichier HTML unique servant de blueprint stylistique inter-fichiers | AJOUT |
| Joyful artifact | CONCEPT | catégorie | Critère émotionnel-pragmatique de choix de format | AJOUT |
| Unreasonable effectiveness | CONCEPT | catégorie | Lignée rhétorique Wigner-Karpathy appliquée à HTML pour agents | AJOUT |
.md de config (CLAUDE.md, agents.md, etc.).shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10.md) — la version HTML est l'artefact de lecture, la Markdown reste l'artefact d'indexation et de knowledge graph.