Mil páginas depois: onde uma wiki mantida por LLM começa a quebrar

Há uns dias percebi que a minha wiki passou de mil arquivos markdown. E a primeira pergunta que me fiz foi a pergunta certa: e daí?

Produzir arquivo é fácil. Um agente que organiza fonte sem parar produz volume o dia inteiro. Volume sozinho não prova nada — não prova que o conhecimento está mais organizado, não prova que ele acumula, não prova que o sistema funciona.

No artigo anterior eu contei como parei de destilar notas manualmente e passei essa etapa para um agente, seguindo a ideia de LLM Wiki do Karpathy. Prometi voltar com os números com calma — o que a wiki acumulou de verdade, e onde o agente errou de um jeito que demorei para perceber. É este artigo.

O que os números realmente dizem

Medi tudo isso em 2026-08-18. A wiki rastreia 1.011 páginas em wiki/; descontando índices, overviews e logs, sobram 916 páginas de conteúdo.

Dessas 916, 472 foram revisadas mais de uma vez — 51%. Ou seja: mais da metade não nasceu e morreu no mesmo commit. Alguém, ou melhor, algum agente, voltou nelas depois.

Preciso ser preciso aqui, porque é fácil escorregar. Revisão não é enriquecimento. Um arquivo pode ser tocado de novo por causa de um typo, de uma reformatação, de um campo de schema que mudou. Essas 472 páginas são evidência de manutenção contínua — não de que o conhecimento está se acumulando com sentido.

Para isso, preciso de outra medida: 219 páginas ligam três fontes ou mais; 112 ligam cinco ou mais. Isso já é integração — conhecimento de origens diferentes convergindo no mesmo lugar.

Mas mesmo assim não é a prova completa. Link não é incorporação semântica.

Para provar que o padrão realmente acumula, preciso mostrar uma página crescendo, revisão a revisão, e explicar o que cada revisão mudou de fato.

Uma página, vinte revisões

A página em questão documenta o índice de busca da própria wiki — um tema técnico, sem nada de cliente, empresa ou vida pessoal.

Ela nasceu em 2026-08-03 com 119 linhas, 2 fontes ligadas e 3 conceitos. Era desenho puro: nada tinha sido implementado ainda.

Hoje, em 2026-08-18, ela tem 541 linhas, 7 fontes e 5 conceitos — mais uma entidade ligada, que não existia na v1. Passou por 20 revisões: a criação, mais 18 que mudaram o que a página afirma e 1 que só mudou a forma (título de uma seção, sem fato novo).

Repare no desequilíbrio. Dezoito revisões semânticas contra uma estrutural não é o padrão típico da wiki inteira — é o retrato de uma página que documentou um projeto vivo enquanto eu trabalhava nele: desenho, implementação, duas rodadas de medição, replicação por outro agente.

O que entrou de fato nesse meio tempo:

1. A arquitetura interna inteira, de uma vez, quando o projeto saiu do papel — módulos, o racional do ranqueador, a seção de observabilidade.
2. A avaliação de duas ferramentas prontas concorrentes, em momentos diferentes. A segunda não repetiu a primeira: uma delas chegou a ser instalada e testada sobre o meu próprio acervo, virando um braço de controle medido.
3. Duas rodadas de medição empírica, que substituíram uma hipótese de desenho — “o índice deve ganhar do rg” — por número real. Incluindo o resultado que não confirmou a hipótese.

Uma das sete fontes veio de uma reunião de trabalho, então não posso nomeá-la aqui. O que ela deixou na página foi só uma correção de escala — um número dado de cabeça, confrontado no mesmo dia com a medição real. É o único ponto do caso que não posso detalhar, e prefiro dizer isso a fingir que a fonte não existe.

Este é o caso que sustenta o compounding — e ele é só um caso. Os 219 e os 112 lá em cima mostram que ele não é anomalia isolada, mas a prova mesmo é este arco: duas fontes viraram sete, e cada uma trouxe alguma coisa que a página não sabia sozinha.

Quando o LLM erra, o erro fica

Aqui está o trade-off que mais me preocupa no padrão inteiro, e é ele que separa isso de simplesmente jogar suas dúvidas num chat.

Numa conversa comum com uma LLM, uma síntese ruim morre com o chat. Você lê, desconfia, segue em frente. Na wiki, não: a interpretação errada vira página, a página persiste, e a próxima consulta volta a ler exatamente aquela interpretação. O erro se reforça sozinho.

Aconteceu comigo, na mesma página do índice de busca. Um agente encontrou o que parecia ser um defeito no script de consulta — devolvia resultado vazio em silêncio, registrado como um problema em aberto. Horas depois, corrigindo o script, percebi a causa real:

“Correção de uma afirmação minha: eu registrei que o script devolvia ‘lista vazia em silêncio’. Não devolvia — imprimia o uso no stderr e saía. Quem silenciou foi o meu arnês de benchmark, que capturava só o stdout e leu saída vazia como ‘o motor não encontrou nada’. O erro de leitura era meu, não do script.”

A página não apagou o registro errado. Ela guardou a correção ao lado dele, com data e causa raiz nomeada — inclusive nomeando o próprio erro, não só o do script.

Isso não acontece por acidente. É o motivo de eu insistir num conjunto de coisas que, vistas de fora, parecem mania de testador: raw/ que nunca muda, guardando a fonte original; related_sources e date_ingested em todo frontmatter, para eu conseguir voltar e checar de onde veio cada afirmação; e, principalmente, uma regra que o schema impõe e que eu não abro mão:

Automatizar a manutenção não é delegar autoridade epistemológica ao modelo.

O agente pode perceber uma contradição. Ele não decide qual versão da realidade fica. Isso é regra escrita, não hábito — o SCHEMA.md proíbe fechar um [!contradiction] ou um [!outdated] sem confirmação minha.

