HTML es el formato que quieren los agentes de IA

El 8 de mayo de 2026, Thariq Shihipar, ingeniero que trabaja en Claude Code en Anthropic, publicó un sitio personal que reúne 20 artefactos en HTML producidos por un agente en nueve categorías de trabajo de conocimiento, con un argumento central: cuando la respuesta contiene estructura espacial, interacción o evidencia visual, HTML supera a Markdown.¹²

HTML supera a Markdown como salida para agentes porque la estructura espacial, la interacción y la evidencia visual transmiten información que la prosa aplana. El formato que emite el agente es la superficie de control que inspecciona la persona, no un envoltorio que la rodea.

La publicación apareció seis días antes de que un artículo de arXiv del 14 de mayo mostrara que la calidad de búsqueda de los agentes vive en el entorno de ejecución, no en el recuperador.³ El patrón es el mismo: el formato y el entorno de ejecución son el sustrato, no el envoltorio. El componente solo importa después de que la superficie que lo rodea convierte la salida del modelo en algo que una persona puede verificar.

Resumen rápido

Thariq Shihipar publicó un sitio complementario con 20 ejemplos en HTML que abarcan revisión de código, sistemas de diseño, prototipado, exploración, diagramas, investigación, informes y superficies de edición.¹ La tesis: Markdown vuelve lineal información que llega de forma espacial. Diffs, grafos de llamadas, comparaciones lado a lado y prototipos interactivos transmiten significado que la prosa aplana. La época del lanzamiento de GPT-4 con 8K tokens impulsó Markdown como opción predeterminada eficiente en tokens; la documentación actual de ventanas de contexto de Claude enumera modelos de 200K y 1M tokens, lo que cambia el cálculo para muchos tamaños de artefacto.⁴⁵ Para stacks web sin compilación y renderizados en servidor, como FastAPI más HTMX, la publicación aporta el argumento desde el lado del agente: HTML es el formato que el modelo quiere producir y el formato que el navegador ya renderiza. Pasar por Markdown agrega una traducción intermedia que pierde fidelidad en ambos extremos.⁶

Ideas clave

Para quienes construyen agentes: - Deja de usar Markdown por defecto para la salida de un agente cuando la respuesta es una comparación, un diff, un diagrama de flujo o una estructura navegable. Pide HTML y deja que el agente defina una distribución espacial.¹ - Trata el formato de salida del modelo como parte de la superficie de la herramienta. Un único artefacto renderizado se puede inspeccionar mejor que una transcripción que desaparece al desplazarse.⁷

Para diseñadores de interfaces: - HTML es el medio en el que ya se entrega tu sistema de diseño. Pasar por Markdown introduce un paso de traducción que pierde fidelidad, y luego un segundo paso al renderizar.¹ - La superficie de control es lo que produce el agente. Si la persona no puede ver lo que vio el agente, la superficie está rota.⁷

Para equipos con stacks sin compilación renderizados en servidor: - La apuesta por HTML en lugar de una canalización de compilación ahora tiene validación desde el lado del agente. El formato que el modelo quiere producir y el formato que el navegador ya renderiza son el mismo.⁶ - Un sitio renderizado en servidor elimina dos veces una capa de traducción: una en el paso de compilación y otra en el paso de salida del agente. Ambas eliminaciones se refuerzan.

Qué argumentó realmente Thariq

Shihipar trabaja en Claude Code en Anthropic; la publicación está en su sitio personal, no en el blog oficial de Anthropic.² La galería complementaria contiene 20 archivos HTML autónomos producidos por un agente, agrupados en nueve categorías de trabajo donde HTML supera estructuralmente a Markdown.¹

Sus afirmaciones centrales:

La segunda afirmación es la que sostiene el peso para cualquiera que construya infraestructura web. Si el sistema de diseño se entrega en HTML, el agente debería producir HTML. Cualquier otra cosa introduce un recorrido de ida y vuelta con pérdida.

