Utiliser Claude Code : l’efficacité surprenante du HTML

 (twitter.com/trq212)
2 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Avec Claude Code, utiliser le HTML comme format de sortie à la place du Markdown permet de produire des résultats plus faciles à lire et à relire par des humains, grâce à des visualisations, des couleurs, des diagrammes et des interactions plus riches
  • Le HTML permet de représenter efficacement la plupart des informations que Claude peut lire, en s’appuyant sur les tableaux, le CSS, le SVG, script, les interactions JavaScript, les images, le canvas et le positionnement absolu
  • Claude Code peut lire le contexte provenant du système de fichiers, de MCP, du navigateur ou de l’historique Git, puis l’assembler dans un livrable HTML ; il suffit de demander « crée-moi un fichier HTML » pour commencer
  • Les principaux usages se répartissent en spécifications, planification et exploration, revue et compréhension de code, design et prototypage, rapports, recherche et apprentissage, ainsi qu’interfaces d’édition jetables sur mesure
  • Le HTML prend 2 à 4 fois plus de temps à générer que le Markdown et ses diff sont plus bruyants, ce qui complique le contrôle de version, mais ses avantages en matière d’expressivité, de partage et de probabilité réelle d’être lu sont mis en avant

Pourquoi j’ai fini par préférer le HTML au Markdown

  • Le Markdown est devenu le format de fichier dominant pour la communication entre agents et humains : il est simple, portable, permet un peu de mise en forme et reste facile à éditer manuellement
  • Claude sait aussi très bien produire des diagrammes ASCII dans du Markdown, mais à mesure que les agents gagnent en puissance, le Markdown donne l’impression d’un format contraignant
  • Un fichier Markdown de plus de 100 lignes devient difficile à lire, et l’envie vient de partager plus facilement des visualisations, des couleurs et des diagrammes plus riches
  • Comme on demande de plus en plus souvent à Claude d’éditer les fichiers à notre place, l’un des grands avantages du Markdown — la facilité d’édition directe — perd de sa valeur
  • Même au sein de l’équipe Claude Code, l’usage du HTML comme format de sortie progresse, avec des exemples visibles sur html-effectiveness

L’expressivité et la facilité de partage du HTML

  • Le HTML peut représenter non seulement la structure documentaire, comme les titres et la mise en forme, mais aussi une palette d’informations bien plus large que le Markdown
  • Parmi les informations représentables figurent les données tabulaires via les tableaux, les données de design via le CSS, les illustrations SVG, les extraits de code via la balise script, ainsi que les interactions grâce à JavaScript et au CSS
  • Il est possible de représenter des workflows en SVG et en HTML, des données spatiales avec le positionnement absolu et le canvas, et d’insérer des images avec la balise img
  • La plupart des types d’information que Claude peut lire peuvent être représentés assez efficacement en HTML, ce qui en fait un format efficace à la fois pour transmettre des informations riches depuis le modèle et pour les faire relire par un humain
  • Sans HTML, Claude peut se retrouver à produire en Markdown des diagrammes ASCII ou à estimer des couleurs avec des caractères Unicode, ce qui revient à des modes d’expression inefficaces
  • À mesure que Claude exécute des tâches plus complexes, il rédige des spécifications et des plans plus volumineux, et dans les faits un fichier Markdown de plus de 100 lignes se lit mal
  • Les documents HTML peuvent organiser visuellement leur structure avec des onglets, des illustrations et des liens, ce qui les rend faciles à explorer, et ils peuvent aussi être rendus responsive pour une lecture différente selon la taille d’écran
  • Les fichiers Markdown sont mal rendus nativement par les navigateurs et doivent souvent être joints à un e-mail ou à un message, tandis qu’un HTML peut être mis sur S3 et partagé très facilement par lien
  • Des spécifications, rapports ou descriptions de PR en HTML sont bien plus simples à ouvrir et à consulter pour des collègues, ce qui augmente fortement les chances qu’ils soient réellement lus
  • Un document HTML peut prendre en charge des interactions bidirectionnelles, par exemple en ajoutant des sliders ou des molettes pour ajuster un design ou modifier des options d’algorithme et observer le résultat
  • On peut aussi créer une fonctionnalité qui copie les réglages ajustés sous forme de prompt à recoller dans Claude Code ; un exemple connexe est présenté dans le playgrounds post