Build verde não é produto perfeito

Uma coisa que aprendi rápido, trabalhando com qualidade de software: existe uma diferença enorme entre restrição rígida e dívida de qualidade.

Frontmatter correto, links íntegros, schema respeitado — isso é hard constraint. Ou passa, ou não passa. O resultado é um VALIDATION: PASS e ponto final.

Conceito incompleto, link que falta, enriquecimento possível — isso é dívida. E dívida não trava o build. Ela vira contador.

Na última rodada de lint, em 2026-08-18: 354 gaps abertos em 262 páginas, três fechados no mesmo dia, contador em 351 — e VALIDATION: PASS ao lado.

As duas coisas convivendo é saudável, não é contradição. build verde não significa produto perfeito. VALIDATION: PASS não significa conhecimento completo. Significa que a estrutura está íntegra o suficiente para eu continuar trabalhando em cima dela sem risco de corromper o que já existe.

E o mesmo raciocínio vale para as marcações de dúvida. A wiki tem 227 callouts [!contradiction], 574 [!gap] e 41 [!outdated]. Só o número, sem contexto, soa mal.

Mas registrar 227 contradições não é criar 227 contradições. Antes de existir o callout, essas inconsistências já estavam lá — só que invisíveis. Agora têm representação explícita e podem entrar numa fila de resolução.

É a mesma lógica de warning de compilador e de débito técnico: não enxergar o problema nunca foi o mesmo que não ter o problema.

O que quebrou

Nem tudo foi limpo. Alguns padrões de falha se repetiram o suficiente para eu aprender com eles.

Página classificada no lugar errado. Aconteceu mais de uma vez: um conteúdo que devia estar numa área acabou registrado em outra, e só apareceu quando fui procurar por ele e não achei. A correção existe no histórico — um commit inteiro só de mover página para a área certa.

Schema que não aguentou o próprio crescimento. O log de atividade da wiki começou como um arquivo único. Cresceu até virar pesado demais para caber em qualquer contexto de consulta, e teve que ser fatiado por dia. Isso não é falha do agente — é o schema tendo que evoluir porque a realidade passou do desenho original.

Contradição real entre o que foi escrito e o que foi implementado. A mesma página do índice de busca guarda duas contradições nunca fechadas, de propósito. Uma projeta indexação incremental para dez mil documentos, quando o acervo medido tem uma ordem de grandeza a menos — decisão de desenho que ficou obsoleta e ninguém apagou o registro, só marcou.

A outra nasceu de um commit cujo próprio título diz “corrige afirmações erradas”: a página descrevia um comportamento controlado por feature flag que, na prática, nunca existiu — rodou sempre, sem flag.

Página quase-duplicada. Duas fontes parecidas, ingeridas em dias diferentes, quase criaram duas páginas de conceito para a mesma ideia — uma com o nome no singular, outra no plural, cada uma puxando parte das fontes que deviam estar juntas.

O lint pega isso quando o slug diverge o suficiente para escapar da checagem automática. Quando não pega, sou eu quem encontra ao consultar e estranhar por que a resposta veio pela metade.

Manutenção não é o mesmo que ausência de esforço. O agente organiza. Quem lê os 72 relatórios de lint acumulados desde maio e decide o que vale corrigir agora sou eu. Isso não aparece em nenhum número da seção anterior, e é o tipo de trabalho que fica invisível justamente porque funciona — até o dia em que eu paro de fazer e o contador de gaps só cresce.

Custo de contexto. Cada fonte nova que entra numa página aumenta o que qualquer consulta futura precisa carregar para responder sobre aquele tema. Não bati o pé nessa métrica ainda com o rigor que os outros números têm — fica como pendência honesta, não como número que eu vou inventar.

Nenhum desses casos é dramático sozinho. Juntos, mostram um padrão: o agente erra devagar, no detalhe estrutural, não na frase solta. E é exatamente aí que o schema e o lint entram.

Por que cada regra existe

O SCHEMA.md já passou por 11 revisões. Cada uma nasceu de uma dor real, não de antecipação.

A regra do log fatiado por dia existe porque o log de um arquivo só ficou grande demais para qualquer consulta razoável.

O campo específico para diferenciar projetos pessoais dentro da mesma área existe porque, sem ele, duas iniciativas distintas se misturavam no mesmo espaço. O agente perdia a referência de qual projeto cada página pertencia.

E a extensão do schema para registrar memórias — aprendizados que não são fonte, nem conceito, nem entidade — existe porque eu tentei encaixar esse tipo de conteúdo nos tipos que já existiam. Encaixava mal.

Nenhuma dessas regras nasceu de eu sentar e desenhar o schema perfeito antes de usar. Nasceram de eu bater a cara na versão anterior. O schema de hoje é uma cicatriz de cada erro que já cometi organizando isso.

Por fim

A tese que sustenta essa trilha inteira é essa: uma LLM Wiki não elimina a manutenção de conhecimento; ela muda quem faz a manutenção — e cria a necessidade de governar o agente que a executa.

Demorei para perceber a diferença entre “a manutenção virou automática” e “a manutenção acabou”. São frases parecidas e significam coisas completamente diferentes.

A primeira é o que eu tenho hoje: um agente que organiza, um schema que restringe, um lint que mede a dívida e um humano — eu — que continua decidindo o que é verdade quando duas fontes discordam. A segunda seria eu me demitindo do processo, e isso eu nunca tive intenção de fazer.

No próximo artigo eu mostro o repositório que sustenta tudo isso na prática — o que entra num kit mínimo e o que só faz sentido depois que a sua wiki já dói do jeito que a minha doeu.

Espero que este artigo tenha sido útil.