Por que o criador do Jepsen desconfia da documentação escrita com ajuda de LLMs

O criador do Jepsen, Kyle Kingsbury, levantou um alerta: LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → tornaram mais fácil fingir maturidade em projetos de software. Para quem escolhe dependências no dia a dia, isso muda o que vale a pena verificar antes de confiar.

Uma frase de quem passou a carreira desconfiando de banco de dados

Kyle Kingsbury é conhecido por uma coisa: não acreditar na palavra do fabricante. Ele criou o Jepsen, o conjunto de testes que simula partições de rede e falhas de hardware pra ver se um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → realmente entrega as garantias de consistência que promete no site. O projeto ficou conhecido justamente por submeter bancos de dados distribuídos a esse tipo de teste adversarial, independentemente do que a documentação do fabricante prometia. Quando esse cara diz que não confia mais nos sinais que usava pra avaliar maturidade de software, vale prestar atenção.

A frase foi coletada pelo Simon Willison em seu blog no dia 1º de novembro de 2026, extraída de um relatório Jepsen sobre o banco ParticleDB, na versão 1.1.4. Ela resume um incômodo que já estava latente:

De forma mais ampla, 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 novo projeto de software com desconfiança: os sinais que costumávamos usar como marcadores de um sistema maduro agora são mais fáceis de falsificar.

Kyle Kingsbury, criador do Jepsen, em relatório de testes do ParticleDB 1.1.4More 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.

Eu concordo com o diagnóstico. Discordo um pouco da conclusão implícita de desconfiar de tudo, porque isso também pune quem está do lado certo da história. Mas vamos por partes.

Os sinais que a gente usava para medir maturidade não servem mais

Antes de LLM virar ferramenta de trabalho, um README.md bem escrito, com exemplos de código testados, seção de troubleshooting e changelog detalhado, era um proxy razoável de cuidado. Escrever aquilo dava trabalho. Projeto que investia tempo em documentação normalmente também tinha investido tempo no código.

Esse proxy quebrou. Hoje qualquer ferramenta de IA generativa escreve um README.md completo, com seção de instalação, exemplos, FAQ e até diagrama em texto, a partir de um prompt de trinta segundos. O texto fica bom. Não diz nada sobre se o código funciona, se os testes realmente cobrem os casos difíceis ou se o mantenedor sabe o que está prometendo.

O mesmo vale pra outros sinais que a comunidade dev aprendeu a ler:

• Mensagens de commit detalhadas: hoje saem de um assistente de código em segundos, sem relação direta com a qualidade do diff
• Descrição de pull request bem argumentada: pode vir de um LLM que nunca rodou o teste que diz ter rodado
• Changelog organizado por categoria (Added, Fixed, Breaking): formato trivial de gerar, difícil de verificar sem abrir o diff

Nenhum desses sinais era prova definitiva antes. Mas custavam tempo o suficiente pra funcionar como filtro grosseiro. Esse filtro deixou de existir.

O paradoxo que sobra pro mantenedor honesto

Aqui mora a parte mais difícil da provocação de Kingsbury, que ele deixa explícita na segunda pergunta do mesmo post:

Na era dos LLMs, o que os mantenedores podem fazer para garantir software correto e documentação precisa? Feito esse trabalho, como podem demonstrar essa qualidade aos usuários?

Kyle Kingsbury, criador do JepsenIn 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?

Um mantenedor sério também usa LLM pra escrever documentação mais rápido. Isso é legítimo e, na maioria dos casos, resulta em docs melhores do que ele escreveria sozinho, com menos tempo gasto. O problema é que, de fora, o README.md dele e o README.md de um pacote mal testado ficam parecidos. A prosa deixou de distinguir os dois casos.

Isso não é motivo pra descartar documentação gerada por IA em bloco. Seria jogar fora o uso legítimo junto com o abuso, e a maior parte dos projetos que uso no dia a dia já usa IA generativa em algum ponto da escrita. O recorte certo não é quem escreveu o texto, é o que dá pra verificar além do texto.

O que muda na prática pra quem escolhe dependência

Se a prosa parou de carregar sinal confiável, o trabalho de avaliação precisa migrar pra artefato verificável. Na prática, antes de adicionar uma dependência nova a um projeto, eu priorizaria:

1. Rodar o npm test (ou equivalente) localmente e ver se o que passa bate com o que o README.md promete, em vez de confiar na badge de cobertura
2. Olhar o histórico de .github/workflows (ou pipeline equivalente): CI que roda de verdade, com logs reais de execução, é mais difícil de falsificar do que um parágrafo bem escrito
3. Procurar análise adversarial de terceiros, no estilo Jepsen: alguém de fora tentou quebrar a promessa específica da ferramenta, seja consistência, segurança ou performance sob carga
4. Checar se as issues fechadas têm discussão técnica real, com reprodução de bug e trade-off explicado, não só respostas genéricas

Nenhum desses critérios é novo. A diferença é que, antes, documentação caprichada ainda contava como sinal auxiliar. Agora ela conta pouco, porque custa quase zero de produzir independentemente da qualidade real por trás.

O contra-argumento que eu levo a sério

Dá pra argumentar que isso sempre foi assim: documentação bonita nunca foi garantia de nada, projeto com marketing forte e engenharia fraca existe desde antes de LLM, e o que muda é só o custo de produzir o verniz. Esse ponto é válido e eu não vou fingir que é novo o problema de empresa vender confiança que não tem.

A diferença de grau virou diferença de tipo. Antes, fingir maturidade custava tempo real: escrever README.md convincente, manter changelog, responder issues com aparente competência. Esse custo funcionava como filtro, mesmo imperfeito. Hoje o custo caiu perto de zero pra qualquer um, honesto ou não, justamente no momento em que mais dependências entram em produção via npm install sem revisão humana no meio.

O que fica em aberto

Kingsbury termina com uma pergunta sem resposta fácil, e eu não vou fingir que tenho uma. O caminho mais honesto que vejo é deslocar a confiança da prosa pro artefato reproduzível: teste que roda, pipeline que falha quando devia falhar, análise independente que tentou quebrar a promessa. Isso não resolve o problema de escala, porque verificar artefato dá trabalho que ninguém tem tempo de fazer pra cada dependência transitiva do package.json. Mas é melhor do que continuar confiando num texto que, hoje, qualquer modelo escreve igual, seja o projeto sólido ou não.

Fonte: Simon Willison, "A quote from Kyle Kingsbury", Simon Willison's Weblog, 1º de novembro de 2026 (https://simonwillison.net/2026/Nov/1/kyle-kingsbury/).

Fonte: Simon Willison