Capturar notas é fácil. Destilar é a parte que dói.

Já faz uns bons anos que eu tento manter um sistema de notas. Comecei com caderno. Depois veio o OneNote, depois o Notion, depois o Obsidian — e ainda teve uma temporada de arquivos de texto soltos numa pasta qualquer.

Nenhum durou. E eu culpava a ferramenta, então trocava de ferramenta.

Até que eu esbarrei no Segundo Cérebro, do Tiago Forte. Esse pegou. É o que eu uso até hoje e é o que funciona comigo.

Mas tem uma parte dele que eu vinha deixando para trás…

O método que pegou

O Segundo Cérebro cabe em quatro letras: CODE. Capture, Organize, Distill, Express — capturar, organizar, destilar e expressar.

Capturar é salvar o que chamou sua atenção. Um artigo, um trecho de livro, o print de uma discussão em grupo de desenvolvedores.

Organizar é decidir onde aquilo mora, pensando em quando você vai precisar daquilo de novo.

Essas duas eu faço bem. Capturar virou reflexo. Organizar eu já resolvo quase no automático.

Destilar é o passo seguinte: voltar na nota, tirar o que sobra, marcar o que importa, ligar com o que você já sabia. Expressar é usar aquilo para produzir alguma coisa — um artigo, uma decisão técnica, uma resposta melhor numa reunião.

E é aqui que eu tenho que ser honesto.

Destilar é a parte que dói

Eu capturava e organizava. Destilar e refinar, quase nunca.

A nota entrava, ficava lá bonitinha na pasta certa e nunca mais era tocada. Sem tópico, sem resumo, sem link para nenhuma outra nota. Um arquivo morto num lugar organizado.

Sabe qual é o problema disso? Nota que não é destilada não vira conhecimento. Ela vira arquivo.

E não é preguiça no sentido de não querer trabalhar. É que destilar é uma tarefa que nunca é urgente. Sempre tem algo com prazo na frente dela. No fim de semana, quando sobra tempo, você olha para trinta notas cruas acumuladas e simplesmente não começa.

Eu convivi com isso por anos. Achava que era falta de disciplina minha — e talvez seja mesmo, em parte. Mas quando um passo do processo depende de força de vontade toda semana, o problema não é só o seu caráter. É o desenho do processo.

Foi aí que eu esbarrei numa ideia que me fez olhar para o problema de outro jeito.

Sobre a LLM Wiki do Karpathy

O Andrej Karpathy publicou um gist curto descrevendo o que ele chama de LLM Wiki. A ideia toda cabe em poucos parágrafos, e é o tipo de coisa simples que a gente lê e pensa: por que eu não fiz isso antes?

Em vez de manter uma pilha de notas cruas, você mantém uma wiki. E em vez de você fazer a manutenção dela, quem faz é uma LLM.

O funcionamento é mais ou menos assim:

1. Você joga uma fonte para dentro — um artigo, um vídeo, uma transcrição, um documento de trabalho.
2. O agente lê a fonte e cria uma página para ela, registrando de onde aquilo veio.
3. Ele identifica os conceitos e as entidades que aparecem ali e cria ou atualiza a página de cada um.
4. Ele liga as páginas entre si, para que o conceito aponte para as fontes que falaram dele.

Repare no que acabou de acontecer. Capturar continua sendo meu. Expressar continua sendo meu, e isso é inegociável.

Destilar deixou de ser um item de fim de semana. Virou parte da ingestão.

A nota não fica crua esperando um sábado livre em que eu esteja com paciência. Ela entra já ligada ao resto — e quando eu volto no conceito seis meses depois, ele acumulou as quatro fontes que passaram por ali nesse meio tempo.

O agente destila, eu decido

Eu venho rodando isso há alguns meses e a wiki cresceu. Quando fui medir para escrever este artigo, ela tinha 922 páginas de conteúdo, e 473 delas já tinham mais de uma revisão — ou seja, mais da metade não nasceu e morreu no mesmo dia, foi tocada de novo depois. Guardo os detalhes dessa medição para o próximo artigo da série.

Só que crescer não é a parte interessante. A parte interessante é o que o agente não tem permissão de fazer.

Quando ele encontra duas fontes que se contradizem, ele não escolhe a vencedora. Ele registra a contradição na página e me deixa decidir. Quando ele percebe que falta informação para fechar um raciocínio, ele não preenche o buraco com o que parece plausível. Ele marca o buraco.

Isso é uma decisão de projeto, não um detalhe de implementação:

Automatizar a manutenção do conhecimento não significa entregar ao modelo a autoridade de decidir o que é verdade.

O agente pode detectar uma contradição. Não significa que ele deva escolher qual versão da realidade fica.

Falha silenciosa é o pior tipo de falha

Trabalho com qualidade de software e essa parte me pegou de um jeito que eu não esperava.

Um agente que organiza conhecimento sem contrato nenhum não falha com barulho. Ele falha calado. Você pede para ele consolidar uma fonte, ele infere uma coisa plausível, escreve com toda a segurança do mundo — e aquilo vira página. Na semana seguinte, aquela página é a fonte que você consulta.

Uma invenção que ninguém contestou vira conhecimento persistente. E você nem sabe em qual página ela está.

Por isso os marcadores de contradição e de lacuna importam tanto. Uma contradição registrada não é uma contradição criada — ela já estava lá, só que invisível. É a mesma lógica de débito técnico, que eu já comentei por aqui: não enxergar o problema nunca foi o mesmo que não ter o problema.

O que mudou é que agora ele tem representação explícita e pode entrar numa fila de resolução.

De onde isto veio

Nada disto aqui é invenção minha, e eu acho importante deixar a linhagem clara.

O método é do Tiago Forte, no Segundo Cérebro. O conceito de deixar a manutenção com a LLM é do Karpathy, no gist da LLM Wiki. E a implementação que eu usei como ponto de partida é a wiki-wonka, da Coopera Code, publicada sob licença MIT.

Eu montei um repositório público a partir dela, o Anvilore: as skills traduzidas para português, um schema menor, um validador com testes e as regras que eu fui aprendendo na marra. É obra derivada e o crédito está no LICENSE e no README, como a licença exige.

Se você quiser experimentar sem herdar a complexidade da minha wiki, é por ali que eu começaria.

Por fim

Trocar de ferramenta nunca resolveu o meu problema, porque o meu problema nunca foi a ferramenta. Era um passo do processo que dependia de eu estar disposto todo fim de semana.

Nos próximos artigos eu quero mostrar os números com mais calma — o que a wiki acumulou de verdade, o que envelheceu mal e onde o agente errou de um jeito que demorei para perceber. Porque delegar manutenção cria modos de falha novos, e fingir que não cria seria desonesto.

Enquanto isso, fica a pergunta que eu levei anos para me fazer: quantas das suas notas você abriu uma segunda vez?

Espero que este artigo tenha sido útil.