Agents de codage : lisibilité accrue avec HTML et diagrammes

Présenter les réponses d’un agent de codage en HTML plutôt qu’en texte brut permet de mieux distinguer l’essentiel du superflu. Des diagrammes générés côté agent, notamment avec Archify, sont proposés pour cartographier des pipelines comme l’OCR et la classification. Ces pratiques sont décrites comme utilisées quasi systématiquement, à l’exception de cas simples.

Des diagrammes pour expliquer un système de bout en bout

La création de diagrammes est présentée comme un levier central pour rendre les échanges avec un agent de codage plus exploitables. Un package GitHub, Archify, est cité pour produire des schémas très visuels capables d’agréger beaucoup d’informations. Ces diagrammes servent à comprendre le fonctionnement de sections d’une application, par exemple la chaîne de traitement d’un téléchargement. Dans cet exemple, la représentation visuelle peut inclure une étape de classification, de l’OCR et d’autres extractions de données. Cette cartographie facilite la compréhension d’un pipeline documentaire et les modifications à y apporter. L’usage de diagrammes est recommandé dès qu’un mécanisme ou une information peut être représenté graphiquement, l’outil étant présenté comme riche en informations. L’approche repose sur l’idée que la structuration visuelle est plus intuitive pour un lecteur humain.

Passer du texte brut à un rendu HTML structuré

La recommandation principale consiste à demander aux agents de livrer leurs sorties en HTML plutôt qu’en flux texte dans le terminal. Cette pratique est appliquée dans 90 à 95 % des interactions décrites, car le terminal fournit un équivalent TXT sans capacités de mise en forme avancées. Le texte brut peut suffire pour une lecture par machine, mais rend la sélection des éléments-clés plus difficile pour un humain. À l’inverse, un rendu proche d’un document markdown, avec titres et citations, améliore l’attention et la compréhension. En HTML, l’agent peut structurer l’information avec des en-têtes, du gras pour les points critiques, des surlignages et des visuels, y compris des captures d’écran utiles à l’analyse applicative. Cette structuration est présentée comme un moyen d’améliorer l’efficacité globale de la communication.

Réorganiser la sortie pour éviter l’information éparpillée

L’auteur décrit un problème récurrent d’informations disséminées à plusieurs endroits d’un fil de discussion. Une étape intermédiaire a consisté à demander un récapitulatif exhaustif en fin de fil, afin de consolider le contexte. Toutefois, cette consolidation est jugée insuffisante si la présentation reste non formatée ou contient des éléments non pertinents. La recommandation est donc de coupler cette réorganisation avec un formatage structuré, afin de limiter les relectures et l’exposition à du contenu superflu.

Quand garder l’affichage en ligne et intensité d’usage rapportée

Des exceptions sont mentionnées pour des cas très simples, lorsque seules quelques informations rapides sont recherchées, où la lecture en ligne est conservée. L’auteur affirme utiliser cette approche de présentation jusqu’à 100 fois par jour et l’appliquer à la quasi-totalité des sessions de codage. Ces pratiques répondent à des difficultés rapportées de lecture des sorties en terminal, y compris dans des contextes avec des applications dédiées, et à la nature peu hiérarchisée du texte brut. Il est également rapporté que le bas des fils est relu de très nombreuses fois quotidiennement. L’objectif déclaré est de mieux s’aligner avec des agents tels que Claude Code ou Codex, et de clarifier leurs intentions. Le terminal n’offrant pas nativement de mise en forme avancée, la conclusion met en avant ces méthodes comme un moyen d’améliorer l’efficacité des échanges. Un exemple de bloc de citation illustre, par contraste, l’intérêt d’un formatage qui rompt la linéarité.