A eficácia irracional do HTML: o Claude Code deixa o Markdown

O Markdown ficou apertado

O Markdown tem muitas qualidades: é simples, funciona em qualquer lugar, aceita um pouco de texto formatado e é fácil de editar à mão. O Claude até ficou surpreendentemente bom em desenhar diagramas com caracteres ASCII dentro de um arquivo Markdown.

Mas os agentes estão cada vez mais poderosos, e o Thariq sente que o Markdown ficou apertado. Ele tem dificuldade de ler um arquivo com mais de cem linhas. Quer visualizações mais ricas, com cor e diagramas, e quer poder compartilhá-las com facilidade.

Além disso, ele edita esses arquivos cada vez menos. Usa como especificações, como documentos de referência ou como resultado de um brainstorm, e quando é preciso mudar algo, pede ao Claude. Então uma das grandes vantagens do Markdown, ser fácil de editar à mão, quase não serve mais para ele. Por isso ele passou a preferir o HTML como formato de saída.

Densidade de informação

O Thariq dá seis motivos, e o primeiro é a densidade de informação. O HTML consegue dizer muito mais do que o Markdown: faz o básico, como títulos e formatação, mas também consegue representar muitos outros tipos de informação:

Ele chega a dizer que quase não existe informação que o Claude consiga ler e que não dê para representar em HTML de forma bastante eficiente. Por isso é um jeito muito eficaz de o modelo te explicar algo a fundo, e de você revisar.

Quando não pode usá-lo, o modelo recorre a truques pouco eficientes em Markdown, como os diagramas em ASCII. Ou o favorito dele: aproximar cores com caracteres unicode. Numa captura do artigo, o Claude Code tenta mostrar uma paleta de cores com blocos de pontinhos cinza.

Clareza e facilidade para compartilhar

O segundo motivo é a clareza visual. O Claude faz trabalhos cada vez mais complexos, então escreve especificações e planos cada vez mais longos. O Thariq admite que, na prática, não lê mais do que cem linhas de Markdown, e com certeza não consegue que mais ninguém na empresa dele leia.

Já um documento em HTML é muito mais fácil de ler. O Claude pode organizá-lo para você navegar com abas, ilustrações e links, e pode adaptá-lo ao celular, para você ler de um jeito diferente conforme a tela. É o mesmo conteúdo, mas pensado para ler, não para rolar a tela.

O terceiro: é fácil de compartilhar. Um arquivo Markdown é difícil de compartilhar, porque a maioria dos navegadores não o mostra bem, e você acaba mandando como anexo num email ou numa mensagem. Com HTML, basta subir o arquivo (por exemplo, no S3 da Amazon) e compartilhar o link. Seus colegas abrem onde quiserem e consultam quando precisarem.

E, segundo o Thariq, a chance de alguém realmente ler a sua especificação, o seu relatório ou a descrição do seu pull request é muito, muito maior se estiver em HTML.

Interação, contexto e diversão

O quarto motivo é a interação nos dois sentidos. Você pode pedir ao Claude controles deslizantes e botões giratórios para ajustar um design, ou para mudar as opções de um algoritmo e ver o que acontece. E um botão que copia as suas mudanças como prompt, para colar de volta no Claude Code. É a mesma ideia dos "playgrounds" dele.

O quinto é o contexto. Por que fazer esses arquivos com o Claude Code e não no site do Claude, ou com o Claude Design? Porque o Claude Code consegue ler muito contexto: seus arquivos, seus servidores MCP (como o Slack ou o Linear), seu navegador com o Claude in Chrome e o seu histórico do git.

Um exemplo: para escrever o artigo, o Thariq pediu ao Claude Code que procurasse na pasta de código dele todos os arquivos HTML que ele tinha gerado, que os agrupasse por tipo e que fizesse um HTML com um diagrama de cada tipo. Os diagramas do artigo saíram daí.

E o sexto: é divertido. Fazer documentos em HTML com o Claude é mais gostoso, e o Thariq se sente mais envolvido no que cria. Ele diz que só isso já vale a pena.

Como começar

O Thariq tem medo de que as pessoas leiam o artigo e o transformem numa skill /html ou algo do tipo. Pode ter seu valor, mas ele insiste que quase não é preciso fazer nada. Basta pedir ao Claude: "faça um arquivo HTML" ou "faça um artefato HTML".

O segredo é saber o que você quer que esse arquivo faça e como vai usá-lo. Com o tempo, talvez você acabe criando uma skill, mas por enquanto ele recomenda pedir do zero toda vez, para aprender a tirar proveito em cada caso.

Quatro famílias de usos

O Thariq fez muitos arquivos HTML para usos diferentes e juntou todos numa galeria. Ele os agrupa em quatro famílias.

1. Especificações, planejamento e exploração

Quando começa um problema, em vez de um plano simples em Markdown, ele espera terminar com uma rede de arquivos HTML. Primeiro pede ao Claude Code um brainstorm com várias opções diferentes. Depois, que aprofunde uma delas, talvez com protótipos de tela ou trechos de código. Quando a ideia fica clara, pede um plano de implementação com protótipos, o fluxo de dados e o código importante.

Se o plano o convence, abre uma sessão nova e passa todos esses arquivos para ela implementar. E na verificação, o agente que confere o trabalho também os lê, então entende muito melhor o que é preciso. Um prompt de exemplo:

Não sei que direção dar para a tela de boas-vindas. Gere seis abordagens bem diferentes (varie o layout, o tom e a densidade) e coloque numa grade, num único HTML, para eu comparar. Marque em cada uma o que ela sacrifica.

