Habr: Como uma Base de Conhecimento Desatualizada Quebra LLM-Agentes e Como Corrigir

O Habr publicou a segunda parte de uma série sobre desenvolvimento com LLM: o autor explica por que uma base de conhecimento desatualizada é mais perigosa do que a completa falta de documentação. Se você mostrar a um agente um markdown bonito mas obsoleto, ele o tomará como verdade e começará a cometer erros no nível de arquitetura, status e dependências.

Por que isso é importante

A ideia principal é simples: um LLM confia no contexto da mesma forma que um compilador confia nos dados de entrada. Quando uma base de conhecimento contém versões antigas de serviços, links quebrados e planos que já divergiram há muito da realidade, o agente se apoia em um mapa falso do projeto. Como resultado, os erros aparecem não porque o modelo é fraco, mas porque lhe foi dada uma descrição imprecisa do ambiente. Para equipes com dezenas de projetos paralelos, isso rapidamente se torna um problema sistêmico em vez de um descuido único.

O autor enfatiza que a disciplina manual mal funciona aqui. Quanto mais documentos, repositórios e sessões com agentes, mais rápido a base de conhecimento acumula entropia. Até um workbench bem estruturado fica desatualizado no momento em que é criado, se ninguém o verifica automaticamente. Portanto, a questão não é mais se escrever documentação ou não, mas como incorporar ao processo mecanismos que não permitam que ela degrade silenciosamente e envenene o próximo ciclo de desenvolvimento.

Como detectar desatualização

A resposta básica são verificações automáticas simples que podem ser executadas manualmente ou em CI. O autor descreve um script que passou por seu workbench e imediatamente encontrou dezenas de problemas: mais de um terço dos links internos não levava a lugar nenhum após migrações de documentos entre repositórios. Para um agente, isso é especialmente perigoso: ele tenta seguir um link, não encontra o arquivo e perde contexto ou começa a preenchê-lo com alucinações. Em escala, isso rapidamente se torna uma fonte constante de defeitos.

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

O autor recomenda separadamente introduzir um limite de atualidade, por exemplo 60 dias, e não reescrever cada documento do zero, mas fazer uma breve revisão dos fatos: versões, status, dependências, planos atuais. Alguns minutos dessa verificação devolvem credibilidade ao documento. A mesma lógica funciona para TODOs: enquanto as tarefas estão espalhadas por logs, planos e anotações, a equipe não vê o quadro completo. Uma vez agregadas, a base de conhecimento se torna uma ferramenta de trabalho novamente, não um arquivo de anotações aleatórias.

Regras e armadilhas

Scripts sozinhos não são suficientes se os documentos não tiverem um ciclo de vida claro. O autor sugere marcá-los com status active, reference, draft e archived, e colocar materiais antigos em archive/ em vez de deletá-los. Após cada fase de trabalho, o agente deve atualizar documentos relacionados, registrar itens inacabados e, quando a janela de contexto ficar cheia, coletar um prompt de continuação para a próxima sessão. Dessa forma, a base de conhecimento permanece sincronizada entre sessões em vez de se espalhar pela memória do modelo.

Como escreve o autor:

"Um plano desatualizado é o mesmo contexto envenenado, apenas

parecendo inocente."

A segunda parte do argumento traz à tona o lado inverso: LLM torna a automação muito barata, então o desenvolvedor facilmente começa a otimizar o processo em vez do produto. Outro ADR, outro script ou um pipeline perfeitamente planejado parecem progresso, embora production ainda possa não ter uma feature funcionando. A orientação prática aqui é rígida: primeiro produto, depois staging, monitoramento e CI/CD, depois tipagem, testes e ciclos autônomos mais complexos. Se a equipe construir uma cadeia completa "hipótese — geração — deploy" antes de aprender a detectar um merge quebrado, ela investe em meta-otimização com ROI questionável.

O que isso significa

O material no Habr atinge em cheio o principal ponto de dor do desenvolvimento assistido por IA: a qualidade da resposta de um modelo depende cada vez mais não apenas do prompt, mas da higiene do contexto ao redor do código. Para equipes e desenvolvedores solo, a conclusão é prática: a base de conhecimento deve viver pelas mesmas regras que o código — com verificações, status e atualizações regulares. Caso contrário, LLM acelerará não o trabalho, mas a disseminação de erros antigos que parecerão plausíveis e se reproduzirão de sessão em sessão.