Agentes já leem 80% do tráfego da documentação de 20 mil empresas — em janeiro era o contrário

A manchete «Agentes de IA leem 80% da internet» pede para ser classificada como caça-cliques. Ela é imprecisa, mas a história em si é mais interessante do que a manchete sugere. Trata-se de como a documentação para desenvolvedores mudou de leitor principal.

O que realmente foi medido

O número não se refere a toda a web. Trata-se do tráfego em sites com documentação oficial para desenvolvedores pertencentes a cerca de 20 mil empresas. Entre elas estão Anthropic, Microsoft e Amazon. Atualmente cerca de 80% desse tráfego vem de agentes. Em janeiro a proporção era a inversa: predominavam as pessoas.

Em dez meses, a maioria dos leitores da documentação passou de humanos para programas. É essa dinâmica que vale lembrar, e não o número redondo da manchete. Observe que estamos reproduzindo números de uma publicação no Substack e de uma análise de Andrey Sebrant. Como exatamente os autores separam agentes de pessoas não fica claro no resumo. Quem for citar esses dados deve abrir a fonte original e verificar a metodologia.

Por que justamente a documentação

A documentação é um conteúdo quase ideal para um agente. Ela tem um objetivo claro: descobrir como chamar um método da API, quais parâmetros uma função aceita, o que significa um erro específico. Antes, o desenvolvedor com essa dúvida abria a página e lia. Agora ele passa a tarefa a um assistente de programação, que vai sozinho ao site, pega os trechos necessários e escreve o código.

A pessoa, por sua vez, lê a documentação com menos frequência e de forma indireta, por meio da resposta do agente. Essa é a nossa interpretação, mas ela explica bem por que os contadores de visitas mudaram tão bruscamente. Uma única solicitação do desenvolvedor pode gerar várias consultas do agente a páginas diferentes, de modo que a mudança no tráfego parece mais dramática do que a mudança no número real de usuários.

O que fazer a respeito

Se você é responsável pela documentação ou por um produto com API, daí decorrem alguns passos práticos.

• Separe a análise de dados. Veja que parcela dos acessos à sua documentação vem de agentes. Se você conta todas as visitas como humanas, suas métricas o enganam.
• Escreva para a máquina como primeiro leitor. Títulos claros, exemplos de código completos que podem ser copiados e executados, versões explícitas da API, descrição compreensível dos erros. O agente não adivinha pelo contexto: ele pega o que está escrito.
• Não esconda o essencial. Informações-chave em abas, imagens ou em uma interface renderizada apenas por scripts correm o risco de nem chegar ao agente.
• Considere formatos legíveis por máquina. Por exemplo, versões das páginas em marcação simples ou o arquivo llms.txt proposto pela comunidade, com uma lista de materiais importantes. Não é um padrão, mas um acordo, e nem todos o suportam, mas o custo de adoção é baixo.
• Meça o sucesso de outra forma. As visualizações de página mostram mal se a documentação ajudou. É mais útil ver se o agente resolveu a tarefa com a sua API na primeira tentativa.

As pessoas continuam precisando de documentação, mas de outro tipo: conceitos, visões gerais de arquitetura, aprendizado do zero. A camada de referência se transforma cada vez mais em uma interface para agentes.

Limitações

Primeiro, é uma amostra de sites de documentação, e não de toda a internet. Blogs, notícias e fóruns são lidos de outra forma, e os 80% não podem ser transferidos para eles. Segundo, é a parcela de visitas, e não de leitores. Um agente pode fazer dezenas de requisições onde uma pessoa abriria uma única página. Terceiro, como já dito, os detalhes da metodologia são desconhecidos pelo resumo.

Em resumo: mesmo com ressalvas, a tendência é evidente. Se o seu produto é usado por desenvolvedores, uma parte significativa do primeiro contato com ele hoje não é feita por uma pessoa. A documentação deve ser testada da mesma forma que você testa uma interface: um novo leitor, desta vez programático, consegue entendê-la?