Los 20 ejemplos son el argumento

Las categorías de la galería de Shihipar cubren el trabajo que la mayoría de la gente ahora delega a un agente de código:¹

• Revisión de código: diffs anotados con notas en línea codificadas por severidad; mapas de módulos con rutas de llamadas resaltadas.
• Exploración: enfoques de código lado a lado; opciones de diseño visual dispuestas para elegir, no para leer en secuencia.
• Diseño: páginas vivas de sistemas de diseño; láminas de variantes de componentes que renderizan las variantes.
• Prototipado: entornos de prueba de animación con curvas de aceleración reales; flujos interactivos que responden a clics.
• Diagramas: figuras SVG en línea; diagramas de flujo anotados; bocetos de arquitectura con cajas y flechas.
• Investigación: secciones plegables; explicadores interactivos de conceptos con demostraciones en vivo.
• Informes: cronologías y gráficos formateados donde la estructura porta el significado.
• Editores: interfaces personalizadas con funciones de exportación integradas en el artefacto.

Cada uno es una página HTML que el modelo produjo de una sola vez. El patrón común: la respuesta es espacial o interactiva, y el artefacto renderizado conserva lo que una respuesta en Markdown tendría que describir con prosa.

Por qué Markdown era la opción predeterminada

Markdown ganó como formato predeterminado de salida para agentes por dos razones que ya no aplican.

Primero, la generación de GPT-3.5 y GPT-4 chocaba con ventanas de contexto de 4K a 8K durante el periodo en que se consolidó la convención de salida en chat.⁴ La concisión de Markdown era una presión real: un token gastado en <div class="..."> era un token que no estaba disponible para el análisis. La documentación actual de ventanas de contexto de Claude enumera contextos de 200K tokens para muchos modelos y de 1M tokens para Opus 4.1 y Sonnet 4.6.⁵ El argumento de eficiencia en tokens se ha debilitado para muchos artefactos de inspección.

Segundo, los renderizadores de terminal y las ventanas de chat renderizan Markdown de forma trivial, mientras que HTML requiere una vista web o una pestaña del navegador. La conveniencia de la superficie mantuvo a Markdown como el camino de menor resistencia incluso después de que el argumento de tokens perdiera fuerza.

La publicación de Shihipar pesa porque el autor trabaja en Claude Code en Anthropic. Los 20 ejemplos son artefactos concretos, no afirmaciones abstractas.² La cobertura de Simon Willison ese mismo día reprodujo el patrón con un explicador de un exploit de seguridad en Linux renderizado como una página HTML interactiva en lugar de un artículo en Markdown.⁸

Qué preserva HTML que Markdown descarta

Cuatro propiedades sostienen el argumento:

Cada propiedad se corresponde con una clase de tarea de agente que se vuelve más difícil cuando aplanas la salida a prosa. Un diff es una comparación espacial; un diagrama de flujo es un grafo; una revisión de sistema de diseño es un juicio visual. Forzar todo eso a pasar por Markdown le pide al lector que reconstruya lo que el renderizador podría haber mostrado.

La conexión con el entorno de ejecución

La calidad de búsqueda de los agentes vive en el entorno de ejecución, no en el recuperador. Esa publicación argumentó que el método de recuperación importa menos que el arnés que lo rodea: la forma de la instrucción, la superficie de herramientas, el formato de la transcripción, la entrega de resultados y el comportamiento de reintento.³

El argumento de HTML extiende el mismo marco a la salida. El modelo puede producir la respuesta correcta en cualquier formato. El formato que pides forma parte del contrato del entorno de ejecución. Formatos distintos producen superficies verificables distintas:

• Entrega en Markdown: el usuario lee de arriba abajo, decide qué importa y reconstruye mentalmente la estructura.
• Entrega en HTML: el modelo se compromete con una estructura, el renderizador vuelve esa estructura escaneable y el usuario inspecciona en lugar de solo leer.

