Compound Engineering: O Loop Que Transforma Experiência em Ativos
Plan → Work → Review. Todo engenheiro faz isso.
O que quase ninguém faz é o quarto passo. Sem ele, cada sessão de trabalho é descartada no momento em que você fecha o terminal. A decisão difícil que você tomou — "escolhemos X porque Y, e Z falharia pelo motivo W" — fica inacessível seis meses depois.
O problema
Engenheiros acumulam experiência mas raramente a convertem em conhecimento estruturado. Uma decisão difícil tomada em março fica inacessível em setembro, quando o mesmo trade-off reaparece.
A documentação convencional registra o o quê: changelogs, READMEs, comentários. O por quê e o o que eu faria diferente — as partes com valor reutilizável — se perdem no contexto de uma sessão que já terminou.
Os quatro passos
Plan. Definir escopo e requisitos antes de agir. Planos vivem como arquivos Markdown versionados, não na sua cabeça. A regra: nenhuma linha de código antes do escopo estar claro.
Work. Implementar conforme o plano. Código, docs, configuração — tudo rastreável, commitado com prefixos convencionais. Divergências do plano são registradas, não ignoradas.
Review. Um quality gate explícito. Os testes passam? Decisões arquiteturais viraram ADRs? Blockers foram identificados e rastreados? A documentação está atualizada? Review não é só code review — é validar que o conhecimento da sessão foi capturado.
Compound. O passo mais subestimado. Extrair o conhecimento da sessão para ativos permanentes: notas Zettelkasten, arquivos em docs/solutions/, skills do agente, ADRs, artigos. Sem esse passo o loop não rende juros — é apenas trabalho.
Por que torná-lo explícito
A alternativa óbvia é "documentar quando for necessário". Nunca é necessário no momento; a urgência do próximo ticket vence sempre. O resultado é conhecimento perdido de forma sistemática, não ocasional.
Uma wiki centralizada captura o o quê e tende a virar arquivo morto — sem versionamento junto ao código, sem conexões emergentes entre conceitos.
Tornar o Compound um passo obrigatório do loop cria accountability: a sessão não está "pronta" até o conhecimento estar capturado.
O que custa
Você ganha um efeito composto real. Depois de seis meses de loops, decisões passadas ficam acessíveis como um grafo navegável. O onboarding acontece pela base de conhecimento em vez de "pergunta para o fulano". Artigos emergem das notas permanentes sem trabalho extra.
Você paga cerca de 15 a 30 minutos de Compound a cada quatro horas de Work, mais uma resistência psicológica genuína — o passo parece opcional exatamente quando você está acelerado. E ele pode calcificar em burocracia se o template ficar mais importante que o conteúdo.
Como isso falha
O loop degenerado: Plan → Work → Plan, sem Review e sem Compound. Parece produtivo enquanto acumula dívida de conhecimento. O sintoma é refazer a mesma decisão em sessões diferentes sem saber por quê.
O Compound vira arquivamento. Escrever "o que foi feito" em vez de "o que foi aprendido". O teste: se a nota não contém trade-offs nem "o que eu faria diferente", não é Compound — é changelog.
Notas sem conexões. Captura sem grafo. O valor de um Zettelkasten emerge dos links, não das notas isoladas. Uma nota permanente com menos de duas conexões está isolada e não contribui para o efeito composto.
O que eu aprendi
O Compound é muito mais fácil logo depois do Review, com o contexto ainda quente. Agendá-lo para "depois" quase sempre significa nunca.
Resistência ao Compound geralmente sinaliza que o plano estava mal definido — não havia critério claro de "sessão completa". Definir esse critério no Plan reduz o atrito no fim.
E ferramentas importam menos que o hábito. Esse loop funcionou com Markdown, Logseq e Cursor. Funcionaria com Obsidian, Notion e vim. O que quebra o loop é a ausência do passo, não a escolha da ferramenta.
O sinal de que está funcionando: você consulta uma nota que escreveu quatro meses atrás antes de tomar uma decisão, e ela já tinha antecipado o trade-off que você estava prestes a ignorar.