El 8 de mayo de 2026, Thariq Shihipar, ingeniero en Anthropic que trabaja en el equipo de Claude Code, publicó un argumento que cambió cómo muchos desarrolladores le piden cosas a Claude: en vez de pedir Markdown, pide HTML. La diferencia en calidad de output no es marginal, es notable.
En 30 segundos
- Thariq Shihipar (equipo Claude Code, Anthropic) publicó el 8 de mayo de 2026 un artículo argumentando que HTML supera a Markdown como formato de output en Claude.
- Con HTML, Claude puede incluir SVG, JavaScript interactivo, widgets con sliders, navegación intra-página y diff de código con anotaciones en margen.
- Markdown era la opción lógica con los límites de tokens de GPT-4 (8.192), pero los modelos actuales cambiaron esa ecuación.
- El prompt concreto que Thariq propone para code reviews con HTML ya circula entre desarrolladores y da resultados que Markdown no puede igualar.
- Simon Willison, referencia del mundo Python y de las herramientas IA, dijo que este artículo lo hizo replantear su flujo de trabajo completo.
La revolución silenciosa: por qué Thariq Shihipar cambió de Markdown a HTML
Claude Code es la herramienta de línea de comandos de Anthropic que permite a los desarrolladores interactuar con Claude directamente desde su terminal para tareas de programación, revisión de código, generación de archivos y automatización de flujos de trabajo.
Thariq Shihipar es ingeniero en el equipo de Claude Code en Anthropic. No es un blogger de opinión ni un influencer de Twitter. Es alguien que construye la herramienta que vos usás. Y su tesis, publicada el 8 de mayo de 2026 y destacada ese mismo día por Simon Willison en su weblog, es simple: cuando le pedís a Claude una explicación, un reporte o una revisión, pedila en HTML.
¿Y qué tiene de especial esto? Que la mayoría de los que usan Claude desde hace años, incluyendo Willison, venían defaulteando a Markdown. Por costumbre. Por eficiencia de tokens. Por inercia.
El artículo de Thariq cambió eso. Al menos para Willison, que lo dijo sin rodeos: “Este artículo me hizo replantearme eso, especialmente para output.”
HTML vs Markdown: más allá de la legibilidad
La comparación no es nueva, pero el contexto sí lo es. Con GPT-4 y su límite de 8.192 tokens, pedir Markdown tenía todo el sentido: es 3 a 5 veces más eficiente en tokens que HTML equivalente. Si tenés un contexto ajustado, cada token importa. Más contexto en cómo la regulación europea moldea la IA.
Ahora los modelos manejan contextos de 200k tokens en adelante. La eficiencia de tokens dejó de ser el factor limitante para la mayoría de las interacciones cotidianas. Y ahí es donde HTML empieza a ganar con claridad.
| Capacidad | Markdown | HTML |
|---|---|---|
| Tablas | Básico, sin estilos | Nativas con CSS, colores, sorting |
| Diagramas | No | SVG nativo |
| Interactividad | No | JavaScript, sliders, filtros |
| Navegación interna | Limitada | Anclas, tabs, menús |
| Código con anotaciones | Bloque plano | Diff visual con margen y color |
| Eficiencia de tokens | 3-5x más eficiente | Más pesado, pero contexto ya no limita |
5 patrones efectivos para HTML en Claude Code con ejemplos reales
El artículo de Thariq no es teórico. Viene con ejemplos concretos de cómo usar HTML en distintos escenarios. Acá los más relevantes:
Code reviews con diff visual y anotaciones
Ponele que tenés un PR con lógica de streaming y backpressure que no conocés bien. En Markdown, Claude te devuelve un bloque de texto con el diff mezclado en la explicación. En HTML, podés pedirlo así, con el prompt exacto que cita Thariq en el artículo original:
“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.”
El resultado: un diff renderizado con líneas agregadas y eliminadas en color, anotaciones en el margen clasificadas por severidad (crítico, warning, sugerencia), y secciones colapsables por archivo. Algo que Markdown no puede hacer.
Diagramas SVG explicativos
Cuando le pedís a Claude que te explique una arquitectura de microservicios o un flujo de autenticación, en Markdown obtenés texto con algún diagrama ASCII en el mejor caso (que nadie lee). En HTML, Claude genera SVG inline que muestra el flujo visualmente, con nodos, flechas y etiquetas.
Navegación intra-página para documentos largos
Si pedís un análisis de 10 secciones, HTML permite una tabla de contenidos con anclas al inicio. Hacés click, vas a la sección. Markdown en un chat no tiene eso. Para más detalles técnicos, mirá cómo Claude se compara con Gemini.
Widgets interactivos: sliders, filtros, tablas dinámicas
Acá es donde HTML realmente despega. Pedís una comparación de tres configuraciones con un slider que ajusta el parámetro N y el HTML renderizado te muestra los resultados cambiando en tiempo real. Es la diferencia entre un reporte estático y una herramienta funcional.
Reportes con métricas visuales
Si tenés datos de performance, errores de producción o resultados de un benchmark, HTML permite barras de progreso, indicadores con colores por umbral y gráficos básicos sin dependencia externa. Todo auto-contenido en un solo archivo.
Prompts efectivos para generar HTML interactivo
No basta con decir “dame esto en HTML”. Hay patrones que funcionan mejor. El más directo es especificar el artefacto desde el inicio:
“Creá una visualización HTML con [descripción del contenido]. Incluí [SVG / slider / tabla dinámica / navegación interna]. El output debe ser un archivo HTML auto-contenido que funcione en el browser sin dependencias externas.”
Eso último es importante: “auto-contenido”. Claude, si no lo aclarás, a veces referencia librerías externas que no van a cargar si abrís el archivo offline o lo mandás por mail. Con “sin dependencias externas” forzás el CSS y JS inline.
Otro patrón útil es el “paste back”: generás el HTML, lo revisás en el browser, copiás el output de vuelta a Claude Code y pedís iteraciones. “En el diff, los comentarios en el margen izquierdo no tienen suficiente contraste. Ajustá los colores y añadí el número de línea original.” El ciclo de iteración es rápido y el resultado mejora mucho con 2-3 vueltas. Lo explicamos a fondo en la batalla con herramientas de OpenAI.
Cómo integrar HTML en tu flujo de Claude Code hoy
Si usás claude.ai, los artefactos HTML se renderizan directamente en la interfaz. Podés verlos, interactuar con ellos y exportarlos. La extensión de VS Code de Claude Code también soporta preview de HTML auto-contenido.
Para flujos más avanzados: generás el HTML con Claude Code desde la terminal, lo abrís en el browser con open output.html (Mac) o start output.html (Windows), lo revisás, y volvés a Claude con el feedback. Si tu proyecto está hosteado y necesitás compartir estos outputs con el equipo, podés servirlos estáticamente, incluso en un plan básico de hosting como los que ofrece donweb.com.
Una aclaración sobre los artefactos de claude.ai: según la documentación disponible sobre artefactos, Claude genera código HTML/CSS/JS que podés ver renderizado en tiempo real dentro de la interfaz. Podés compartirlos con un link directo o descargarlos. No requieren configuración adicional.
El cambio de mentalidad que propone Willison
Simon Willison, que lleva años documentando el ecosistema de LLMs y construye herramientas en tools.simonwillison.net, reconoció algo interesante: venía pidiendo HTML principalmente para herramientas interactivas (calculadoras, utilidades, mini-apps). Nunca lo había considerado seriamente para outputs explicativos: análisis, documentación, reportes ad-hoc.
El artículo de Thariq abrió esa puerta. Pedir una explicación de una arquitectura de red en HTML, en vez de texto con bullets, te da un diagrama SVG, secciones colapsables por capa del stack, y una tabla comparativa con estilos. La misma información, navegable.
¿Siempre vale la pena? No. Para una respuesta corta de dos párrafos, Markdown está bien. Para un análisis de 10 secciones o una revisión de PR con 40 archivos cambiados, HTML gana sin discusión.
Errores comunes al pedir HTML a Claude
No especificar “auto-contenido”
Claude por defecto puede referenciar librerías vía CDN (Bootstrap, Chart.js, etc.). Si el contexto donde vas a ver el HTML no tiene acceso a internet, o querés enviarlo como attachment, el archivo no va a funcionar. Siempre especificá “HTML auto-contenido sin dependencias externas” en el prompt.
Pedir HTML para cosas que no lo necesitan
Una respuesta de tres líneas a una pregunta concreta no necesita HTML. El overhead de generar y renderizar HTML para contenido simple no tiene sentido. Reservalo para outputs que se benefician de la estructura visual: análisis largos, comparativas, revisiones de código, reportes. Complementá con las nuevas capacidades de Claude 2026.
No iterar después del primer output
El primer HTML que genera Claude es un borrador. Abrilo en el browser, revisá cómo se ve realmente, y mandá feedback específico. “El slider de la sección 3 no responde al cambiar el valor” o “los colores del diff no se distinguen bien en pantalla oscura” son feedbacks accionables. Sin esa iteración, te quedás con un output que funciona pero no es tan útil como podría ser.
Asumir que Claude “sabe” qué tipo de interactividad querés
Si querés tabs, pedí tabs. Si querés un slider que filtre resultados, describilo. Claude puede generar muchos tipos de interactividad, pero sin instrucción específica defaultea a algo simple. Cuanto más concreto sea tu pedido, mejor el output.
Preguntas Frecuentes
¿Por qué Claude genera mejor output en HTML que en Markdown?
HTML permite estructuras que Markdown no soporta: SVG nativo, JavaScript interactivo, CSS con control fino de layout. Markdown es texto formateado; HTML es una interfaz funcional. Para outputs complejos como code reviews, análisis técnicos o reportes con datos visuales, HTML da un resultado que Markdown no puede igualar en utilidad.
¿Cómo pido a Claude que me genere HTML interactivo?
El patrón más efectivo es especificar el tipo de interactividad que querés desde el inicio del prompt: “Creá un artefacto HTML auto-contenido que muestre X con [sliders / tabs / tabla dinámica / diagrama SVG]. Sin dependencias externas.” Cuanto más específico seas sobre los elementos de UI, mejor el resultado.
¿Cuándo tiene sentido usar HTML y cuándo Markdown?
HTML para: revisiones de código, análisis largos, documentación técnica con diagramas, reportes con datos visuales, cualquier output que el usuario vaya a navegar y no solo leer. Markdown para: respuestas cortas, notas rápidas, contenido que vas a copiar a otra herramienta. La heurística: si el output tiene más de 5 secciones o incluye datos comparativos, HTML gana.
¿Cómo crear artefactos HTML con widgets y SVG en Claude Code?
Desde claude.ai, los artefactos HTML se generan y renderizan automáticamente cuando pedís un output HTML. Desde Claude Code CLI, el output es texto que guardás como archivo .html y abrís en el browser. Para SVG, especificalo en el prompt: “incluí un diagrama SVG que muestre el flujo”. Para widgets, describí el comportamiento: “un slider que ajuste el valor de N entre 1 y 100 y muestre el resultado calculado”.
¿Este enfoque requiere saber HTML para usarlo?
No. Pedís el output en HTML, Claude lo genera, vos lo abrís en el browser y lo usás. Si querés iterar, describís en palabras qué cambiar. Para aprovecharlo al máximo sí ayuda entender qué elementos son posibles (SVG, sliders, tabs), pero no necesitás escribir una línea de HTML para beneficiarte del enfoque.
Conclusión
Lo que Thariq Shihipar publicó el 8 de mayo de 2026 parece un detalle técnico menor. En la práctica, es un cambio de mentalidad sobre qué le pedís a Claude y qué podés esperar recibir.
La mayoría de los que usan Claude a diario todavía piden Markdown por inercia. El límite de tokens de GPT-4 que justificaba esa elección ya no existe en los modelos actuales. El contexto cambió; el hábito no.
Probalo con el próximo PR que tengas que revisar. Usá el prompt exacto que cita Thariq: pedí un artefacto HTML con el diff renderizado, anotaciones en el margen y color-coding por severidad. Comparalo con lo que obtendrías en Markdown. La diferencia en utilidad real es suficiente para cambiar el flujo de trabajo.