Pourquoi utiliser HTML avec Claude Code

  • Claude Code peut lire des contextes variés — système de fichiers, MCP, navigateur, historique Git — puis les assembler dans un résultat HTML
  • Par exemple, il peut trouver tous les fichiers HTML générés dans un dossier de code, les regrouper et les classer, puis produire un fichier HTML contenant des diagrammes représentant chaque type
  • Au-delà du système de fichiers, il peut chercher du contexte supplémentaire dans MCP comme Slack ou Linear, dans le navigateur web via Claude in Chrome, ou encore dans l’historique Git
  • Concevoir des documents HTML avec Claude est plus amusant et donne le sentiment d’être davantage impliqué et investi dans ce qui est produit
  • Il n’est pas nécessaire de créer une compétence /html dédiée : il suffit de demander « crée-moi un fichier HTML » ou « crée-moi un artifact HTML » pour démarrer
  • L’astuce importante est de savoir ce que l’artifact doit faire et comment il sera utilisé ; au début, mieux vaut écrire un prompt depuis zéro à chaque fois afin d’apprendre différents usages

Principaux usages

  • Spécifications, planification, exploration

    • Le HTML devient une toile riche sur laquelle Claude peut creuser un problème, et il est possible de démarrer le travail non pas avec un seul plan Markdown, mais avec un ensemble de plusieurs fichiers HTML
    • On peut d’abord faire un brainstorming de plusieurs directions, puis en développer une avec des maquettes ou des extraits de code, avant de rédiger enfin le plan d’implémentation
    • Une fois le plan satisfaisant, on peut créer une nouvelle session et lui transmettre ces fichiers pour implémentation, tandis qu’un agent de vérification peut lire les mêmes fichiers pour disposer d’un contexte plus large
    • Il est possible de demander une grille HTML unique présentant 6 approches pour un écran d’onboarding, avec des différences de layout, de ton et de densité, ainsi que les compromis de chaque choix
    • On peut aussi faire produire un plan d’implémentation HTML lisible intégrant des maquettes, des flux de données et des extraits de code à relire
    • Cela peut servir à explorer des approches d’implémentation ou à comparer plusieurs directions visuelles

  • Revue et compréhension du code

    • Le code peut être difficile à lire dans un fichier Markdown, alors qu’en HTML il est possible de rendre des diff, des annotations, des schémas de flux ou des structures de modules
    • Cela peut servir à comprendre du code écrit par un agent, à recevoir une revue de code ou à expliquer des changements à quelqu’un qui relit une PR
    • Dans certains cas, cela fonctionne mieux que la vue diff standard de GitHub, et on peut imaginer un flux où chaque PR embarque un fichier HTML d’explication du code
    • On peut demander un artifact HTML pour revue de PR, ciblé sur une logique de streaming/backpressure peu familière, avec des annotations en marge sur le diff réel et un code couleur selon la gravité
    • Cela peut servir à rédiger une PR, relire une PR ou comprendre un sujet de code

  • Design et prototypage

    • Claude Design repose sur le HTML, et le HTML offre une forte expressivité pour le design, même si la surface finale n’est pas du HTML
    • Claude peut esquisser un design en HTML, puis l’écrire dans le langage souhaité, comme React ou Swift
    • Il est possible de prototyper des interactions comme des animations ou des actions, et d’ajouter des sliders ou des molettes pour ajuster les valeurs souhaitées
    • On peut lui demander de créer un bouton de checkout qui, au clic, joue une animation puis devient rapidement violet, avec plusieurs sliders, options et un bouton pour copier les paramètres jugés les plus adaptés
    • Cela peut servir à générer des artifacts de design system, ajuster des composants, visualiser une bibliothèque de composants ou prototyper des animations plaisantes

  • Rapports, recherche, apprentissage

    • Claude Code est très efficace pour synthétiser des informations issues de plusieurs sources de données et les transformer en rapports faciles à lire
    • On peut lui faire chercher dans Slack, dans la codebase, dans l’historique Git ou sur Internet, puis générer des rapports lisibles pour soi-même, pour le management ou pour l’équipe
    • Le résultat peut prendre la forme d’un long document HTML, d’un guide interactif, de slides ou d’un deck
    • Lui faire produire des diagrammes en SVG aide à la visualisation
    • Lors de la préparation d’un article sur le prompt caching, une approche a consisté à lui faire lire l’historique Git puis à produire un fichier de recherche HTML approfondi couvrant l’ensemble des changements liés au prompt caching
    • On peut lui faire lire le code lié à un rate limiter et lui demander une page explicative HTML unique contenant un diagramme de flux token-bucket, 3 ou 4 extraits de code clés annotés, ainsi qu’une section gotchas en bas de page
    • Cela peut servir à résumer le fonctionnement d’une fonctionnalité, expliquer un concept, produire un rapport d’avancement hebdomadaire, un rapport d’incident, ou des illustrations SVG, des organigrammes et des diagrammes techniques

  • Interfaces d’édition sur mesure

    • Lorsqu’il est difficile d’exprimer ce que l’on veut avec une simple zone de texte, on peut créer un éditeur HTML jetable adapté aux données en cours de travail
    • Il ne s’agit pas d’un produit ni d’un outil réutilisable, mais d’un fichier HTML unique conçu pour un seul morceau de données précis
    • L’idée clé consiste à ajouter à la fin un export du type « copy as JSON » ou « copy as prompt », afin de pouvoir recoller dans Claude Code le résultat manipulé via l’interface
    • On peut transformer 30 tickets Linear en cartes glissables-déposables réparties dans les colonnes Now / Next / Later / Cut, puis copier l’ordre final en Markdown avec une justification d’une ligne par catégorie
    • On peut aussi créer un éditeur à base de formulaires pour des réglages de feature flags, les regrouper par zone, afficher les dépendances, avertir lorsqu’on active un flag alors qu’un flag préalable est désactivé, puis copier uniquement les clés modifiées sous forme de diff
    • Lorsqu’on ajuste un prompt système, on peut avoir à gauche un prompt éditable avec des emplacements de variables mis en évidence, et à droite le rendu en temps réel de trois entrées d’exemple, avec compteur de caractères, compteur de tokens et bouton de copie
    • Cela peut servir à réorganiser des tickets, des cas de test ou des retours, à éditer des réglages structurés, à ajuster des prompts, des templates ou des formulations, à faire de la curation de datasets, à annoter des documents, transcriptions ou diff, ou à choisir des valeurs difficiles à exprimer textuellement comme une couleur, une easing curve, une crop region, une cron schedule ou une regex