Mismos datos, distinta superficie de control. El diseño agéntico es diseño de superficies de control. El formato que emite el agente forma parte de esa superficie, no es un empaque que la rodee.⁷

Qué significa esto para el stack sin compilación

La guía de FastAPI más HTMX en este sitio defiende HTML renderizado en servidor por encima de una canalización de compilación de JavaScript.⁶ La publicación de Shihipar aporta el argumento desde el lado del agente:

• El modelo quiere producir HTML.
• El navegador quiere renderizar HTML.
• Insertar Markdown o JSX entre ambos agrega dos pasos de traducción con pérdida.

Un sitio sin compilación renderizado en servidor elimina la traducción en tiempo de compilación. Producir HTML directamente desde el agente elimina la traducción en tiempo de salida. El beneficio acumulado: el mismo formato corre desde el modelo, pasa por la ruta y llega al navegador sin formas intermedias.

Esto no afirma que React o Markdown estén mal en todas partes. Dice que el costo de esos pasos de traducción ahora es visible desde ambos extremos, y que un stack que evita ambos extremos se vuelve más simple en la misma proporción.

El formato importa. El entorno de ejecución importa. Ambos son el sustrato.

El artículo sobre búsqueda de agentes y la publicación sobre HTML llegaron con ocho días de diferencia y defienden la misma forma de pensar:¹³

• El recuperador es un componente. El entorno de ejecución es el sustrato.
• El modelo es un componente. El formato de salida es el sustrato.

Pensar en componentes sigue ofreciendo mejoras locales: cambiar el recuperador, agregar memoria, sustituir el modelo, refinar la instrucción. Pensar en el sustrato cambia la superficie que ve el usuario y la superficie que produce el agente. Ambos hallazgos de esta semana empujan el trabajo hacia el segundo marco.

El movimiento práctico: cuando la respuesta de un agente contiene información espacial, pide HTML. Cuando el agente corre en un arnés, instrumenta el arnés antes de instrumentar el modelo. Ambos movimientos se refuerzan. Ninguno es una solución mágica por sí solo.

FAQ

¿Anthropic publicó esta entrada?

No. Thariq Shihipar la publicó en su sitio personal, thariqs.github.io/html-effectiveness/.¹ Trabaja en Claude Code en Anthropic, así que la señal de autoridad es fuerte, pero la publicación no es de Anthropic.²

¿El argumento aplica a todas las tareas de agentes?

No. La publicación apunta explícitamente al trabajo donde la estructura espacial, la interacción o la evidencia visual transmiten significado. Para respuestas factuales breves o salidas destinadas a la terminal, Markdown sigue siendo una buena opción predeterminada.¹

¿Qué pasa con el costo en tokens?

El argumento de costo a favor de Markdown estaba ligado a ventanas de contexto pequeñas. La documentación actual de ventanas de contexto de Claude enumera modelos de 200K y 1M tokens, lo que cambia el intercambio entre verbosidad y valor de HTML para los tamaños de artefacto que muestra la publicación.⁵

¿Esto rompe los valores predeterminados existentes de Markdown en Claude Code?

No. El argumento trata sobre la salida que le pides al modelo que produzca bajo demanda para inspección, no sobre la transcripción ni la salida de terminal. Todavía puedes pedir HTML en una sola instrucción y recibir un artefacto autónomo.¹

¿Cómo se conecta esto con el artículo sobre el entorno de ejecución de búsqueda de agentes?

Ambos argumentos apuntan al sustrato alrededor del modelo, no al modelo en sí. La calidad de búsqueda depende del arnés; la calidad de salida depende del formato. El componente es necesario; el sustrato es lo que vuelve confiable al componente.³

¿Qué debería hacer con esto un equipo que usa FastAPI más HTMX?

Tratar HTML como un destino de salida de primera clase para cualquier función de IA que publiques. El mismo formato corre desde el modelo, pasa por la ruta y llega al navegador, y el stack sin compilación ya optimiza ese camino.⁶

Referencias