começou assim, no whatsapp, no meio de uma conversa sobre outras coisas:
paulo: vc devia ter um blog, se eh q ja nao tem
vinny: eu tenho, a newsletter no linkedin (recente, focada em claude code) e o medium, que é mais blog mesmo
paulo: nenhum deles eh blog.
paulo: kkkk
e não tá errado.
newsletter e medium são canais de distribuição ótimos, cada um com seu propósito. mas blog próprio é outra categoria. dono do domínio, dono do conteúdo, dono do feed. lugar pra pensar em voz alta sem o paywall do medium espreitando por cima do meu ombro e sem o algoritmo do linkedin decidindo se um post sobre context window merece ser visto hoje.
então é isso. primeiro post. e o dilema da página em branco: sobre o que escrever primeiro?
o que esse post não é
não é sobre claude code. não é sobre skills, harness, agentes, mcp, context engineering, spec-driven development, ou qualquer uma das dez coisas brilhantes que apareceram essa semana no feed. não é sobre as ferramentas que tão no meu workflow agora, mesmo sendo disso que eu mais tenho escrito na newsletter.
esse post é sobre uma coisa que está antes de tudo isso. uma coisa que eu uso todo dia e que provavelmente você também usa sem pensar. o formato em que essa publicação está sendo escrita neste momento.
15 de março de 2004
naquele dia, no blog daring fireball, um cara chamado john gruber publicou um post curto chamado “introducing markdown”. junto, liberou um script em perl de pouco mais de mil linhas. a especificação da linguagem cabia numa página. o objetivo era modesto: um jeito de escrever texto que fosse legível como texto puro e que pudesse ser convertido pra html sem sofrimento. parafraseando o sérgio lopes, como era o HTML no começo antes da gente começar a pintar botão e centralizar divs.
gruber não tava tentando substituir o html. ele tava tentando não precisar escrever html pros 90% dos casos em que escrever html era só “quero um parágrafo, um heading, um link, uma lista, uma ênfase”. ele queria voltar a ter o blog que dava pra ler sem o ctrl+shift+i ligado.
asterisco vira ênfase. hash vira heading. colchete-parêntese vira link. qualquer pessoa que já recebeu um email com *importante* entende a convenção no primeiro contato. não é coincidência — a inspiração veio de convenções de texto em email e usenet dos anos 90.
tem um detalhe que eu gosto: o # como heading não foi ideia do gruber. foi do aaron swartz, que em 2002, aos 15 anos, já tinha proposto o atx — uma sintaxe estruturada com # pra títulos. dois anos depois, aos 17, swartz virou o único beta-tester do markdown. não teve comitê. não teve w3c. não teve spec de 400 páginas. teve um cara com um problema, uma especificação deliberadamente curta, e um parser que funcionava bem o suficiente. ponto.
o que sobreviveu
vinte e dois anos depois, cadê o markdown?
tá em todo readme do github. tá no notion, no obsidian, no discord, no slack (na versão deles), no stack overflow, no dev.to, no medium (internamente), em jupyter notebook, em docusaurus, em astro — esse blog, inclusive. tá no docs.anthropic.com. tá na claude.ai e no chatgpt, que respondem em markdown por default sem ninguém ter pedido explicitamente.
cadê o concorrente “superior” de 2004? o xml com xsl que ia renderizar qualquer coisa? o wiki markup que cada wiki reinventava com a própria sintaxe? o bbcode dos fóruns? os editores wysiwyg que geravam 40kb de html pra um parágrafo em negrito?
ainda existem. alguns até funcionam. mas o que virou infraestrutura foi o asterisco.
entra texto, sai texto
tem um detalhe mais recente que só ficou óbvio nos últimos anos, e que é o ponto principal desse post.
as llms — a tecnologia mais usada da década, que movimenta bilhões em infra, pesquisa e hype — rodam no modelo computacional mais simples que existe. o mesmo modelo do pipe do unix, de 1973.
entra texto. sai texto.
você manda uma string. recebe uma string. tudo o resto — tool use, multimodalidade, agentes, pipelines, orquestração, mcp — é camada em cima desse núcleo. e o formato que o núcleo prefere, por default, é markdown.
não é acidente. markdown é o formato que um humano consegue ler sem renderizar, que uma máquina consegue parsear sem depender de contexto externo, e que sobrevive a ser copiado entre 12 ferramentas diferentes sem perder a semântica. é o formato que serve tanto pra você rascunhar um email quanto pra um modelo de 400 bilhões de parâmetros te responder uma dúvida técnica.
claude escreve em markdown por padrão. gpt também. quando o modelo quer te dar uma lista, usa -. quando quer destacar, usa **. quando quer mostrar código, usa três crases. é a língua franca entre humanos e máquinas — e ela já estava ali, esperando.
o que tende a vencer
eu podia ter aberto esse blog com um post sobre context window degradation, sobre a diferença entre skill e agente, sobre como estruturar um claude.md pra um monorepo. tudo útil.
mas começar por aí seria começar pelo teto. o andar de baixo é a simplicidade. os formatos que vencem não são os mais poderosos no dia do lançamento — são os mais baratos de adotar, os mais fáceis de ler, e os mais difíceis de quebrar.
é o http sobre os protocolos “sofisticados” de conexão dos anos 90. é o json sobre o xml. é o markdown sobre o wysiwyg. é o pipe do unix sobre os frameworks de orquestração que tentaram reinventá-lo. é o prompt em texto natural sobre a api estruturada com 40 campos obrigatórios.
uma das coisas que aprendi escrevendo código por mais de uma década e dando aula por outra: quando uma tecnologia sobrevive parecendo óbvia, raramente é sorte. é porque alguém, em algum momento, resistiu à tentação de adicionar complexidade — e essa resistência era o trabalho duro. complexidade é o caminho de menor atrito pra quem projeta. simplicidade é o caminho de maior atrito, e o que envelhece melhor.
o paulo escreveu sobre isso há algumas semanas, num post ótimo chamado “markdown, abstrações e o futuro do ux”. recomendo. não é coincidência a gente chegar nessa conclusão em paralelo — é onde a água corre.
obrigado pela cobrança, paulo
e aqui estou.
o blog abre com um post que não é sobre a ferramenta do mês, nem sobre o framework do trimestre. é sobre observar o que sobrevive. e tentar, quando der, construir do lado certo dessa curva.
os próximos posts vão ter código, terminal, claude code, opinião forte sobre ia generativa, e o que mais der pano pra manga. mas o chão é esse aqui. a gente escreve em markdown por um motivo, e eu queria que o primeiro post fosse sobre esse motivo.