Por qué HTML puede ser mejor que Markdown como output de Claude

Durante años, pedir respuestas en Markdown ha sido el reflejo condicionado de cualquiera que trabaje con LLMs. Tiene su lógica histórica: cuando GPT-4 operaba con ventanas de 8.192 tokens, la eficiencia de Markdown frente a HTML marcaba una diferencia real en coste y en lo que cabía en cada llamada. Ese contexto ya no existe, y un artículo publicado esta semana lo argumenta con suficiente peso como para merecer atención.

Thariq Shihipar, ingeniero del equipo de Claude Code en Anthropic, publicó el 8 de mayo "The Unreasonable Effectiveness of HTML", una pieza que defiende HTML como formato de salida preferente cuando se trabaja con Claude. Simon Willison la recogió en su blog confesando que le ha hecho replantearse hábitos que arrastra desde la era GPT-4.

El argumento central

La tesis de Shihipar no es que Markdown sea malo. Es que con ventanas de contexto de 1M tokens —las que ofrece Claude Opus 4.7, por ejemplo— el argumento de eficiencia que justificaba Markdown se ha evaporado. HTML, en cambio, permite estructuras de presentación que Markdown simplemente no puede expresar: anotaciones inline en diffs, código coloreado por severidad, tablas con semántica real, diseño visual integrado en el propio artefacto.

El ejemplo de prompt que circula en el artículo ilustra bien el tipo de salida que se habilita:

> Help me review this PR by creating an HTML artifact that describes it. I'm not very familiar with the streaming/backpressure logic so focus on that. Render the actual diff with inline margin annotations, color-code findings by severity and whatever else might be needed to convey the concept well.

Eso es algo que un bloque de Markdown con listas y asteriscos no puede reproducir con fidelidad. El HTML resultante es, literalmente, un documento de revisión navegable, no texto plano con un poco de formato.

Por qué importa en el contexto de Claude Code

El detalle de que Shihipar trabaje en el equipo de Claude Code no es menor. Claude Code ya soporta artefactos HTML como salida nativa, y la CLI puede renderizarlos o pasarlos como input a otros pasos de un pipeline. Combinar esto con subagentes que generen informes HTML intermedios, o con hooks que procesen esos artefactos en eventos `PostToolUse`, abre flujos de trabajo que con Markdown serían torpes o directamente imposibles.

Los ejemplos recopilados en la web de ejemplos del artículo muestran casos concretos: desde visualizaciones de datos embebidas hasta interfaces de revisión de código con filtros interactivos. No son demos de laboratorio; son el tipo de artefacto que un equipo de ingeniería podría usar directamente en su flujo de revisión.

Para quién cambia esto algo

El cambio de mentalidad es más relevante para ciertos perfiles que para otros:

• Ingenieros que usan Claude Code para generar informes, revisiones de PR o análisis de logs: HTML les da control sobre la presentación sin tener que post-procesar texto plano.
• Equipos que construyen pipelines con subagentes: un artefacto HTML es un objeto más rico que puede enrutarse, almacenarse y mostrarse sin transformación adicional.
• Desarrolladores de skills y plugins: si el output de una skill es HTML, el consumidor de esa skill obtiene algo inmediatamente utilizable.

Para quien usa Claude de forma conversacional en el chat web, el impacto es menor, aunque Claude.ai ya renderiza HTML en sus artefactos de forma nativa.

El hábito que cuesta cambiar

Willison es honesto al respecto: llevar años pidiendo Markdown por defecto crea inercia. No porque Markdown sea la mejor opción, sino porque es la opción conocida. El artículo de Shihipar funciona como recordatorio de que los supuestos que formaron esos hábitos —contextos cortos, tokens caros, modelos que generaban HTML verboso y frágil— ya no son los supuestos actuales.

Los modelos actuales generan HTML estructuralmente sólido con consistencia suficiente como para confiar en él como formato de salida. Y las ventanas de contexto actuales hacen que el sobrecoste en tokens sea, en la mayoría de casos, irrelevante.

---

Desde ElephantPink, nos parece un reencuadre útil y bien argumentado. No es una recomendación absoluta —hay contextos donde Markdown sigue siendo la opción correcta—, pero la pregunta «¿por qué no HTML?» merece hacerse más a menudo de lo que se hace.