Habr: como uma knowledge base desatualizada quebra o trabalho de agentes LLM e como corrigir

O Habr publicou a segunda parte de uma série sobre desenvolvimento com LLM. O autor explica por que uma knowledge base desatualizada é mais perigosa do que a ausência total de documentação. Se o agente recebe um markdown bonito, mas desatualizado, ele o toma como verdade e passa a errar na arquitetura, nos status e nas dependências.

Por que isso importa

A ideia central é simples: o LLM confia no contexto como um compilador confia nos dados de entrada. Quando a base de conhecimento guarda versões antigas de serviços, links quebrados e planos que há muito tempo divergiram da realidade, o agente se apoia em um mapa falso do projeto. Os erros surgem, então, não de um modelo fraco, mas de uma descrição incorreta do ambiente. Para equipes com dezenas de projetos paralelos, isso rapidamente vira um problema sistêmico, e não um descuido pontual.

O autor ressalta que a disciplina manual quase não funciona aqui. Quanto mais documentos, repositórios e sessões com o agente, mais rápido a knowledge base acumula entropia. Até um workbench bem estruturado envelhece desde a criação se ninguém o verifica automaticamente. Por isso a questão já não é escrever ou não documentação, mas como incluir no processo mecanismos que impeçam que ela se degrade em silêncio e envenene o próximo ciclo de desenvolvimento.

Como detectar a desatualização

A resposta básica são verificações automáticas simples, que podem ser executadas manualmente ou no CI. O autor descreve um script que rodou primeiro no próprio workbench e encontrou de imediato dezenas de problemas: mais de um terço dos links internos não levava a lugar nenhum depois da migração de documentos entre repositórios. Para o agente, isso é especialmente perigoso: ele tenta seguir o link, não encontra o arquivo e, ou perde o contexto, ou começa a completá-lo com alucinações. Em escala, isso vira rapidamente uma fonte constante de defeitos.

• Verificação de links internos entre arquivos markdown
• Controle da atualidade dos documentos-chave pela data de atualização
• Verificação de cobertura: todo projeto deve ter um arquivo workspace
• Agregação dos TODOs de todos os documentos markdown em um único ponto de visão geral

À parte, o autor aconselha definir um limite de atualidade, por exemplo 60 dias, e não reescrever cada documento do zero, mas fazer uma revisão curta dos fatos: versões, status, dependências e planos atuais. Alguns minutos nessa passada devolvem a confiança ao documento. A mesma lógica vale para os TODOs: enquanto as tarefas estiverem espalhadas por logs, planos e anotações, a equipe não enxerga o quadro completo. Depois de agregadas, a base de conhecimento volta a ser uma ferramenta de trabalho, e não um arquivo de notas aleatórias.

Regras e armadilhas

Scripts sozinhos não bastam se os próprios documentos não têm um ciclo de vida claro. O autor propõe marcá-los com os status active, reference, draft e archived, e guardar o material antigo em archive/ em vez de apagá-lo. Após cada fase do trabalho, o agente deve atualizar os documentos relacionados, registrar o que ficou pendente e, se a janela de contexto estourar, montar um continuation prompt para a próxima sessão. Assim a base de conhecimento fica sincronizada entre as sessões, em vez de se espalhar pela memória do modelo.

Como escreve o autor:

«Um plano desatualizado é o mesmo contexto envenenado, só que com

aparência inofensiva».

Na segunda parte do argumento aparece também o outro lado: o LLM torna a automação barata demais, e por isso o desenvolvedor facilmente passa a otimizar o processo em vez do produto. Mais um ADR, mais um script ou um pipeline perfeitamente descrito parecem progresso, embora em produção ainda possa não haver uma funcionalidade em funcionamento. A orientação prática é rígida: primeiro o produto, depois staging, monitoramento e CI/CD, em seguida tipagem, testes e ciclos autônomos mais complexos. Se a equipe constrói a cadeia completa «hipótese, geração, deploy» antes de aprender a detectar um merge quebrado, está investindo em metaotimização com ROI duvidoso.

O que isso significa

O material do Habr acerta a principal dor do desenvolvimento assistido por IA: a qualidade da resposta do modelo depende cada vez mais não só do prompt, mas da higiene do contexto em torno do código. Para equipes e desenvolvedores solo, a conclusão é prática: a base de conhecimento deve seguir as mesmas regras do código, com verificações, status e atualização regular. Caso contrário, o LLM não vai acelerar o trabalho, e sim a propagação de erros antigos, que parecerão plausíveis e se repetirão de sessão em sessão.