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 ser que nunca visite o seu site. E é cada vez mais assim que o software é construído.
A principal mudança
A documentação tem agora dois consumidores fundamentalmente diferentes: os humanos que a lêem e os assistentes de IA que a lêem em nome dos construtores. A maior parte da documentação é optimizada exclusivamente para humanos. A IA já é o leitor dominante.
Isto muda tudo a jusante:
- Quando uma IA serve conteúdos obsoletos, o construtor não tem forma de detetar o problema. Os danos são silenciosos.
- Os gestores de produto, designers e analistas estão a enviar software através de assistentes de IA, muitas vezes sem nunca terem lido uma linha de documentação.
- A estrutura legível pela máquina é mais importante do que o design visual. O markdown limpo, os blocos autónomos e os metadados explícitos são o que permite à IA representar o seu produto com precisão.
- Os requisitos de formato dividiram-se.** Os leitores humanos precisam de narrativa. Os intermediários de IA precisam de especificações estruturadas e analisáveis. É necessário servir ambos.
O resto deste post revela como chegamos aqui, o que isso significa para o DevRel e o que você pode fazer sobre isso agora.
A viagem que ninguém planeou
Durante muito tempo, as relações com os programadores seguiram um caminho bem compreendido. Você escreveu uma documentação abrangente. 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. [A pesquisa anual do Stack Overflow] (https://survey.stackoverflow.co/2024/) mostrou que 76% de todos os desenvolvedores estão usando ou planejando usar ferramentas de IA, com 62% dos profissionais usando-as ativamente no dia a dia. Em 2026, esse número subiu para 84%, com 41% de todo o código agora gerado por IA e 51% dos desenvolvedores profissionais usando ferramentas de IA diariamente. Estes números não estão a abrandar.
A nova viagem 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 refine 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 por ser 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
Existe a 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.
Os números confirmam isso. Só o Claude lida agora com [25 mil milhões de chamadas de API por mês] (https://www.incremys.com/en/resources/blog/claude-statistics), com 30 milhões de utilizadores activos mensais em 159 países. 70% das empresas da Fortune 100 usam o Claude. De acordo com um inquérito da Menlo Ventures, a Anthropic detém 32% da quota de mercado da IA empresarial por utilização de modelos, à frente da OpenAI com 25%. Um relatório de investigação do HSBC coloca esse valor ainda mais alto: 40% do total de despesas com IA. Não se trata de ferramentas experimentais. São infra-estruturas primárias.
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 liam 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, ele 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.
E aqui está o que torna isto pior do que parece: 66% dos programadores já afirmam que o maior problema das ferramentas de IA é o facto de darem resultados que estão "quase certos, mas não totalmente". A documentação obsoleta contribui diretamente para esse problema. A IA não está a alucinar. Está a reproduzir fielmente conteúdo desatualizado, e não há forma de o construtor perceber a diferença.
O construtor confia na IA. A IA confia na documentação. Se a documentação estiver desactualizada, essa cadeia de confiança dá uma resposta seguramente errada.
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. Trata-se de um novo modelo operacional, que está a funcionar a uma escala que torna muito difícil descartá-lo como uma experiência.
O próprio estudo interno da Anthropic é revelador. Quando eles [entrevistaram 132 de seus próprios engenheiros] (https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/) sobre como eles usam o Claude, os engenheiros relataram usá-lo para cerca de 60% de suas tarefas de trabalho. As utilizações mais comuns? Depurar código existente, compreender o que partes da base de código estavam a fazer e implementar novas funcionalidades. Os engenheiros afirmaram que tendem a entregar ao Claude tarefas que "não são complexas, repetitivas, em que a qualidade do código não é crítica". E 27% do trabalho que agora fazem com o Claude simplesmente não teria sido feito antes.
Esta é a própria equipa da Anthropic. As pessoas que construíram o modelo estão a usá-lo como um leitor de documentação, um navegador de base de código e um gerador de primeiro rascunho. Todos os outros estão a fazer o mesmo, apenas com os seus documentos em vez dos deles.
A Anthropic foi deliberada em chamar isso de persona "construtora". 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. O seu público já não se limita às 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á a 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.
**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 ponto final 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 para resolver com o Rasepi. Forçar a expiração de blocos de documentação para que o conteúdo obsoleto não se possa esconder).
Começando: audite sua documentação atual
Se leu até aqui e está a pensar "ok, mas o que é que eu faço na segunda-feira?", aqui estão quatro coisas concretas que pode verificar esta semana.
**1. Abra o Claude ou o ChatGPT e peça-lhe para integrar o seu produto num cenário realista. Não utilize os seus conhecimentos internos. Veja apenas o que a IA produz. Está correto? Está actualizada? Está a utilizar os pontos finais corretos, a versão correta do SDK, o fluxo de autenticação correto? Se a IA estiver errada, é isso que os construtores estão a receber neste momento.
**2. Escolha as cinco páginas de documentação mais visitadas e pergunte: quando foi a última revisão? Ainda descreve o estado atual do produto? Se não conseguir responder a esta pergunta com confiança, a IA também não conseguirá. Esta é a correção mais importante para a maioria das equipas.
3. Envie formatos legíveis por máquina Se você não tem um arquivo /llms.txt, crie um. Se a sua referência de API estiver disponível apenas como HTML renderizado, exporte a especificação OpenAPI bruta e torne-a acessível. Se os seus documentos estão num CMS que não produz markdown limpo, esse é um problema que vale a pena resolver agora.
4. Adicione datas de revisão e metadados de atualização. Mesmo algo simples, um campo last-reviewed em seu sistema de gerenciamento de conteúdo, um ciclo de revisão obrigatório para páginas de alto tráfego. Isto dá aos humanos e à IA um sinal sobre se o conteúdo é fiável. Ferramentas como o Rasepi podem automatizar isto com expiração forçada ao nível do bloco, mas mesmo um processo manual é melhor do que nada.
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 de analisar por um modelo? 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, 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 um código funcional em minutos. Talvez nunca mais volte a visitar um sítio de documentação. Mas a IA que os 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 extraídas do Inquérito aos programadores do GitHub de 2024, do Inquérito aos programadores do Stack Overflow de 2024, do Relatório de produtividade dos programadores do Index.dev de 2026, das Estatísticas da Incremys Claude e do Relatório da Fortune sobre o Anthropic. A especificação /llms.txt é mantida em llmstxt.org. O Protocolo de Contexto de Modelo está documentado em modelcontextprotocol.io.