Documentação gerada por IA corrói os sinais que provam que um projeto é maduro

Uma citação do criador do Jepsen, Kyle Kingsbury, publicada por Simon Willison em 1º de novembro de 2026, aponta que LLMs tornaram baratos os sinais que engenheiros usavam para confiar num projeto novo. A saída passa por verificação empírica, não por ler o README.

O alerta saiu de um relatório técnico, não de um ensaio sobre IA

Kyle Kingsbury é o criador do Jepsen, uma suíte de testes que simula falhas de rede e verifica se um banco de dados realmente cumpre as garantias de consistência que promete, sempre com o mesmo método: rodar o banco sob partição de rede e checar se os dados ficam consistentes como o fabricante jura que ficam.

Em 1º de novembro de 2026, Simon Willison registrou em seu blog uma citação de Kingsbury tirada de um relatório Jepsen sobre o ParticleDB, versão 1.1.4. A citação não fala de um bug específico do banco: fala de um problema maior, que atinge qualquer projeto de software na era dos modelos de linguagem.

O uso de LLMs corrói a confiança na documentação, no software e nas organizações que os produzem. Talvez os engenheiros passem a tratar qualquer projeto novo com desconfiança: os sinais que costumávamos usar como marcadores de um sistema maduro agora são mais fáceis de falsificar. [...] Na era dos LLMs, o que os mantenedores podem fazer para garantir que o software esteja correto e a documentação seja precisa? Tendo feito esse trabalho, como podem demonstrar essa qualidade aos usuários?

More broadly, the use of LLMs erodes trust in documentation, in software, and in the organizations which produce them. Perhaps engineers will begin to treat any new software project with suspicion—the signals we used to rely on as markers of a mature system are now easier to counterfeit. [...] In the age of LLMs, what can maintainers do to ensure correct software and accurate documentation? Having done that work, how can they demonstrate its quality to users?Kyle Kingsbury, criador do Jepsen, em relatório Jepsen sobre o ParticleDB 1.1.4

Os sinais que um desenvolvedor usava para confiar num projeto novo

Antes de qualquer LLM escrever uma linha de documentação, um engenheiro avaliando se adota uma biblioteca ou um banco de dados novo olhava para alguns sinais indiretos de maturidade:

• README completo, com exemplos que rodam de primeira
• Changelog detalhado, explicando o motivo de cada mudança de versão
• Issues respondidas com profundidade técnica, não só "obrigado, vamos olhar"
• Seção de arquitetura que explica trade-offs, não só recursos
• Benchmarks com metodologia descrita, não só números soltos

Esses sinais funcionavam como proxy de esforço humano: só uma equipe que de fato entendia o sistema escrevia aquilo direito. Era caro falsificar, e por isso funcionava como filtro.

O que muda quando qualquer um desses sinais sai de um prompt

Um LLM de 2026 gera um README completo, um changelog plausível e até uma seção de arquitetura convincente em segundos, para um projeto que mal tem código funcional por trás. O texto fica gramaticalmente correto, bem estruturado, cheio de linguagem técnica correta. Só que nada ali garante que o software funciona como descrito.

É esse o ponto de Kingsbury: a documentação sempre foi um proxy imperfeito para qualidade, mas era um proxy caro de fabricar. Com LLMs, o custo de produzir milhares de palavras de documentação convincente caiu para frações de centavo em chamadas de API, enquanto o custo de produzir a coisa real (software correto, testado, íntegro) continua o mesmo de sempre. O proxy descolou do que ele deveria medir.

Isso devolve o problema para onde a documentação deveria ter resolvido: o leitor, o desenvolvedor avaliando a dependência, precisa voltar a verificar empiricamente, porque o texto sozinho não prova mais nada.

Como verificar na prática, sem confiar só no texto

O próprio trabalho de Kingsbury é um modelo de como sair do "confiar no texto" para "verificar o comportamento". Um teste Jepsen roda o banco sob condições adversas (partição de rede, atraso, perda de pacote) e checa se as operações realmente respeitam a consistência anunciada.

O ponto não é que todo desenvolvedor vá rodar Jepsen contra toda dependência nova (isso exige infraestrutura e tempo que a maioria dos times não tem). É que a pergunta certa deixou de ser "a documentação parece boa?" e passou a ser "existe alguém, de preferência independente do fabricante, que testou isso sob carga e publicou o resultado?". Relatórios Jepsen, auditorias de segurança de terceiros e benchmarks reproduzíveis por qualquer pessoa voltam a valer mais do que valiam há dois anos, justamente porque ficaram mais difíceis de falsificar com um prompt.

O que um mantenedor pode fazer para não perder a confiança do usuário

A pergunta que Kingsbury deixa em aberto (como provar qualidade numa era em que o texto não prova nada) tem algumas respostas práticas que já circulam entre mantenedores de projetos sérios:

1. Publicar testes que qualquer pessoa consiga rodar localmente, com instruções que realmente funcionam, não só prometer "cobertura de 95%"
2. Separar explicitamente o que foi gerado por IA do que foi revisado por humano, em vez de deixar a origem do texto ambígua
3. Manter um histórico público de incidentes e pós-mortems, porque admitir falha é mais difícil de fabricar com IA do que vender perfeição
4. Buscar auditoria independente (como um relatório Jepsen, uma auditoria de segurança externa ou um benchmark replicável) em vez de só benchmark interno

Nenhuma dessas medidas é barata. Pedir um relatório Jepsen a um banco de dados custa tempo de engenharia e, historicamente, contrato pago a quem faz esse tipo de auditoria; manter pós-mortems públicos exige maturidade organizacional que startups em estágio inicial raramente têm. O risco real é que essa verificação vire luxo de quem tem orçamento, e que o pequeno projeto open source honesto fique sem meio de provar que é honesto.

O que fica sem resposta

Kingsbury termina a citação com uma pergunta, não com uma fórmula pronta, e isso é o ponto mais honesto do texto: ele não tem solução definitiva. A própria verificação empírica (um relatório Jepsen, um benchmark, uma auditoria) também pode, em teoria, ser mal executada ou gerada com ajuda de IA, embora seja ordens de grandeza mais cara de falsificar do que um parágrafo de README.

Simon Willison, que coletou a citação, usa a tag ai-misuse para catalogar esse tipo de conteúdo; no momento da escrita, a tag soma cerca de 68 posts no blog dele. O recado para quem constrói software é que a reputação de um projeto deixou de ser algo que se lê. Virou algo que se precisa testar.

Fonte: Simon Willison