Há uma pessoa neste momento, algures, a integrar a sua API. Ela não está no seu site de documentação. Não abriu o seu guia de iniciação. Nunca viu o seu playground interativo ou a navegação cuidadosamente concebida na barra lateral.
Eles estão sentados no Claude. Ou no Copilot. Ou Cursor. Escreveram algo como "integrar a API de faturação Stripe com a minha aplicação Next.js utilizando o router de aplicações" e esperaram que o código de trabalho voltasse. A IA lia os seus documentos em nome deles. Encontrou os endpoints relevantes, compreendeu o fluxo de autenticação, escolheu os métodos SDK corretos e produziu uma implementação.
Há duas semanas, na Start Summit Hackathon em St. Gallen, vi isto acontecer em tempo real. Estava a falar com um grupo de estudantes de Ciências da Computação e com alguns fundadores de startups em fase inicial sobre a forma como abordam as novas API, e todos eles descreveram o mesmo fluxo de trabalho: colar o problema numa IA, receber o código de volta, iterar a partir daí. Uma das alunas riu-se quando lhe perguntei se tinha lido os documentos. "Porque é que eu havia de ler? O Claude lê-os por mim".
A pessoa nunca visitou o seu sítio. Pode nunca mais visitar o seu site. E é cada vez mais assim que o software é construído.
A viagem que ninguém planeou
Durante muito tempo, as relações com os programadores seguiram um caminho bem compreendido. Escrevia-se documentação completa. Publicou guias de início rápido. Dava palestras em conferências. Mantinha uma presença no Stack Overflow. Tornou a referência da sua API pesquisável, os seus SDKs idiomáticos, as suas mensagens de erro úteis.
Esse caminho pressupõe que o desenvolvedor lerá seu conteúdo. Navegar na sua estrutura. Seguir os seus passos.
A pesquisa de desenvolvedores do GitHub de 2024 descobriu que 97% dos desenvolvedores corporativos já usaram ferramentas de codificação de IA em algum momento. O inquérito anual do Stack Overflow revelou que 76% de todos os programadores estão a utilizar ou planeiam utilizar ferramentas de IA, com 62% dos profissionais a utilizá-las ativamente no dia a dia. Esses números já eram altos e só aumentaram desde então.
O novo percurso tem um aspeto diferente. Alguém descreve o que pretende em linguagem natural. Um assistente de IA lê a documentação, encontra as secções relevantes e gera a integração. O construtor revê o resultado, talvez aperfeiçoe o pedido, talvez faça um seguimento. Minutos, não horas.
O funil de arranque que as equipas DevRel passaram anos a aperfeiçoar? Está a ser contornado. Não porque fosse mau - o ponto de entrada simplesmente mudou.
Dois consumidores, um conjunto de documentos
A documentação tem agora dois públicos fundamentalmente diferentes.
O primeiro é o leitor humano. Esta pessoa ainda existe. Aparece para tomar decisões de arquitetura, depurar casos extremos, analisar a conformidade e compreender conceitos. Quer explicações narrativas, material de referência bem organizado e um raciocínio claro sobre as soluções de compromisso.
O segundo é o intermediário de IA. Este lê a sua documentação em nome de um construtor. Não se preocupa com a sua barra lateral. Não aprecia o seu design visual. Precisa de conteúdo estruturado e analisável por máquina: markdown limpo, formatação consistente, especificações explícitas sobre as quais possa raciocinar sem ambiguidade.
Atualmente, quase todos os sítios de documentação são optimizados exclusivamente para o primeiro público. O segundo público já é o consumidor dominante.
Jeremy Howard identificou esta tensão quando [propôs a norma /llms.txt] (https://llmstxt.org/) em 2024. A sua observação foi precisa: "Os grandes modelos linguísticos dependem cada vez mais de informações de sítios Web, mas enfrentam uma limitação crítica: as janelas de contexto são demasiado pequenas para lidar com a maioria dos sítios Web na sua totalidade." A proposta é simples. Um ficheiro markdown com curadoria em /llms.txt que dá aos modelos de IA uma visão geral estruturada do seu produto e ligações para os recursos mais importantes. FastHTML, os próprios documentos do Anthropic e um [diretório crescente de projectos] (https://llmstxt.site/) já têm um.
É uma convenção útil. Mas é também um sintoma de um problema mais profundo. O verdadeiro problema não é o formato. É o facto de a maior parte da documentação nunca ter sido concebida tendo em mente o consumo por parte das máquinas.
O construtor não está a cortar nos cantos
Há uma tentação de olhar para a pessoa que pede Claude em vez de ler a documentação e concluir que ela está a tomar atalhos. Que ela não entende realmente o que está acontecendo no código. Que ela é, de alguma forma, um desenvolvedor inferior.
Já tive esta conversa vezes suficientes para saber que isso é normalmente errado.
Muitos destes construtores são engenheiros sénior que fazem escolhas deliberadas de eficiência. Eles entendem o código - só não querem navegar por quatro páginas de documentação para encontrar as três linhas de que realmente precisam. Eles aprenderam que um assistente de IA pode extrair essas linhas mais rápido do que eles podem procurar por elas, então eles delegam a leitura. (Honestamente, eu próprio faço isto. Não me lembro da última vez que li um guia de iniciação de cima a baixo).
A Anthropic reconheceu este padrão quando construiu o [Model Context Protocol] (https://modelcontextprotocol.io/introduction). O MCP é agora suportado pelo Claude, ChatGPT, VS Code, Cursor, entre outros. Foi explicitamente concebido para que os assistentes de IA possam aceder a sistemas externos, obter contexto e agir com base nele. A especificação descreve-a como fornecendo "acesso a um ecossistema de fontes de dados, ferramentas e aplicações que irão aumentar as capacidades e melhorar a experiência do utilizador final".
Leia isto com atenção - é uma linguagem de infraestrutura, não de conveniência. Os construtores que utilizam estas ferramentas não estão a evitar o trabalho. Estão a trabalhar através de uma nova camada, e a sua documentação faz parte dessa camada, quer a tenha concebido ou não.
As relações com os programadores foram criadas para uma era diferente
Se a sua estratégia DevRel foi concebida antes de 2023, foi concebida para um mundo onde os programadores lêem os documentos diretamente. Esse mundo não desapareceu, mas já não é o padrão de interação dominante para uma parte crescente dos criadores.
Isto altera o cálculo de várias actividades DevRel de longa data.
**Uma apresentação de 45 minutos numa conferência de programadores chega a uma sala com algumas centenas de pessoas. Um ficheiro /llms.txt bem estruturado e uma documentação limpa e legível por máquina chegam a todos os construtores que perguntam a qualquer assistente de IA sobre o seu produto, continuamente, em qualquer altura. A palestra é um evento único. A documentação legível por máquina é composta. Não estou a dizer que as conferências não têm valor - acabei de regressar de uma, literalmente - mas a equação de alavancagem mudou.
**O clássico tutorial de início rápido em cinco passos é cada vez mais uma formalidade. O construtor não segue passos. Descrevem o que pretendem e esperam que a IA produza a integração. Se a API estiver bem documentada num formato de fácil utilização, a IA trata da experiência de arranque de forma mais eficiente do que qualquer tutorial poderia fazer. Em vez disso, os tutoriais devem tornar-se material concetual: explicar por que razão se deve escolher a abordagem A em vez da abordagem B. A IA pode gerar a implementação. É muito menos fiável a explicar as soluções de compromisso.
**Os dados do seu próprio inquérito mostraram que 84% dos programadores utilizam a documentação técnica diretamente, sendo que 90% destes confiam na documentação contida nos pacotes API e SDK. Mas a forma como acedem a esses documentos é cada vez mais através de uma camada de IA e não de um separador do browser. As perguntas que ainda chegam ao Stack Overflow tendem a ser as mais difíceis - casos extremos, depuração de produção, coisas que exigem nuances. Valiosas, com certeza. Mas já não é onde está o volume.
Quando a IA lê os seus documentos, a atualidade torna-se crítica
Aqui está a parte em que a maioria das equipas não pensou.
Quando um ser humano lê uma página de documentação, pode fazer um julgamento. Pode reparar que as capturas de ecrã parecem antigas, ou que um comentário no final diz que o processo mudou. Podem olhar para ela e pensar "isto parece desatualizado".
Um assistente de IA não pode fazer nada disso. Lê o texto, processa-o como um facto e gera uma resposta com total confiança. Se a documentação descrever um ponto final obsoleto, a IA recomendará alegremente a integração com ele. Se a documentação fizer referência a uma infraestrutura que foi substituída há seis meses, a IA descreverá a configuração antiga como atual. Sem hesitação.
O construtor confia na IA. A IA confia na documentação. Se a documentação estiver desatualizada, essa cadeia de confiança fornece uma resposta errada com segurança.
Isto sempre foi um problema, obviamente. Os conteúdos obsoletos sempre confundiram as pessoas. Mas os danos foram contidos porque os leitores humanos podiam, por vezes, detectá-los. Os intermediários de IA não conseguem. Amplificam os conteúdos obsoletos, fornecendo-os em grande escala, com autoridade, a pessoas que não têm motivos para duvidar deles.
A atualidade já não é uma questão de qualidade do conteúdo. É um problema de fiabilidade para todos os fluxos de trabalho alimentados por IA que tocam nos seus documentos.
A palavra "programador" é demasiado restrita
As pessoas que estão a criar software em 2026 não se identificam todas como programadores. Alguns são designers que pedem ao Claude para construir um protótipo funcional. Alguns são gestores de produto que utilizam o Cursor para enviar ferramentas internas. Outros são analistas de dados que descrevem um pipeline de dados em linguagem natural e deixam um agente montá-lo. Na Start Summit, metade das equipas da hackathon tinha membros sem qualquer experiência em programação que, no final do fim de semana, já estavam a enviar software funcional.
A Ramp é um exemplo útil. A empresa fintech passou de uma avaliação de US $ 5.8 bilhões em 2023 para [US $ 32 bilhões no final de 2025] (https://techcrunch.com/2025/11/17/ramp-hits-32b-valuation-just-three-months-after-hitting-22-5b/), ultrapassando US $ 1 bilhão em receita anualizada ao longo do caminho. Uma das startups de crescimento mais rápido da história. Uma parte amplamente discutida de sua abordagem: gerentes de produto construindo recursos diretamente com ferramentas de IA em vez de esperar em um backlog de engenharia. Os PMs da Ramp não se limitam a escrever especificações. Eles enviam o código. A IA trata da implementação. O PM lida com a intenção.
Não é um atalho. Um novo modelo operacional - e está a funcionar a uma escala que torna muito difícil descartá-lo como uma experiência.
A Anthropic tem sido deliberada em chamar a isto a persona "construtor". As suas ferramentas foram concebidas não apenas para engenheiros de software profissionais, mas para qualquer pessoa que consiga descrever o que pretende construir. Quando Claude pode criar uma aplicação full-stack a partir de um design Figma via MCP, a linha tradicional entre "desenvolvedor" e "não desenvolvedor" se dissolve.
Isso tem implicações reais para qualquer pessoa que mantenha documentação ou se preocupe com a experiência do desenvolvedor. Seu público não está mais limitado a pessoas que sabem o que é um ponto de extremidade REST. Ele inclui qualquer pessoa cujo assistente de IA possa interagir com seu produto. O PM da Ramp que envia um recurso usando sua API? Provavelmente nunca lerá sua documentação diretamente. O agente de IA deles lerá com certeza.
O que isso significa para a documentação
Se a documentação serve agora dois públicos - leitores humanos e intermediários de IA - precisa de funcionar para ambos. Parece óbvio. Na prática, quase ninguém o faz.
Eis o que eu acho que realmente importa:
**Se os documentos da sua API são uma página HTML lindamente renderizada que um LLM tem que raspar e analisar, a IA está a trabalhar mais do que deveria. Envie a especificação OpenAPI em bruto juntamente com a versão renderizada. Enviar markdown limpo. Tornar as especificações acessíveis sem exigir que a IA interprete o layout da página.
**Estrutura ao nível do bloco em vez de narrativa ao nível da página. Os assistentes de IA não consomem documentação página a página. Extraem as secções relevantes. Um documento com títulos claros, parágrafos autónomos e semântica explícita ao nível do bloco é muito mais útil para uma IA do que uma narrativa fluida que requer a leitura de toda a página para obter o contexto.
**Confie nos sinais de que as máquinas sabem ler. Quando é que este documento foi revisto pela última vez? Ainda é atual? O conteúdo foi assinalado? Estes sinais têm de existir numa forma a que a IA possa aceder, e não apenas como sinais visuais numa página Web. Uma pontuação de atualidade, um estado de expiração, uma data de revisão, são os metadados que permitem a uma IA decidir se um documento é seguro para ser utilizado como fonte.
**Quando um assistente de IA fornece a um construtor uma resposta confiante baseada num endpoint obsoleto, os danos são piores do que um 404. O construtor constrói sobre ele. Faz o envio. Depois, ele quebra na produção e ninguém sabe o motivo até que alguém rastreie a documentação que deveria ter sido atualizada meses atrás. Cada documento que uma IA possa referenciar precisa de um mecanismo para provar que ainda está atualizado. (Isto é, revelação completa, exatamente o problema que estamos a construir o Rasepi para resolver - expiração forçada em blocos de documentação para que o conteúdo obsoleto não se possa esconder).
A mudança silenciosa na forma como os produtos são representados
Há uma consequência mais ampla de tudo isto que vale a pena referir diretamente.
A sua documentação já não é apenas um manual de referência para os programadores. É o material de origem que os assistentes de IA utilizam para representar o seu produto para o mundo. Quando um construtor pergunta ao Claude como utilizar o seu produto, a resposta do Claude é moldada por tudo o que consegue encontrar e analisar na sua documentação.
Bons documentos, boa resposta. Desactualizados, ambíguos, fechados em HTML que é difícil para um modelo analisar - pior resposta, ou uma resposta incorrecta. Tão simples quanto isso.
A qualidade da resposta da IA sobre o seu produto é agora um indicador direto da experiência do programador. A maioria das empresas ainda não está a tratar isso dessa forma.
As equipas que estão à frente nesta matéria - Stripe, Vercel, Cloudflare, a própria Anthropic - tratam a legibilidade da IA como uma preocupação de primeira classe. Um requisito fundamental que molda a forma como a documentação é escrita, estruturada e mantida. Não é um item do backlog para o próximo trimestre.
O construtor sentado no Claude neste momento, descrevendo o que quer construir, esperando código funcional em minutos - pode nunca mais visitar um site de documentação. Mas a IA que o serve fá-lo-á. Constantemente.
Essa IA é agora o seu leitor mais frequente. A questão é saber se os seus documentos estão preparados para isso.
A melhor estratégia de experiência do programador em 2026 não é uma palestra numa conferência ou um guia de início rápido. É garantir que a IA o faz corretamente.
Este post faz referência a pesquisas e documentação de produtos disponíveis publicamente. As estatísticas são retiradas do Inquérito aos programadores do GitHub 2024 e do Inquérito aos programadores do Stack Overflow 2024. A especificação /llms.txt é mantida em llmstxt.org. O protocolo de contexto de modelo está documentado em modelcontextprotocol.io.