2. Revisar e entender código

Em Markdown, o código é difícil de ler. Em HTML dá para mostrar as mudanças com anotações, diagramas de fluxo ou módulos. Serve para entender o que o agente escreveu, para pedir uma revisão ou para explicar o seu pull request a quem vai revisá-lo. Para o Thariq, isso muitas vezes funciona melhor do que a tela de mudanças do GitHub, e ele já anexa um explicador em HTML a cada pull request que faz. O prompt dele:

Me ajude a revisar este PR com um artefato HTML que o descreva. Mostre o diff real com anotações na margem e pinte os achados conforme a gravidade.

3. Design e protótipos

O Claude Design é baseado em HTML porque ele é incrivelmente expressivo para design, mesmo que o produto final não seja um site. O Claude pode esboçar o design em HTML e depois escrevê-lo na linguagem que você usa, seja React ou Swift. Você também pode prototipar interações:

Quero um botão de pagamento novo que, ao ser clicado, faça uma animação e fique roxo. Faça um HTML com controles deslizantes para testar opções e um botão para copiar os parâmetros que funcionarem.

Serve para documentar o seu design system (cores, fontes e espaçamentos), para ajustar componentes, para ver uma biblioteca de componentes de relance ou para prototipar animações caprichadas.

4. Relatórios, pesquisa e aprendizado

O Claude Code é muito bom em juntar informação de várias fontes e transformá-la num relatório fácil de ler. Ele pode buscar no seu Slack, no seu código, no histórico do git ou na internet, e preparar relatórios para você, para os seus chefes ou para a sua equipe. Pode ser um documento longo, um explicador interativo ou até uma apresentação, com diagramas em SVG.

Para os artigos dele sobre o cache de prompts, o Thariq pediu que ele lesse o histórico do git e preparasse um relatório completo, em HTML, com todas as mudanças da equipe. Outro prompt de exemplo:

Não entendo como funciona o nosso limitador de requisições. Leia o código e faça uma única página que o explique: um diagrama do fluxo, os trechos principais comentados e uma seção de armadilhas no final.

Editores sob medida

Tem coisas que são difíceis de descrever só com texto. Nesses casos, o Thariq pede ao Claude um editor descartável, feito para o que ele tem em mãos. Não é um produto nem uma ferramenta reutilizável: é um único arquivo HTML, pensado para aquele dado específico.

O segredo é sempre terminar com uma exportação: um botão de "copiar como JSON" ou de "copiar como prompt" que transforma o que você fez na interface em algo que dá para colar no Claude Code. Os três exemplos dele:

• Repriorizar trinta tickets do Linear. Cada ticket é um cartão que se arrasta entre quatro colunas (agora, em seguida, mais tarde e fora). O Claude os posiciona primeiro do jeito que acha melhor, e um botão exporta a ordem final com uma frase que justifica cada coluna.
• Editar as feature flags. Um formulário que as agrupa por área, mostra as dependências entre elas e avisa se você liga uma cujo requisito está desligado. Um botão de "copiar diferenças" entrega só as chaves que mudaram.
• Refinar um prompt de sistema. À esquerda, o prompt editável com as variáveis destacadas; à direita, três exemplos que são preenchidos ao vivo; embaixo, um contador de tokens e um botão de copiar.

Serve para ordenar ou classificar qualquer coisa, para editar uma configuração com regras, para refinar prompts vendo o resultado, para curar dados ou anotar documentos, e para escolher valores difíceis de expressar em palavras: uma cor, uma curva de animação, um recorte ou uma expressão regular.

As dúvidas de sempre

O Thariq ouviu várias perguntas repetidas vezes:

• Não gasta mais tokens? Sim, o Markdown costuma gastar menos. Mas o HTML expressa muito mais, e é muito mais provável que ele leia; então, no geral, o resultado é melhor. E com a janela de um milhão de tokens do Claude Opus, o gasto extra quase não se nota.
• Quando ele ainda usa Markdown? Quase nunca: abandonou para quase tudo, embora admita que é um maximalista do HTML.
• Como ele abre os arquivos? No navegador, localmente, ou pedindo ao Claude que os abra. Se quer compartilhar, sobe para o S3.
• Não demora mais? Sim: o HTML pode demorar de duas a quatro vezes mais que o Markdown, mas para ele compensa.
• E o controle de versão? É uma das maiores desvantagens: as diferenças entre duas versões de um HTML têm muito ruído e são mais difíceis de revisar.
• E se ficar feio? O plugin frontend-design ajuda o Claude a fazer bons HTML. Para seguir o estilo da sua empresa, peça um único arquivo com o seu design system, tirado do seu código, e use como referência para todos os outros.

Dentro do loop

No fim, o Thariq acha que o verdadeiro motivo de ele usar HTML é que ele se sente muito mais dentro do loop com o Claude. Como tinha parado de ler os planos a fundo, ele temia que não teria outra saída a não ser deixar o Claude tomar as próprias decisões. Ele fica feliz em dizer que aconteceu o contrário: com o HTML, ele se sente mais dentro do loop do que nunca.

Seus agentes ainda escrevem para você em Markdown?

Fontes

• "Using Claude Code: The Unreasonable Effectiveness of HTML", do Thariq (@trq212), maio de 2026. Também no blog do Claude.
• A galeria de exemplos: thariqs.github.io/html-effectiveness.
• O vídeo, nos meus três canais: português, espanhol e inglês.