Using Claude Code: The Unreasonable Effectiveness of HTML

Puntos clave

1. Autor. Thariq Shihipar — Ingeniero y emprendedor serial, equipo de Claude Code en Anthropic. X: @trq212. Sitio: thariqs.github.io/html-effectiveness (galería de ejemplos HTML generados por Claude Code, organizada por categoría de uso).
2. Fecha. ~2026-05-10 (artículo reciente, menciona Opus 4.7 con contexto de 1MM, ID snowflake de X ~ mayo 2026). URL: https://x.com/i/status/2052809885763747935.
3. Tesis en una línea. "He empezado a preferir HTML como formato de salida en lugar de Markdown" — el formato de salida por defecto para los artefactos agénticos debería pasar de Markdown a HTML.
4. ¿Por qué ahora?. tres factores convergentes: 1. Los agentes producen specs/planes más largos y ricos que antes. 2. El autor (y quienes lo rodean) ya no edita manualmente estos archivos — le pide a Claude que los edite → la ventaja del "Markdown editable a mano" desaparece. 3. Opus 4.7 + contexto de 1MM absorbe sin dolor los tokens adicionales de HTML.
5. Las 6 razones (por qué HTML). 1. Densidad de información — tablas, CSS, SVG, scripts, canvas, imágenes, posicionamiento absoluto, datos espaciales. "Casi no hay ningún conjunto de información que Claude pueda leer que no puedas representar de forma bastante eficiente con HTML." 2. Claridad visual y facilidad de lectura — pestañas, ilustraciones, enlaces, responsive para móvil. Más allá de 100 líneas de Markdown, nadie vuelve a leerlo. 3. Facilidad para compartir — subida a S3 → enlace directo. "La probabilidad de que alguien realmente lea tu spec es mucho, mucho mayor si está en HTML." 4. Interacción bidireccional — sliders, mandos, botones "copy as prompt" para reinyectar en Claude Code. 5. Ingesta de datos — Claude Code agrega codebase + MCP (Slack, Linear) + historial git + Chrome → un contexto más amplio que ClaudeAI o Claude Design. 6. Es placentero — "me hace sentir más implicado e invertido en la creación, y eso por sí solo ya es suficiente".
6. Antipatrón observado en Markdown. el modelo, privado de expresividad visual, produce diagramas ASCII o aproxima colores con caracteres Unicode (el artículo incluye una captura de pantalla de Claude Code intentando "mostrar un color" en Unicode → una señal absurda de la inadecuación del formato).
7. Referencia retórica. "The Unreasonable Effectiveness of HTML" es un guiño a "The Unreasonable Effectiveness of Mathematics" (Wigner, 1960) y al linaje de títulos "unreasonable effectiveness of X" en ML (Karpathy 2015 sobre RNN).
8. 5 casos de uso canónicos detallados. 1. Specs, planificación y exploración — "una red de archivos HTML": brainstorming de 6 direcciones en una cuadrícula comparativa, expansión de una opción, mockups, fragmentos de código, plan de implementación. Prompt de ejemplo: "Genera 6 enfoques claramente distintos — varía el layout, el tono y la densidad — y colócalos en un único archivo HTML en cuadrícula para poder compararlos lado a lado." 2. Revisión y comprensión de código — adjuntar un explicador HTML a cada PR. Diff renderizado en línea con anotaciones marginales, coloración de código por severidad. Prompt de ejemplo: "Renderiza el diff real con anotaciones en el margen en línea, colorea los hallazgos según su severidad." 3. Diseño y prototipos — el propio Claude Design está basado en HTML. Prototipado de animaciones con sliders y un botón "copy parameters" para exportar los valores ajustados. 4. Informes, investigación y aprendizaje — el autor hizo generar su artículo sobre prompt-caching leyendo el historial git. HTML de formato largo, explicador interactivo, presentación de diapositivas. 5. Interfaces de edición a medida (editores desechables) — un editor desechable de archivo único para un dato concreto, que siempre termina con una exportación (copy as JSON/markdown/prompt) reinyectable en Claude Code. Ejemplos: drag-and-drop de 30 tickets de Linear en columnas Now/Next/Later/Cut, un editor de feature flags con dependencias y advertencias, un prompt-tuner lado a lado con contador de tokens. "No es un producto, ni una herramienta reutilizable, sino un único archivo HTML, diseñado específicamente para este dato concreto."
9. Antipatrón principal hecho explícito. "Me da un poco de miedo que la gente lea este artículo y lo convierta en una skill /html o algo así. Aunque podría haber cierto valor en ello, quiero recalcar que no hace falta hacer gran cosa para que Claude lo haga." → Anti-skill-ificación: la práctica es demasiado dependiente del contexto como para fijarla en una skill; basta con pedir "haz un archivo HTML".
10. FAQ honesta. (concesiones explícitas):
11. Eficiencia de tokens. HTML usa más tokens, pero el contexto de 1MM de Opus 4.7 lo absorbe.
12. Generación. 2-4× más lenta que Markdown — "pero he comprobado que los resultados merecen la pena".
13. Control de versiones. "esto es honestamente uno de los mayores inconvenientes de HTML, los diffs HTML son ruidosos y difíciles de revisar en comparación con Markdown" — un inconveniente sin resolver que el autor reconoce abiertamente.
14. Estilo / evitar la fealdad. usar el plugin de diseño frontend o crear un único design system HTML apuntando a Claude hacia el codebase, y luego referenciarlo para el resto de archivos HTML generados.
15. Metatesis final (in-the-loop). "Había empezado a temer que, al haber dejado de leer los planes en profundidad, simplemente tendría que dejar que Claude tomara sus propias decisiones. Pero me alegra decir, en cambio, que me siento más dentro del bucle que nunca al usar HTML." → HTML como antídoto a la rendición cognitiva (Osmani) / deuda de comprensión: la legibilidad recuperada permite permanecer en el bucle de decisión.
16. Conexiones con el corpus de veille tecnológica.
17. Convergencia directa con design.md de Isenberg × Meng To (2026-05-06): Meng afirma explícitamente que "HTML = plato terminado, archivo MD = receta, skills = ingredientes". Shihipar valida la primacía de HTML para el plato terminado entregado al humano.
18. Respuesta operativa a Osmani — Cognitive Surrender / Comprehension Debt (2026-05-05): Shihipar nombra exactamente el mismo problema ("había dejado de leer los planes en profundidad") y propone HTML como solución para "permanecer en el bucle".
19. Tensión con Lattice / Vincent / Karpathy "skills-maxi": Shihipar adopta la postura opuesta sobre la skill-ificación ("no conviertas esto en una skill /html"). Compromiso: skills para patrones estables, prompting desnudo para prácticas emergentes.
20. Confirmación de Opus 4.7 + contexto de 1MM como un cambio arquitectónico que hace económicamente sostenibles formatos más verbosos (HTML, design systems, brainstormings extensos).
21. Forma parte del linaje Compounding engineering / Cherny: HTML como una nueva capa de salida artefactual entre agente y humano, al mismo nivel que las descripciones de PR, las release notes y los mensajes de commit.
22. Meta-ejemplo. para escribir este artículo, el autor pidió a Claude Code que revisara su carpeta de código, encontrara todos los archivos HTML generados, los agrupara/categorizara, y produjera un archivo HTML con todos los diagramas por tipo → las ilustraciones del propio artículo son un producto del patrón que describe.
23. Flujo de trabajo resultante para la práctica habitual.
24. Cualquier spec, plan o informe > 100 líneas → pasar a HTML.
25. PRs críticos → adjuntar un explicador HTML.
26. Onboarding de archivos, exploraciones de diseño, reordenaciones → editor HTML desechable con exportación estructurada.
27. Mantener Markdown para: mensajes de commit, notas de fiche breves, archivos de configuración .md (CLAUDE.md, agents.md, etc.).