Questions fréquentes et limites

  • Le Markdown consomme généralement moins de tokens, mais le HTML offre davantage d’expressivité et a plus de chances d’être réellement lu, ce qui améliore le résultat global
  • Avec la fenêtre de contexte de 1MM d’Opus 4.7, l’augmentation de l’usage de tokens se remarque peu dans la fenêtre de contexte
  • L’usage décrit s’approche d’une préférence maximale pour le HTML, au point d’avoir quasiment cessé d’utiliser le Markdown dans presque tous les cas
  • Les fichiers HTML peuvent être ouverts dans un navigateur local, on peut aussi demander à Claude de les ouvrir, et s’il faut un lien partageable, on peut les mettre sur S3
  • Générer du HTML prend plus de temps que du Markdown — parfois 2 à 4 fois plus — mais le résultat est jugé suffisamment utile pour compenser
  • L’un des plus gros inconvénients reste le contrôle de version : les diff HTML sont plus bruyants et plus difficiles à relire que les diff Markdown
  • Pour amener Claude à produire un HTML correspondant à ses goûts, un frontend design plugin peut aider
  • Pour coller au style de l’entreprise, on peut laisser Claude regarder la codebase afin qu’il produise un fichier HTML unique de design system servant ensuite de référence pour les autres fichiers HTML
  • Utiliser le HTML réduit la peur de ne pas lire en profondeur les plans rédigés par Claude et de devoir lui laisser trop de choix, ce qui aide à rester davantage dans le flux du travail avec Claude

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Réactions sur Hacker News

  • Ce qui m’inquiète, si on penche vers le HTML, c’est de perdre cette capacité à rédiger et modifier des documents conjointement entre humains et LLM
    Pour un texte explicatif simple, ça va, mais pour une spécification plus complexe, la capacité d’entrer directement dans le résultat généré pour le corriger est très importante. Les documents HTML sont bien plus difficiles à modifier ainsi que le Markdown, et on peut bien sûr redemander au LLM de modifier le HTML, mais quand on sait déjà clairement dans sa tête ce qu’on veut dire, cela devient un obstacle supplémentaire. Si ce schéma devient courant, la co-création humain/LLM risque de diminuer encore, au profit d’une délégation au LLM du style, du ton et même des choix de contenu. J’ai été surpris de ne pas voir cette inquiétude dans la FAQ du blog

    • Le Markdown prend en charge le HTML inline pour les éléments interactifs, donc un document Markdown accompagné d’un modèle HTML connu et d’une procédure de build simple pourrait être une alternative intéressante
      Par exemple, avec une commande pandoc en une ligne
    • Je pense qu’il y a encore une étape au-dessus. Le HTML permet déjà beaucoup de choses, mais laisser un LLM définir son propre langage s’est aussi révélé étonnamment efficace
      Je fais en ce moment un petit jeu mobile avec vue isométrique et son, et j’ai demandé à Codex de créer un outil qui place des blocs dans une doc three.js préparée et prend des captures via les outils de développement de Chromium ; il a alors créé une petite structure JSON qui définit blocs, couleurs et effets pour produire un tileset 2.5D. Je lui ai aussi fait définir les sons et la musique avec un script Python uv, et il a inventé un format YAML capable de générer du bruit. Ça dépasse complètement le test du pélican SVG, et Codex a même produit suffisamment de prototype art pour des soldats, chevaliers et prêtres, ainsi qu’une bande-son prototype
    • Cela fait des décennies que nous écrivons facilement du HTML à la main. Les éditeurs de texte sont très bons pour écrire du HTML, et avec des commandes comme le retour à la ligne automatique et la fermeture automatique, lire et écrire reste simple
    • J’ai l’impression que cela ne vaut que si l’on s’enferme volontairement dans un émulateur de téléscripteur primitif. Dans un vrai environnement de développement, éditer du HTML devrait être très simple, et si l’on va vers des sorties de modèle plus riches, un éditeur WYSIWYG intégré peut aussi être une option
    • J’ai commencé récemment à utiliser du HTML pour des rapports, mais je garde toujours un fichier Markdown comme format intermédiaire, puis je demande au LLM d’en faire une version plus soignée avec des graphiques et illustrations SVG à partir des tableaux du Markdown

  • Il y a une ironie dans le fait qu’il ne s’agisse pas d’une page HTML interactive, mais d’un post Twitter avec une image rendue en HTML
    Défendre le HTML sur une plateforme dont la structure sémantique est plus pauvre que celle du Markdown, c’est finalement assez drôle

  • Voici un prompt que j’utilise souvent quand j’explore de nouvelles idées ou de nouveaux outils

    In a single index.html, no dependencies, sparse styling, create an app that

    Je construisais déjà de petits outils comme ça avant l’IA, et j’aime le fait de pouvoir envoyer l’outil par e-mail à un ami en lui disant : « si tu veux le modifier, passe-le à un LLM »

    • C’est exactement la bonne approche
      La portée de ce qu’on peut faire avec un seul fichier HTML contenant style et JS est étonnamment large pour des dashboards, des petites applis, des utilitaires qui interagissent avec une API ou vont chercher des données quelque part. On peut le déposer dans le dossier personnel ~ d’un serveur partagé de l’entreprise, et tout le monde peut immédiatement le voir et l’utiliser
    • J’utilise aussi cette approche quand j’itère sur le design d’un nouveau client : je fais un simple index.html avec du CSS inline, puis quand le résultat me plaît, je place ce fichier à côté des fichiers de template du projet et je demande au LLM d’intégrer le design de index.html dans le template
    • Je me sens un peu bête de n’avoir jamais vraiment pensé à ce cas d’usage avant. Son utilité est pourtant évidente
      Jusqu’ici, avec les LLM, je me concentrais surtout sur « l’appli » elle-même, et pas sur les outils auxiliaires autour d’elle. Or ces outils n’ont pas besoin d’être très finis ni de gérer tous les cas : ils doivent simplement fonctionner assez bien pour être utiles. Une fois leur rôle rempli, on les jette et on en recrée d’autres le lendemain
    • J’avais découvert cette astuce il y a un moment et créé tout un tas de calculateurs pour l’électronique analogique : https://cofree.coffee/~solomon/calculators/
      C’est extrêmement pratique de pouvoir assembler vite ce genre d’outil et le publier sur un site statique
    • C’est aussi ce que fait Claude sur le web quand on lui demande du HTML. Il le produit sous forme d’artefact, donc il y a de fortes chances que le modèle soit bien entraîné à ce schéma

  • Les technologies web ont vraiment réussi énormément de choses. Beaucoup s’en plaignent, mais c’est impressionnant
    Dans mon emploi précédent, j’ai travaillé sur une appli codée en vibe coding et j’ai fini par partir à cause de ça : l’architecture avait un frontend Next.js en page unique et un backend API séparé, si bien que les URL côté utilisateur ne correspondaient pas aux endpoints backend. Comme l’IA mettait des hooks React partout, l’état vivait en mémoire et le routage basé sur l’URL n’existait pas, sauf s’il était pensé explicitement. Résultat : on n’obtenait pas gratuitement des liens, et les utilisateurs n’avaient aucun moyen de lier quoi que ce soit en dehors du point d’entrée principal. Des liens, tout simplement. Surtout pour les outils internes, tout doit pouvoir être lié pour faciliter la collaboration et la résolution de problèmes. Cette idée de conception avec localisation uniforme des ressources et verbes était déjà remarquablement bien pensée il y a 30 ou 40 ans

    • Tu veux dire que l’URL ne se mettait pas à jour quand on naviguait vers une autre page ou un autre onglet ?

  • Il manque ici quelques compromis dans l’opposition HTML/Markdown. Le HTML est bien moins efficace en tokens, et il est plus difficile de donner un retour précis sur un plan HTML que sur du Markdown
    Ces deux compromis jouent en faveur d’Anthropic. Utiliser le HTML comme médium augmente la consommation de tokens, et il est probable qu’ils investissent dans des outils d’annotation ou de marquage du HTML dans Claude Design, ce qui peut aussi renforcer l’effet de verrouillage. Soit un hasard, soit une excellente stratégie

    • C’est un peu moins efficace, certes, mais sauf s’il y a énormément de structure ou d’éléments visuels, l’écart n’est pas gigantesque
      Je ne vois pas non plus très bien pourquoi il serait plus difficile de donner un retour précis qu’en Markdown. On peut mettre des id, des sections, etc. sur les balises
    • Le HTML a aussi une surface plus large pour les failles d’exécution de code. Du texte brut, lui, ne peut pas faire de mal

  • Malgré des décennies passées avec le HTML, pour des documents simples, le Markdown reste plus rapide. Il serait utile d’avoir un point intermédiaire, et en pratique cela existe déjà, par exemple avec le GitHub Markdown enrichi
    On peut y embarquer Mermaid, ou utiliser quelque chose comme MDX qui mélange des composants quand c’est nécessaire. Il me semble aussi que readme.com utilise MDX en interne. Si on a besoin de cartes ou de mises en page, on peut ajouter des composants basés sur quelque chose comme Bootstrap. Ce qu’il manque désormais, c’est surtout le support côté interface. Comme on sait déjà rendre du HTML pur, ajouter un Markdown plus puissant ne devrait pas être si difficile

    • MDX me semble être le point d’équilibre parfait. Ce commentaire me donne envie de commencer à utiliser MDX au lieu du Markdown classique

  • La spécification Markdown d’origine [1] et CommonMark [2] prévoient toutes deux explicitement la prise en charge du HTML inline. Selon l’usage, on peut donc obtenir une partie des avantages des deux mondes
    La plupart du temps, on utilise des titres et paragraphes Markdown classiques, et avec des images et tableaux, cela reste lisible dans sa forme source sans balises HTML. Si l’on veut insérer quelque chose comme le SVG mentionné par l’auteur, on peut intégrer directement le SVG, et la personne qui lit n’a plus qu’à rendre le Markdown avec son visualiseur favori. Dans VS Code, si l’on regarde un fichier Markdown brut et qu’on tombe sur des balises HTML, il suffit d’ouvrir la prévisualisation avec Cmd+Shift+V. Bien sûr, pour une véritable page web avec boutons interactifs et style entièrement personnalisé, c’est difficilement réalisable, mais si l’essentiel reste du texte, des images et des tableaux, avec seulement quelques éléments supplémentaires ici ou là, on peut aller déjà très loin
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • À mon avis, un document Markdown ne devrait pas avoir besoin de prévisualisation. Sinon, autant faire directement un document HTML

  • Depuis janvier, je pousse fortement cette approche pour des usages non liés au code. La propriété essentielle, c’est d’avoir une source unique de vérité modifiable, compréhensible par le LLM et par l’humain, rendable et modifiable de façon incrémentale
    Je parle souvent du travail avec l’IA à des gens ordinaires, et quand je tombe sur une conversation sur l’IA dans la rue, je m’y invite presque comme un anthropologue. Les artefacts HTML sont comme une nouvelle barre d’URL du navigateur. De la même façon que certains utilisateurs pensent en réalité à Google quand ils parlent de la barre d’adresse. Aujourd’hui, beaucoup de gens me parlent de travaux comme des « feuilles de calcul », « présentations », « résumés marketing d’une page », « diaporamas », « analyses concurrentielles » ou « schémas de systèmes CVC », en disant que travailler avec ChatGPT ou Claude sur le web n’était pas terrible, alors que créer un nouveau document avec Claude Code ou OpenClaw semblait miraculeux
    Quand je leur demande ce qu’était réellement le document et d’où venait cette différence d’expérience, il faut souvent beaucoup creuser, faute de vocabulaire informatique, ou leur demander de me montrer directement ; mais au final, on aboutit toujours au fait que l’artefact est du HTML. L’expérience agréable vient d’un fichier HTML dans le système de fichiers (+ CSS + images), modifié de manière itérative avec un rendu immédiat de haute qualité, et auquel on peut ajouter un peu de JavaScript si besoin. S’il y a un système git, il se peut même qu’ils bénéficient du versionnage sans le savoir. Sinon, je leur recommande de créer des checkpoints. Pour le grand public, le contrôle de version est peut-être l’étape d’apprentissage suivante
    À l’inverse, l’expérience enfermée dans le web consiste à piquer encore et encore des DOCX/PPTX/XLSX coincés dans une fenêtre de contexte, tout en manipulant une notion floue de stockage local. Et ce, même si au fond c’est rendu en HTML dans une sidebar. Le flux de travail HTML facilite aussi énormément l’intégration d’autres médias. Au bout du compte, ce genre de travail de présentation, c’est du vibe coding pour le grand public, sans qu’il soit nécessaire de connaître toutes les couches cachées en dessous. Et si on le souhaite, on peut quand même ouvrir, corriger ou transmettre facilement le tout à un autre agent. Un système conçu pour la communication multimédia collaborative est ainsi devenu utile pour permettre à l’intelligence machine d’aider notre communication

  • Avant, notre agent chez nous (https://www.definite.app/) écrivait rapports et tableaux de bord sous forme de spécifications YAML rendues par un framework frontend
    Par exemple, si un utilisateur demandait « crée-moi un rapport montrant le chiffre d’affaires mensuel et le nombre de commandes, puis affiche les 100 commandes les plus récentes », l’agent rédigeait une spécification qui était ensuite rendue côté frontend. Cette approche était rapide, mais on s’est retrouvés submergés par les demandes de fonctionnalités que le framework devait prendre en charge : « ici je voudrais enlever le libellé », « là il me faut un libellé », « peut-on transformer ce graphique en heatmap ? », etc. Depuis quelques mois, on laisse simplement l’agent produire du HTML ; la génération prend plus de temps, mais il n’y a plus de limite sur la personnalisation. Le nouveau fonctionnement a encore ses problèmes, par exemple les utilisateurs non techniques qui doivent déboguer les applis monstrueuses qu’ils ont créées, mais globalement les clients l’apprécient bien davantage

    • Dans ce cas, comment empêchez-vous les injections de prompt ?

  • Pour lire de longues sorties d’agent, j’utilise VIM et Quick Look sur macOS (avec une extension de rendu Markdown), ou je colle le tout dans MarkEdit avec son panneau de prévisualisation
    Au pire, il suffit de demander à l’agent de créer une simple page web locale qui interprète et rend le Markdown. Le Markdown a été inventé comme une forme abrégée de la syntaxe du web[0], et c’est précisément à cela qu’il sert. Les tokens et le temps nécessaires pour demander à un agent de convertir du Markdown basique en HTML me semblent supérieurs à ceux qu’exigent ces autres méthodes
    0. https://daringfireball.net/projects/markdown/

    • Il y a de fortes chances que cela consomme plus de tokens, mais comme l’auteur travaille chez Anthropic, il n’a probablement jamais eu à payer lui-même le coût des tokens
    • Si l’on veut aller jusqu’au bout du vibe, pourquoi ne pas demander au bot de résumer aussi les longues sorties ?
      L’usage des bots devient vraiment frénétique et autoréférentiel
    • Je serais curieux de savoir quelle extension Quick Look c’est. J’en cherchais une correcte