"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 sienten satisfechas solo con el 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 devuelve un informe largo. Lo hojeas y lo dejas sin leer.
- Sospechas que si tú no lees bien los materiales generados por IA, no hay forma de que los miembros de tu equipo los lean.
- Pagas más de 3000 yenes al mes por Claude Code, pero los resultados nunca se han utilizado en una reunión o propuesta.
- Los resultados de ChatGPT y Claude.ai se ven hermosos, pero ¿por qué Claude Code solo genera Markdown, lo que lo hace tan agotador de leer?
Este artículo es para esas personas.
Cuando termines de leer, 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 gran 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 algo de tiempo para probar a generar en HTML.
- Si tienes miembros del equipo que usan Claude Code, comparte esto 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 al usuario en "modo plan" para refinar los requisitos fue una función que él mismo implementó.
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 cambiando 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 la 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 un 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 "IU 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 llegar a tus manos con Claude Code.
Hasta ahora, el texto generado por IA era casi exclusivamente Markdown. La persona que lo construye está empezando a objetar en silencio, diciendo "ya no". 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 se basan todas 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 que acumuló más de 80 000 estrellas en GitHub ocurrió precisamente porque Markdown era el lenguaje común de la industria.
Para usar las palabras de Thariq, Markdown se ha convertido en el formato principal para los agentes. Él es alguien que ha construido herramientas sobre 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 interna eran todas 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 se trata de especificaciones técnicas; se trata de tu experiencia diaria de lunes a viernes. He enumerado los beneficios de HTML del artículo original dándoles la vuelta para mostrar las debilidades de Markdown.
① Si supera las 100 líneas, ni siquiera tú lo leerás
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", es probable que hayas tenido la experiencia de cerrar la respuesta de 120 líneas sin desplazarte. Si la persona que lo generó no lo lee, nadie del 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 un 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 estropea 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 cuadro 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 la lectura
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 en las que 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 dispositivos móviles
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 dispositivos móviles.
Los diseños de Markdown no se adaptan al ancho de la pantalla. Las tablas se desbordan horizontalmente, los bloques de código se envuelven de manera incómoda y las jerarquías de encabezados se vuelven invisibles. Las ganas de leer desaparecen en ese momento.
Pongámosle un nombre. 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 colores, el retraso en la toma de decisiones porque no puedes interactuar y la rotura en dispositivos móviles.
Todos estos son cargos ocultos que se pagan todos los días. En este artículo, llamamos a esto el "Impuesto de Formato".
Este 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 "Generar 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 de Claude Code. Las siguientes tres significan lo mismo:
- "Genera como un archivo HTML"
- "Genera como una página HTML única"
- "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 extraer 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 anteriormente. Los Artifacts que recibiste en ChatGPT o Claude.ai y que pensaste que eran "hermosos" se generaron 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 el uso se solidifique, 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 lo es. 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 la 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 muestra para darle a Claude Code.
[Escenario 1] Entrega de 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 extraer 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 haciendo que Claude Code 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 muestra:
"Lee todas las interacciones de Slack de la semana pasada, los tickets completados 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 cuando se abra en un teléfono inteligente."
[Escenario 2] Mostrar 6 opciones de propuesta/investigación una al lado de la otra
¿Qué dirección debemos 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 tú mismo no las habías comparado completamente.
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 un mundo de diferencia 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 muestra:
"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 alinear 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: Haces que Claude Code 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 únicas 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 intercambio 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 muestra:
"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 juicio 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, te mueves a otra hoja y vuelves. 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 se pasa por alto fácilmente pero que es muy efectivo. Es la frase donde Thariq escribe: "Termina siempre 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: juzgas en HTML, luego devuelves el resultado de texto estructurado a Claude.
Esta misma idea se puede usar para editar feature flags, editores de prompt del sistema lado a lado o aprobación/rechazo/etiquetado de conjuntos de datos. "Crear una IU desechable y dedicada en 3 minutos" es donde se demuestra más claramente el verdadero valor de Claude Code.
▼ Instrucción de muestra:
"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 muestra:
"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 sigas 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 a la mente varias preguntas. 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 3000 yenes al mes para 1000 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 un HTML de muestra de tu sitio web o materiales existentes. Si proporcionas un archivo de referencia y dices "con 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 código base te permite consultarlo 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: "Suaviza un poco este color" o "Haz la tercera sección un poco más pequeña", lo arreglará por ti. Siempre que 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. Simplemente 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 de 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 deseas mantener en el repositorio deben permanecer como Markdown.
CLAUDE.md y SKILL.md son más fáciles de administrar y rastrear diferencias si permanecen como Markdown. HTML es adecuado para "entregar a personas", "dejar que lo toquen", "alinear múltiples opciones" y "dejar que juzguen con color". Si lo entiendes en términos generales como "Markdown para interactuar con la IA, HTML para distribuir a las personas", no te perderás.
Para entonces, tus dudas iniciales deberían estar aclaradas. 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.
Hemos hablado antes del "Impuesto de Prompt": el costo de volver a escribir las mismas premisas en 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, se acumula fatiga tanto para ti como para los demás incluso antes de abrirlos. Pagas más de 3000 yenes al mes por Claude Code, pero los entregables nunca se usan en las reuniones. Esa sensación viene de no tomar una decisión sobre la selección del formato. Esto es el Impuesto de Formato.
Generar la salida en Markdown es una tarea. Elegir HTML es un juicio. Incluso usando el mismo Claude Code, un solo juicio en la selección del 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 lean. 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 cambia el estándar pueden moverse medio paso adelante.
Por supuesto, una vez que te das cuenta de que "hago esto todas las semanas", puedes optar por evolucionarlo a una 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, para 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 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 todos los juicios a Claude. Desde que cambié a HTML, siento que estoy más de vuelta en el bucle 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 devolver un poco de emoción 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: "Genera la salida como un archivo HTML". Convertirlo en una Skill puede esperar hasta que el uso esté consolidado.
- 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 la salida en Markdown es una tarea; elegir HTML es un juicio. La diferencia entre los usuarios de Claude Code se abre aquí.
Para quienes encontraron útil este artículo:
El Laboratorio Claude Code de la Universidad de Tokio (@ClaudeCode_UT) es una cuenta gestionada en serio por un equipo de estudiantes de la UTokyo. También estamos trabajando en desarrollo conjunto de negocio de Claude Code con grandes empresas, y solo compartimos diseños y know-how que realmente funcionan en el campo.
Entregamos información y know-how "verdaderamente útiles" especializados para el trabajo práctico todos los días 👇
■ Publicación gratuita de habilidades de Claude Code utilizables en la práctica
■ Traducción y reestructuración de información primaria de IA del extranjero al contexto empresarial japonés
■ Este es el único lugar para recibir habilidades y herramientas desarrolladas en serio por el equipo de la UTokyo que son "verdaderamente útiles" de forma gratuita ❗️
Si estás interesado, por favor sigue y échanos un vistazo.
LINE está aquí ⇩
