
Markdown se ha quedado estrecho
Markdown tiene muchas virtudes: es simple, se lleva a cualquier sitio, admite algo de texto enriquecido y es fácil de editar a mano. Claude incluso se ha vuelto sorprendentemente bueno dibujando diagramas con caracteres ASCII dentro de un archivo Markdown.
Pero los agentes son cada vez más potentes, y Thariq siente que Markdown se ha quedado estrecho. Le cuesta leer un archivo de más de cien líneas. Quiere visualizaciones más ricas, con color y diagramas, y quiere poder compartirlas con facilidad.
Además, cada vez edita menos esos archivos él mismo. Los usa como especificaciones, como documentos de referencia o como resultado de una lluvia de ideas, y cuando hay que cambiarlos se lo pide a Claude. Así que una de las grandes ventajas de Markdown, que se edita fácil a mano, ya casi no le sirve. Por eso ha empezado a preferir el HTML como formato de salida.
Densidad de información
Thariq da seis razones, y la primera es la densidad de información. El HTML puede contar mucho más que el Markdown: hace lo básico, como títulos y formato, pero también puede representar muchos otros tipos de información:
Con filas y columnas de verdad.
Con CSS: color, letra y espaciado.
Con SVG, dentro del propio archivo.
Fragmentos resaltados.
Controles que responden gracias a JavaScript.
Cajas, flechas, coordenadas, lienzos e imágenes.
Llega a decir que casi no hay información que Claude pueda leer y que no se pueda representar con HTML de forma bastante eficiente. Por eso es una vía muy eficaz para que el modelo te cuente algo en profundidad y para que tú lo revises.
Cuando no puede usarlo, el modelo recurre a trucos poco eficientes en Markdown, como los diagramas en ASCII. O su favorito: aproximar colores con caracteres unicode. En una captura del artículo, Claude Code intenta enseñar una paleta de colores con bloques de puntitos grises.
Claridad y facilidad para compartir
La segunda razón es la claridad visual. Claude hace trabajos cada vez más complejos, así que escribe especificaciones y planes cada vez más largos. Thariq reconoce que, en la práctica, no lee más de cien líneas de Markdown, y desde luego no consigue que nadie más de su empresa las lea.
Un documento en HTML se lee mucho mejor. Claude puede organizarlo para navegarlo con pestañas, ilustraciones y enlaces, y puede adaptarlo al móvil para que lo leas distinto según la pantalla. Es el mismo contenido, pero pensado para leerlo y no para hacer scroll.
La tercera es que se comparte fácilmente. Un archivo Markdown cuesta compartirlo, porque la mayoría de navegadores no lo muestran bien: acabas mandándolo como adjunto en un correo o en un mensaje. Con HTML basta con subir el archivo (por ejemplo, a S3 de Amazon) y compartir el enlace. Tus compañeros lo abren donde quieran y lo consultan cuando lo necesitan.
Y según Thariq, la probabilidad de que alguien lea de verdad tu especificación, tu informe o la descripción de tu pull request es muchísimo mayor si está en HTML.
Interacción, contexto y diversión
La cuarta razón es la interacción en los dos sentidos. Puedes pedirle a Claude deslizadores y ruedas para ajustar un diseño, o para cambiar las opciones de un algoritmo y ver qué pasa. Y un botón que copie tus cambios como un prompt, para pegarlos de vuelta en Claude Code. Es la misma idea de sus «playgrounds».
La quinta es el contexto. ¿Por qué hacer estos archivos con Claude Code y no en la web de Claude o con Claude Design? Porque Claude Code puede leer muchísimo contexto: tus archivos, tus servidores MCP (como Slack o Linear), tu navegador con Claude in Chrome y tu historial de git.
Un ejemplo: para escribir el artículo, Thariq le pidió a Claude Code que buscara en su carpeta de código todos los archivos HTML que había generado, que los agrupara por tipos y que hiciera un HTML con un diagrama de cada tipo. Los diagramas del artículo salieron de ahí.
Y la sexta: es divertido. Hacer documentos en HTML con Claude es más entretenido, y Thariq se siente más implicado en lo que crea. Dice que solo por eso ya merece la pena.
Cómo empezar
Thariq teme que la gente lea su artículo y lo convierta en una skill /html o algo parecido. Puede tener su valor, pero insiste en que no hace falta casi nada. Basta con pedirle a Claude «hazme un archivo HTML» o «hazme un artefacto HTML».
El truco está en saber qué quieres que haga ese archivo y cómo lo vas a usar. Con el tiempo quizá acabes creando una skill, pero de momento recomienda pedirlo desde cero cada vez, para aprender a sacarle partido en cada caso.
Cuatro familias de usos
Thariq ha hecho muchos archivos HTML para usos distintos y los ha reunido en una galería. Los agrupa en cuatro familias.
1. Especificaciones, planificación y exploración
Cuando empieza con un problema, en lugar de un plan sencillo en Markdown, espera acabar con una red de archivos HTML. Primero le pide a Claude Code una lluvia de ideas con varias opciones distintas. Luego, que profundice en una, quizá con maquetas o fragmentos de código. Cuando lo ve claro, le pide un plan de implementación con maquetas, el flujo de datos y el código importante.
Si el plan le convence, abre una sesión nueva y le pasa todos esos archivos para que lo implemente. Y al verificar, el agente que comprueba el trabajo los lee también, así que entiende mucho mejor qué se necesita. Un prompt de ejemplo:
No sé qué dirección darle a la pantalla de bienvenida. Genera seis enfoques muy distintos (cambia la distribución, el tono y la densidad) y ponlos en cuadrícula en un solo HTML, para compararlos. Etiqueta cada uno con lo que sacrifica.
2. Revisar y entender código
En Markdown, el código cuesta leerlo. En HTML se pueden mostrar los cambios con anotaciones, diagramas de flujo o módulos. Sirve para entender lo que ha escrito el agente, para pedir una revisión o para explicar tu pull request a quien lo revise. A Thariq le funciona a menudo mejor que la vista de cambios de GitHub, y ya añade un explicador en HTML a cada pull request que hace. Su prompt:
Ayúdame a revisar este PR con un artefacto HTML que lo describa. Muestra el diff real con anotaciones al margen y colorea los hallazgos según su gravedad.
3. Diseño y prototipos
Claude Design se basa en HTML porque es increíblemente expresivo para diseñar, aunque el producto final no sea una web. Claude puede bocetar el diseño en HTML y después escribirlo en el lenguaje que uses, sea React o Swift. También puedes prototipar interacciones:
Quiero un botón de pago nuevo que, al pulsarlo, haga una animación y se vuelva morado. Hazme un HTML con deslizadores para probar opciones y un botón para copiar los parámetros que funcionen.
Sirve para documentar tu sistema de diseño (colores, tipografías y espaciados), para ajustar componentes, para ver una biblioteca de componentes de un vistazo o para prototipar animaciones que den gusto.
4. Informes, investigación y aprendizaje
Claude Code es muy bueno juntando información de varias fuentes y convirtiéndola en un informe fácil de leer. Puede buscar en tu Slack, en tu código, en el historial de git o en internet, y preparar informes para ti, para tus jefes o para tu equipo. Puede ser un documento largo, un explicador interactivo o incluso una presentación, con diagramas en SVG.
Para sus artículos sobre la caché de prompts, Thariq le pidió que leyera el historial de git y le preparara un informe a fondo, en HTML, con todos los cambios del equipo. Otro prompt de ejemplo:
No entiendo cómo funciona nuestro limitador de peticiones. Lee el código y hazme una sola página que lo explique: un diagrama del flujo, los fragmentos clave comentados y una sección de trampas al final.
Editores a medida
Hay cosas difíciles de describir solo con texto. En esos casos, Thariq le pide a Claude un editor desechable, hecho para lo que tiene entre manos. No es un producto ni una herramienta reutilizable: es un único archivo HTML, pensado para ese dato concreto.
El truco es terminar siempre con una exportación: un botón de «copiar como JSON» o de «copiar como prompt» que convierte lo que hiciste en la interfaz en algo que puedes pegar en Claude Code. Sus tres ejemplos:
- Repriorizar treinta tíquets de Linear. Cada tíquet es una tarjeta que se arrastra entre cuatro columnas (ahora, siguiente, más tarde y fuera). Claude las coloca primero según su criterio, y un botón exporta el orden final con una frase que justifica cada columna.
- Editar los interruptores de funciones. Un formulario que los agrupa por áreas, muestra las dependencias y avisa si enciendes uno cuyo requisito está apagado. El botón de «copiar diferencias» da solo las claves que han cambiado.
- Afinar un prompt de sistema. A la izquierda, el prompt editable con las variables resaltadas; a la derecha, tres ejemplos que se rellenan en vivo; debajo, un contador de tokens y un botón de copiar.
Sirve para ordenar o clasificar cualquier cosa, para editar una configuración con reglas, para afinar prompts viendo el resultado, para curar datos o anotar documentos, y para elegir valores que cuesta expresar con palabras: un color, una curva de animación, un recorte o una expresión regular.
Las dudas habituales
Thariq ha oído varias preguntas una y otra vez:
- ¿No gasta más tokens? Sí, Markdown suele gastar menos. Pero el HTML es más expresivo y es mucho más probable que él lo lea, así que en conjunto el resultado es mejor. Y con la ventana de un millón de tokens de Claude Opus, el gasto extra casi no se nota.
- ¿Cuándo usa todavía Markdown? Casi nunca: lo ha dejado para casi todo, aunque reconoce que es un maximalista del HTML.
- ¿Cómo abre los archivos? En el navegador, en local, o pidiéndole a Claude que los abra. Si quiere compartirlos, los sube a S3.
- ¿No tarda más? Sí: el HTML puede tardar entre dos y cuatro veces más que el Markdown, pero para él compensa.
- ¿Y el control de versiones? Es uno de sus mayores inconvenientes: las diferencias entre dos versiones de un HTML tienen mucho ruido y cuestan más de revisar.
- ¿Y si queda feo? El plugin de diseño frontend-design ayuda a Claude a hacer buenos HTML. Para que siga el estilo de tu empresa, pídele un único archivo con tu sistema de diseño, sacado de tu código, y úsalo como referencia para todos los demás.
Dentro del bucle
Al final, Thariq cree que la verdadera razón por la que usa HTML es que se siente mucho más dentro del bucle con Claude. Como había dejado de leer los planes a fondo, temía que no le quedara más remedio que dejar a Claude tomar sus propias decisiones. Se alegra de decir que ha pasado lo contrario: con el HTML se siente más dentro del bucle que nunca.
Markdown se queda corto cuando los agentes escriben más de lo que podemos leer; el HTML aporta densidad, claridad, enlaces que se comparten, interacción y contexto, y te devuelve al bucle.
¿Tus agentes todavía te escriben en Markdown?
Fuentes
- «Using Claude Code: The Unreasonable Effectiveness of HTML», de Thariq (@trq212), mayo de 2026. También en el blog de Claude.
- La galería de ejemplos: thariqs.github.io/html-effectiveness.
- El vídeo, en mis tres canales: español, inglés y portugués.