"La escritura de la IA es tan larga que en realidad no la leo bien 😅"
"Estoy pagando más de 15,000 yenes al mes por Claude Code, pero no siento que esté obteniendo el valor de mi dinero."
Muchas personas se conforman con el simple hecho de que están usando IA, pero solo unos pocos realmente la convierten en resultados. Es un estado de "sentir que la has usado".
¿Has tenido estas experiencias con Claude Code?
- Le pides que "resuma las tendencias de la competencia de la semana pasada" el lunes por la mañana, y te devuelve un informe largo. Lo hojeas y lo dejas sin leer.
- Sospechas que si tú no lees bien los materiales generados por IA, seguro que tus compañeros de equipo tampoco los leen.
- Pagas más de 3,000 yenes al mes por Claude Code, pero los resultados nunca se han usado en una reunión o propuesta.
- Los resultados de ChatGPT y Claude.ai se ven hermosos, pero ¿por qué Claude Code solo genera Markdown, haciéndolo tan agotador de leer?
Este artículo es para esas personas.
Cuando termines de leerlo, podrás generar de forma natural materiales desde Claude Code que tanto tú como otros realmente leerán.
También te llevarás la perspectiva de que "en qué formato generas" es un factor mucho más importante en el juicio del usuario que "qué le pides a Claude Code que haga".
Thariq Shihipar (@trq212), un desarrollador de Anthropic que realmente construye Claude Code, escribió sobre una mentalidad que se está extendiendo dentro de la empresa en X, y se ha convertido en una de las publicaciones más guardadas y compartidas en la comunidad de Claude Code.
Recibió una enorme respuesta inmediatamente después de su lanzamiento.
Esto no es solo un consejo menor para los entusiastas de la IA; es una historia sobre la persona que construyó la herramienta desafiando a Markdown, que ha sido el estándar implícito de la industria de la IA, diciendo "ya no es el camino".
Pensé que esto era importante, así que decidí explicarlo en japonés de inmediato.
Dos cosas antes de que empieces a leer:
- Marca esto como favorito. Solo por esta semana, asegúrate un tiempo para probar a generar en HTML.
- Si tienes compañeros de equipo que usan Claude Code, compártelo con ellos. La forma en que se "leen" tus informes semanales y revisiones de PR cambiará visiblemente a partir de la próxima semana.
Voy a desglosar y explicar el contenido mientras lo traduzco a cómo funciona en el entorno empresarial japonés 👇
Publicación original aquí:
https://x.com/trq212/status/2052809885763747935
El propio desarrollador de Anthropic ya no usa Markdown
Este es el punto de partida. Thariq Shihipar (@trq212), quien escribió la publicación original, es el desarrollador que construye Claude Code en Anthropic. El comportamiento donde Claude hace preguntas de vuelta al usuario en "modo plan" para refinar los requisitos fue una función que él mismo implementó.
Él dice que ya no acepta Markdown de la herramienta que está construyendo. En sus propias palabras, Markdown se ha convertido en un formato restrictivo para él.
Esto no es solo una preferencia personal. Thariq menciona que la adopción de HTML se está extendiendo dentro del propio equipo de Claude Code. Las personas que hacen la herramienta están abandonando el Markdown que produce y cambiándose a HTML.
Y la evidencia está disponible para tocarla. En el sitio de demostración https://thariqs.github.io/html-effectiveness/https://thariqs.github.io/html-effectiveness/), hay 20 ejemplos de HTML autocontenidos. Una comparación de tres enfoques para búsqueda con debounce, microinteracciones que crean una sensación de logro al completar tareas, listas de tokens del sistema de diseño, explicaciones con pestañas para ejemplos de código y material de lectura con glosario en los márgenes. Todos estos son ejemplos reales de reemplazar "documentos que solo hojeas" por "documentos que se leen hasta el final". Puedes abrirlos en tu navegador ahora mismo.
Al leer esto, deberías darte cuenta de algo. Los Artifacts que normalmente recibes en ChatGPT o Claude.ai (esa "UI con pestañas", "diagramas de colores" y "botones interactivos") en realidad se generan como HTML. La revelación aquí es: "La razón por la que se veían tan bien era la diferencia en el formato en sí". Ahora, ese mismo mundo puede estar al alcance de tus dedos con Claude Code.
Hasta ahora, el texto generado por IA era casi exclusivamente Markdown. La persona que lo construye está empezando silenciosamente a objetar, diciendo "ya no más". Ese es el núcleo de la noticia. Pero para ti, que trabajas con IA todos los días, esta es una historia que será efectiva desde el lunes por la mañana.
Markdown era el estándar implícito de la industria de la IA
Confirmemos las suposiciones que dábamos por sentadas. Sin esto, el cambio a HTML podría parecer solo una cuestión de gusto.
Hasta ahora, Markdown era el estándar de facto para la salida de IA. Piensa en el texto que ves todos los días:
- CLAUDE.md en la raíz del proyecto, *.md para definiciones de agentes, SKILL.md para Skills.
- La documentación oficial de Anthropic, la Ayuda de Claude.ai y varias guías de Claude Code.
- Herramientas de desarrollo de IA competidoras, reglas de Cursor, instrucciones de GitHub Copilot e instrucciones de Cline, todas basadas en .md.
- Wikis internas, READMEs de GitHub, texto exportado de Notion y actas de reuniones pegadas en Slack.
- Texto de resumen copiado de chats de ChatGPT.
Todo se ha construido bajo la suposición de Markdown. Es más difícil encontrar un formato que no sea Markdown en la información textual que encuentras al tratar con IA.
El fenómeno del patrón CLAUDE.md de Karpathy acumulando más de 80,000 estrellas en GitHub ocurrió precisamente porque Markdown era el lenguaje común de la industria.
Usando las palabras de Thariq, Markdown se ha convertido en el formato principal para los agentes. Él es alguien que ha construido herramientas bajo la premisa de Markdown durante mucho tiempo.
Esa persona ahora ha declarado claramente: Markdown se ha convertido en un formato restrictivo para mí. Este es el momento en que un insider de Anthropic lanzó una piedra contra la premisa en la que toda la industria ha estado montada.
En pocas palabras: el Markdown que obtienes de Claude Code, las reglas que lee Cursor y las salidas de IA en tu Wiki interno eran todos parte del mismo flujo de "Markdown está bien". La persona que lo creó ha comenzado a dibujar un canal diferente.
A partir de aquí, entraremos en los detalles de por qué Markdown no llega a las personas y con qué reemplazarlo.
5 razones por las que Markdown no se lee
Organicemos las limitaciones de Markdown. Esto no es sobre especificaciones técnicas; es sobre tu experiencia diaria de lunes a viernes. He enumerado los beneficios de HTML del artículo original invirtiéndolos para mostrar las debilidades de Markdown.
① Si supera las 100 líneas, ni siquiera tú lo lees
El propio Thariq escribe que cuando un archivo Markdown supera las 100 líneas, deja de leerlo.
Cuando le pides a Claude Code que "resuma las tendencias de la competencia de la semana pasada", probablemente hayas tenido la experiencia de cerrar la respuesta de 120 líneas sin desplazarte. Si la persona que lo generó no lo lee, nadie en el equipo lo hará. La realidad es que no solo el autor, sino también otros miembros de la organización, solo están hojeando.
② Incluso si se comparte, no se abre bien en el navegador, así que nadie lo toca
Markdown no se renderiza de forma nativa y atractiva en los navegadores. Los saltos de línea se rompen en Slack, el formato se arruina en los correos electrónicos y requiere esfuerzo convertirlo a PDF o tomar capturas de pantalla para propuestas.
Cada vez que compartes, alguien tiene que hacer el trabajo de convertirlo a una "forma legible". Markdown es un formato que crea fricción cada vez que se comparte, hasta el punto de que a menudo ni siquiera se hace clic en los enlaces.
③ Sin colores ni diagramas, solo se transmite el esquema
Quieres enfatizar una diferencia en números, mostrar una advertencia en rojo o mostrar un flujo con flechas. Para hacer esto en Markdown, terminas dibujando diagramas con caracteres ASCII o expresando colores con caracteres de caja Unicode.
Nadie quiere descifrar eso, y el escritor se cansa. Incluso si Claude se esfuerza por dibujar un diagrama, termina siendo hojeado.
④ No puedes tocarlo ni moverlo, así que termina solo con leerlo
Quieres probar un color un poco más suave, probar la velocidad de una animación o ver cómo se ve si aumentas un valor 1.5 veces.
En los negocios, hay situaciones frecuentes donde necesitas "probarlo" para tomar una decisión. No puedes hacer eso con Markdown. Lo lees, lo simulas en tu cabeza y luego envías instrucciones en texto: un bucle ineficiente.
⑤ Se rompe cuando se abre en el móvil
Slack, correo electrónico o Notion sobre la marcha. En el entorno empresarial japonés, la mitad de los materiales compartidos se abren por primera vez en el móvil.
Los diseños de Markdown no siguen el ancho de la pantalla. Las tablas se desbordan horizontalmente, los bloques de código se envuelven de forma extraña y las jerarquías de encabezados se vuelven invisibles. El deseo de leer desaparece en ese momento.
Pongámosle un nombre a esto. Cada vez que produces Markdown no leído, se acumula fatiga tanto para el remitente como para el receptor incluso antes de abrirlo. El costo de desplazarse 100 líneas, arreglar saltos de línea en Slack, la falta de comunicación debido a la ausencia de diagramas y color, el retraso en la toma de decisiones porque no se puede interactuar y la rotura en el móvil.
Todos estos son costos ocultos que se pagan todos los días. En este artículo, llamamos a esto el "Impuesto de Formato".
Esto no es un impuesto pequeño. Más de la mitad del valor de Claude Code está determinado no por el contenido de la salida, sino por "a quién llega y hasta dónde". Al generar en un formato que no llega a las personas, básicamente estás tirando la mitad de tu suscripción.
Cómo cambiar: solo agrega "Genera como un archivo HTML"
No necesitas pensar demasiado en esto. Hay mucho menos que hacer de lo que crees.
Solo agrega una línea al final de tu solicitud habitual a Claude Code. Las siguientes tres significan lo mismo:
- "Genera como un archivo HTML"
- "Genera como un HTML de una sola página"
- "Hazlo HTML para que el lector pueda abrirlo directamente"
Si te sientes más cómodo escribiendo en inglés, "make a HTML file" o "make a HTML artifact" está bien. El resultado es el mismo.
Claude Code puede obtener contexto de MCP, navegadores, git y el sistema de archivos. La fortaleza de Claude Code es que puede agrupar fuentes de información mucho más amplias en un solo HTML que las versiones de chat web de ChatGPT o Claude.ai.
Esto se conecta con lo que discutimos antes. Los Artifacts que recibías en ChatGPT o Claude.ai y que pensabas que eran "hermosos" se generaban como HTML.
Ahora puedes recibir ese mismo mundo en el lado de Claude Code. No es una historia técnica difícil; al cambiar una línea en cómo preguntas, saldrán materiales que realmente llegan a las personas.
Thariq enfatiza un punto en su artículo: "No quiero que esto se convierta en un Skill de /html todavía; quiero que la gente se acostumbre primero a través de los prompts". Esto a pesar de que él es un desarrollador del equipo de Claude Code que produce Skills.
No está descartando convertirlo en un Skill. Está diciendo: "Si lo empaquetas antes de que se solidifique el uso, te perderás las partes que son realmente efectivas".
Dentro de Anthropic, las salidas HTML que se han vuelto frecuentes están comenzando a ser componentizadas en cosas como plugins de Playground. En lugar de esperar un producto terminado desde el principio, pruébalo primero con un prompt de una línea para encontrar el patrón que se ajuste a tu trabajo. Solo después de llegar a ese punto debes pasar a convertirlo en un Skill.
Escribir "genera en HTML" en cada prompt puede parecer una tarea, pero elegir el formato en sí no es una tarea. En el momento en que cambias de que Claude genere Markdown a que Claude genere HTML, has dado medio paso hacia ser quien "diseña la salida antes de esperar un Skill predefinido".
5 escenarios empresariales que cambian solo con cambiar a HTML
Este capítulo es efectivo para el trabajo real de lunes a viernes. He reordenado los cinco casos de uso del artículo original en orden de frecuencia en el entorno empresarial japonés: Informes Semanales/Resúmenes de Investigación, Comparación Paralela de Propuestas, Ajustes de Diseño, Pantallas de Edición para Toma de Decisiones y Revisiones de PR/Especificaciones.
Cada escenario se resume con el problema actual, Antes/Después y, finalmente, una instrucción de ejemplo para darle a Claude Code.
[Escenario 1] Entregar informes semanales y resúmenes de investigación con diagramas
Algo común en los negocios japoneses. El lunes por la mañana, tu jefe te pide: "Resume las tendencias de la semana pasada".
Antes: Pegas 120 líneas de Markdown en Slack. Los saltos de línea se rompen. Tu jefe no lo abre. No se incluye en los materiales de la reunión de dirección. Terminas explicándolo verbalmente, diciendo: "Se lo pedí a Claude".
Después: Lo resumes en una sola página HTML que incorpora registros de Slack, historial de tickets de Linear o Notion, registros de git y documentos internos. Incluyes un diagrama de flujo empresarial simple usando SVG y colocas tres puntos clave en bloques de colores al final.
Si pones esto en el almacenamiento interno y compartes la URL, tu jefe puede abrirlo en su teléfono mientras viaja, la dirección puede citarlo y se puede pegar en las actas de la reunión.
La clave aquí es que Claude Code puede obtener contexto de MCP, navegadores, git y el sistema de archivos. Incluso si le pides a un chat web que "haga un HTML", es difícil agrupar tantas fuentes de información en uno. Este es un informe semanal que solo Claude Code puede crear.
El propio Thariq escribió que hizo los diagramas para sus artículos pidiéndole a Claude Code que leyera todo el HTML en su carpeta de código y los resumiera en una página. Un "informe semanal que se lee" y un "diagrama para un artículo explicativo que se lee" son estructuralmente lo mismo.
▼ Instrucción de ejemplo:
"Lee todas las interacciones de Slack de la semana pasada, las finalizaciones de tickets de Linear y los registros de git, y genera un informe semanal como una sola página HTML que mi jefe pueda entender en 1 minuto. Incluye un diagrama de flujo empresarial simple en SVG y tres puntos clave en bloques de colores al final. Asegúrate de que no se rompa al abrirlo en un teléfono inteligente."
[Escenario 2] Mostrar 6 opciones de propuesta/investigación una al lado de la otra
¿Qué dirección tomar para la propuesta de la próxima semana? Una escena común en planificación, ventas y planificación corporativa donde se crean múltiples opciones y se alinean con los tomadores de decisiones.
Antes: Envías seis opciones en seis archivos Markdown separados. El cliente no puede abrirlos y compararlos uno por uno. Preguntan: "¿Cuál es tu principal recomendación?" y te das cuenta de que no las habías comparado completamente tú mismo.
Después: Organizas seis opciones con diferentes tonos, densidades y públicos objetivo en una cuadrícula en una sola página HTML. Agregas una línea de compensación debajo de cada opción. El tomador de decisiones las compara todas en una pantalla y responde de inmediato: "Quiero mezclar esta y esta" o "Usa el objetivo de la #3 con la densidad de la #1". La resolución de la discusión cambia en el momento en que las muestras en paralelo.
Para un tomador de decisiones, el tiempo que lleva juzgar es mundos diferentes entre recibir seis archivos y tener seis opciones alineadas en una pantalla. Se trata menos de "hacer que lo lean" y más de "permitirles tomar una decisión".
▼ Instrucción de ejemplo:
"Crea 6 opciones de propuesta para la presentación de la próxima semana con diferentes tonos, densidades y públicos objetivo, y organízalas en una cuadrícula en una sola página HTML. Escribe una línea de compensación debajo de cada opción. Además, agrega un botón al final para copiar el resultado como Markdown una vez que se tome una decisión."
[Escenario 3] Decidir diseños y prototipos tocándolos
Al decidir colores, tamaños o movimientos, debes rendirte a alinearlos a través del texto. Esta es una escena donde marketing, relaciones públicas y planificación van y vienen muchas veces sobre correos electrónicos de agradecimiento o botones de páginas de aterrizaje.
Antes: Te comunicas con palabras como "un azul un poco más suave" o "haz que el movimiento sea esponjoso". La imagen del receptor se desvía cada vez. Al mirar la versión que regresó después de una ronda, agregas más palabras: "No, no ese tipo de suavidad".
Después: Le pides a Claude Code que cree un HTML donde puedas mover controles deslizantes para el color y la velocidad de la animación. Creas prototipos para botones de correo electrónico de agradecimiento o botones de CTA de LP como páginas HTML individuales y envías la URL a las partes interesadas. Todos lo tocan, deciden los mejores valores y simplemente copian esos valores de vuelta a Claude. El ir y venir de texto disminuye y el tiempo para llegar a un acuerdo se acorta.
Relacionado con esto, Anthropic Labs está comenzando a formalizar este concepto de "tocar para decidir y copiar la operación de vuelta a Claude" como un plugin de Playground. La salida HTML no es solo un pequeño truco; es una dirección que la propia Anthropic está cultivando como patrón.
▼ Instrucción de ejemplo:
"Crea un HTML donde pueda decidir el color y la velocidad de animación del botón en el correo electrónico de agradecimiento usando tres tipos de controles deslizantes. Agrega un botón al final para copiar los valores decididos."
[Escenario 4] Hacer una pantalla de decisión en 3 minutos
¿Qué medidas deben asignarse a Ahora, Siguiente, Después o Eliminar para el próximo trimestre? Clasificar 30 tickets para decidir prioridades es una "tarea de juicio" típica para PdMs, planificadores y planificación corporativa.
Antes: Alineas 30 elementos en una hoja de cálculo y llenas manualmente la columna de prioridad uno por uno. Ordenas, reconsideras, mueves a otra hoja y vuelves a mover. Algunos días pasas 30 minutos y aún no tienes una conclusión.
Después: Le pides a Claude Code que "haga un HTML donde pueda arrastrar y soltar elementos en cuatro columnas: Ahora, Siguiente, Después y Eliminar". Una pantalla de edición dedicada está lista en 3 minutos. Arrastras las 30 tarjetas y, cuando terminas, copias los resultados. El tiempo para las tareas de juicio se reduce en un orden de magnitud.
Hay un principio de diseño aquí que es fácil de pasar por alto pero altamente efectivo. Es la frase donde Thariq escribe: "Siempre termina con una exportación". Al hacer una pantalla de edición, incluye siempre botones para "Copiar como JSON", "Copiar como Prompt" o "Copiar como Markdown".
Sin esto, no puedes devolver los resultados de tu clasificación a Claude, y termina siendo solo una herramienta de tareas. Una pantalla de edición se convierte en un dispositivo de juicio solo cuando creas un bucle: juzgar en HTML, luego devolver el resultado de texto estructurado a Claude.
Esta misma idea se puede usar para editar banderas de funciones, editores de prompts del sistema lado a lado o aprobar/rechazar/etiquetar conjuntos de datos. "Crear una UI dedicada y desechable en 3 minutos" es donde el verdadero valor de Claude Code se demuestra más claramente.
▼ Instrucción de ejemplo:
"Crea un HTML donde pueda arrastrar y soltar 30 medidas para el próximo trimestre en cuatro columnas: Ahora, Siguiente, Después y Eliminar. Al final, coloca un botón 'Copiar como Markdown' para que pueda generar los resultados de la clasificación con razones para cada línea."
[Escenario 5] Entregar revisiones de PR y compartir especificaciones con diferencias codificadas por colores
Finalmente, una escena para colaborar con ingenieros. Incluso si no lees código, como PdM, director o editor, es posible que te llamen para revisiones de PR o confirmaciones de especificaciones.
Antes: Te piden que abras la pantalla de diferencias de GitHub. No puedes distinguir qué parte de la diferencia es importante y cuál se puede ignorar solo con mirarla. Tienes que leer los comentarios para seguir la historia. Las personas que no leen código a menudo solo dicen "avísame si hay algo" y lo cierran.
Después: Le pides a Claude Code que "convierta este PR en un documento de revisión HTML que alguien que no lee código pueda entender en 30 segundos". Los comentarios se adjuntan junto a las diferencias, el alcance del impacto se codifica por colores y se proporciona un resumen de tres preocupaciones al final. Si subes esto al almacenamiento interno y compartes la URL, los PdMs y directores pueden proporcionar comentarios con un botón. Aquellos que colaboran con ingenieros finalmente pueden participar en las revisiones.
HTML no es un lenguaje para ingenieros; es una herramienta para entregar una historia. El significado de la diferencia, los riesgos y el alcance del impacto: esta "información que requiere descifrado" se entrega con anotaciones, color y diseño. Ese es el significado de la conversión a HTML.
▼ Instrucción de ejemplo:
"Convierte este PR en un documento de revisión HTML que alguien que no lee código pueda entender en 30 segundos. Adjunta comentarios junto a las diferencias, muestra el alcance del impacto con codificación de colores y resume tres preocupaciones al final."
Mientras continúes generando en Markdown para estos cinco escenarios, el impuesto de formato se acumula silenciosamente pero a diario. Si lo detienes en el momento en que te das cuenta será la diferencia a partir de la próxima semana.
6 preguntas que surgen al cambiar
Al leer esto, seguramente te vienen varias preguntas a la mente. He reordenado la sección de preguntas frecuentes del artículo original en el orden en que es probable que los lectores empresariales japoneses las encuentren.
■ ¿Usa más tokens?
Sí, los usa. El artículo original indica que tarda de 2 a 4 veces más en generarse que Markdown. Sin embargo, Opus 4.7 tiene un contexto de 1 millón de tokens, por lo que el riesgo de que las conversaciones se rompan debido a los límites de contexto al devolver HTML es prácticamente inexistente.
La conclusión de Thariq es: "Los números aumentan, pero si eliges el resultado que se lee, vale la pena para el trabajo total". Es una elección entre usar tu contrato de más de 3,000 yenes al mes para 1,000 líneas de Markdown no leído o una página de HTML que se abre.
■ ¿El diseño no será feo?
Esta es una preocupación válida, pero hay contramedidas.
Una es usar los plugins de diseño frontend de Claude Code. Otra es proporcionarle a Claude una muestra HTML del sitio de tu empresa o de materiales existentes. Si proporcionas un archivo de referencia y dices "en este tono" o "con esta fuente y paleta", Claude generará HTML que coincida con la apariencia de tu empresa. Mantener un archivo como design-system.html en tu base de código te permite referenciarlo cada vez.
■ ¿No es una molestia editar HTML?
No necesitas editarlo tú mismo.
El propio Thariq escribe que no toca directamente el HTML. Si le dices a Claude: "Calma un poco este color" o "Haz la tercera sección un poco más pequeña", lo arreglará por ti. Mientras lo uses para especificaciones, lluvia de ideas o materiales de referencia, puedes dejar toda la edición a Claude.
■ ¿Cómo lo abro? ¿Cómo lo comparto?
Abrirlo es fácil. Solo abre el archivo HTML que Claude Code produjo localmente en tu navegador.
Incluso puedes pedirle a Claude que "abra este archivo", y podría abrirlo en tu navegador por ti. Al compartir, la forma más fácil es subirlo al almacenamiento interno o a S3 y proporcionar la URL. Si pegas el enlace en Slack o correo electrónico, el destinatario puede abrirlo en su navegador. Ese paso adicional de convertir Markdown a PDF desaparece por completo.
■ ¿Qué pasa con el control de versiones?
Para ser honesto, HTML no es muy adecuado para la gestión de diferencias en Git. Arreglar una línea podría mover diferencias a otro lugar debido a la configuración del formateador. El propio Thariq escribe que HTML es la mayor debilidad del control de versiones.
Por eso, la solución práctica es: "Los entregables para personas" son HTML, y "las especificaciones o registros de los que quieres mantener un historial" son Markdown. No se trata de abolir Markdown, sino de cambiar a una mentalidad de elegir el formato según el propósito de la salida.
■ ¿Puedo dejar de usar Markdown por completo?
No. Los registros, los historiales de cambios y el texto estructurado que quieras mantener en el repositorio deben seguir siendo Markdown.
CLAUDE.md y SKILL.md son más fáciles de gestionar y rastrear diferencias si se mantienen como Markdown. HTML es adecuado para "entregar a personas", "dejar que la gente lo toque", "alinear múltiples opciones" y "dejar que la gente juzgue con color". Si lo entiendes en términos generales como "Markdown para interactuar con IA, HTML para distribuir a personas", no te perderás.
A estas alturas, tus dudas iniciales deberían estar resueltas. Un artículo que incluye desventajas es más confiable: esa es mi creencia como escritor.
¿Seguirás pagando el impuesto de formato o te pasarás al lado del diseño?
Finalmente, elevemos nuestra perspectiva para cerrar.
Anteriormente hemos hablado del "Impuesto de Prompt"—el costo de volver a escribir las mismas premisas a Claude. Luego, la historia de pasar a la capa de diseño con la carpeta .claude. Este "Impuesto de Formato" es el tercer tema de esa serie. Después de la capa de conversación y la capa de diseño, ahora hemos abordado la capa de salida.
Definamos "Impuesto de Formato" como algo que podemos compartir con los lectores:
Si sigues eligiendo formatos de salida que no se leen, la fatiga se acumula tanto para ti como para los demás incluso antes de abrirlos. Pagas más de 3,000 yenes al mes por Claude Code, pero los entregables nunca se usan en las reuniones. Ese sentimiento viene de no hacer un juicio en la selección de formato. Este es el Impuesto de Formato.
Generar en Markdown es una tarea. Elegir HTML es un juicio. Incluso usando el mismo Claude Code, un solo juicio en la selección de formato cambia significativamente la distancia que alcanzan tus entregables.
Y HTML no es un lenguaje para ingenieros. Es una herramienta para crear materiales que se leen. Deja de lado la idea de construir un sitio web por un momento. Solo intenta generar el informe semanal, la propuesta o el documento de revisión que estás escribiendo esta semana en HTML. Eso es suficiente.
Hablemos del panorama general.
La era en la que Markdown era el estándar implícito de la industria de la IA está terminando silenciosamente dentro de Anthropic. Mientras que CLAUDE.md, SKILL.md y las reglas de Cursor se construyeron sobre una premisa de Markdown, el formato de salida está empezando a cambiar primero. Los lectores que presencian el momento en que el estándar cambia pueden moverse medio paso adelante.
Por supuesto, una vez que te das cuenta de que "hago esto cada semana", puedes optar por evolucionarlo a un Skill.
Dentro de Anthropic, los patrones con alta frecuencia para salida HTML, como los Playgrounds relacionados con diseño, se están cultivando gradualmente como componentes. Sin embargo, durante la primera semana, un prompt de una línea es suficiente. Esta noche, intenta generar solo un informe semanal en HTML. La próxima semana, intenta alinear seis opciones de propuesta en una sola cuadrícula. Empieza por ahí, y el impuesto de formato comenzará a disminuir silenciosamente.
El propio Thariq escribe al final de su artículo: "Tenía miedo de dejar de leer en profundidad Markdown y dejar los juicios completamente a Claude. Desde que cambié a HTML, siento que estoy más involucrado con Claude y, sobre todo, es simplemente divertido crear".
Elegir un formato es un interruptor para recuperar la iniciativa al trabajar con IA, y al mismo tiempo, un interruptor para traer un poco de emoción de vuelta a tu trabajo diario.
¿Seguirás produciendo Markdown que no se lee, o te pasarás al lado que elige el formato? La próxima semana será el límite.
Resumen
- El desarrollador que construye Claude Code en Anthropic declaró que ya no usa Markdown. La adopción de HTML se está extendiendo dentro del equipo interno.
- Hasta ahora, Markdown era el estándar implícito para la IA—desde Claude Code y Cursor hasta GitHub Copilot, Cline, wikis internas y salidas de ChatGPT. El creador ahora ha desafiado ese estándar de la industria.
- Hay 5 razones por las que Markdown no se lee: no se puede releer con 100 líneas / se rompe al compartir / sin color ni diagramas / no se puede tocar para juzgar / se rompe en móvil. Estos costos ocultos son el "Impuesto de Formato".
- Para cambiar, solo agrega una línea: "Generar como archivo HTML". Convertirlo en un Skill puede esperar hasta que el uso se consolide.
- 5 escenarios de negocio—informes semanales, propuestas paralelas, ajustes de diseño, pantallas de juicio y revisiones de PR—se transforman en materiales que se abren, juzgan y devuelven solo con cambiar a HTML.
- Elegir un formato es un juicio, no una tarea. Generar en Markdown es una tarea; elegir HTML es un juicio. La diferencia entre los usuarios de Claude Code se abre aquí.
Para aquellos que encontraron útil este artículo:
El Laboratorio Claude Code de la Universidad de Tokio (@ClaudeCode_UT) es una cuenta gestionada seriamente por un equipo de estudiantes de la UTokyo. También estamos trabajando en desarrollo conjunto de negocios de Claude Code con grandes empresas, y solo compartimos diseños y conocimientos que realmente funcionan en el campo.
Entregamos información y conocimientos "genuinamente útiles" especializados para el trabajo práctico todos los días 👇
■ Lanzamiento gratuito de skills de Claude Code utilizables en la práctica
■ Traducción y reestructuración de información primaria de IA del extranjero a un contexto de negocio japonés
■ Este es el único lugar para recibir skills y herramientas desarrolladas seriamente por el equipo de la UTokyo que son "genuinamente útiles" de forma gratuita ❗️
Si estás interesado, por favor síguenos y échanos un vistazo.
LINE está aquí ⇩
