♻️ Sistemas auto-melhoráveis

Existe um mito sedutor: "se eu usar o modelo mais inteligente (e mais caro), ele vai achar aqueles bugs profundos que nenhum outro acha". Na conversa, contou-se que um modelo encontrou bugs profundos e falhas de security que outros modelos não tinham visto. A reação fácil é: "viu? precisa do modelo top". Pocock discorda na raiz. Nas palavras dele: "você poderia descobrir esses bugs com modelos mais baratos se olhasse nos lugares certos e desse a ele o prompt/harness certo". Traduzindo: o que faltava aos "outros modelos" não era inteligência — era direção.

Isso conecta direto com o que você viu na Trilha 1 (Economia de tokens): um harness bom deixa um modelo "mais burro" fazer o mesmo trabalho. Aqui a ideia é a mesma aplicada à descoberta de defeitos. Em vez de pagar caro por um modelo gênio rodando uma vez, você monta um sistema que coloca um modelo simples no lugar certo, repetidamente. O porquê importa: modelo caro é um custo que cresce a cada chamada; um sistema bem-direcionado é um ativo que rende todo dia. O erro comum é confundir "achou um bug difícil" com "preciso sempre do modelo difícil" — quando o que achou o bug, de fato, foi onde e como você olhou.

A receita concreta de Pocock: rode um cron diário de security review que, a cada dia, checa uma parte nova do repositório, usando um modelo relativamente simples. A palavra-chave é rotativo: você não tenta varrer o projeto inteiro de uma vez (caro, raso e estourando o context window). Você fatia. Hoje a pasta de autenticação; amanhã a de pagamentos; depois a de uploads. Em poucas semanas o repo inteiro foi auditado — e o ciclo recomeça, pegando o que mudou.

Por que agendado e não "quando eu lembrar"? Porque a lição que Pocock tira de um incidente é direta: "o que você aprendeu? Que há problemas de segurança no seu código — você deveria ter algo que roda e checa por mais no futuro." Segurança não pode depender da sua memória num dia corrido. O porquê do modelo simples: review fatiado é tarefa pequena e bem-escopada — exatamente onde o modelo barato basta (tópico 1). O erro comum é montar um cron que revisa o repo todo de uma vez: fica caro, vira ruído e ninguém lê o relatório gigante. Pequeno, diário, rotativo, acionável.

Abaixo, o artefato copiável: uma linha de crontab que dispara, todo dia às 6h da manhã, um agente headless de security review apontado para a "fatia do dia". Cole no seu crontab (crontab -e) e ajuste o caminho do repo:

# Edite com:  crontab -e
# Roda TODO DIA às 06:00 — checa uma fatia rotativa do repo (dia-do-mês % nº de pastas).
0 6 * * * cd /caminho/do/repo && DIRS=(auth payments uploads api db) && TARGET=${DIRS[$(( $(date +\%d) \% ${#DIRS[@]} ))]} && claude -p "Faça um SECURITY REVIEW so da pasta ./$TARGET. Liste cada falha (arquivo:linha), severidade (alta/media/baixa) e a correcao sugerida. Se nada grave, responda 'OK'. Saida em markdown." --model claude-haiku-4-5 --allowedTools "Read,Grep,Glob" >> ~/security-reviews/$(date +\%F)-$TARGET.md 2>&1

Aqui a auto-melhoria deixa de ser proativa (o cron) e vira reativa, mas automatizada. O exemplo de Pocock: um bug de telemetria aparece numa ferramenta como o Sentry. Em vez de você ler, copiar e abrir um chamado na mão, o sistema cria uma issue automaticamente e a marca com um label (etiqueta) tipo agent:explore. Esse label dispara um agente — exatamente o padrão de fila do módulo 4.4.

O agente então retorna dado estruturado: dá pra corrigir já, ou precisa de um humano? Se for direto, ele implementa, abre o PR, e o fluxo segue para review — eventualmente com uma tag de auto-merge (entra sozinho) ou um ping pra você decidir. A frase que organiza tudo isso é de Pocock: "empurre os checkpoints de human-in-the-loop o mais para perto possível do resultado final." Ou seja: a máquina faz o caminho todo; você só entra perto da linha de chegada, onde sua atenção rende mais. O erro comum é deixar o pipeline fazer auto-merge de tudo — sem nenhum gate humano nas mudanças que mexem em comportamento, você troca trabalho manual por risco silencioso.

Essa é a virada de chave do módulo, e Pocock resume numa imagem que gruda: "se alguém vive roubando sua bike, talvez compre um cadeado." Corrigir o bug que apareceu é tratar o sintoma. A pergunta que de verdade melhora o sistema é sobre a causa raiz (root cause): por que esse bug existiu tanto tempo sem você notar? O que faltou no seu processo — um teste, uma revisão, um lint — para que ele passasse batido até virar incidente?

Repare na diferença de nível. "Achei um bug de security e corrigi" para na bike. "Há falhas de security no meu código, então vou montar algo que roda e checa por mais no futuro" instala o cadeado — é literalmente o cron do tópico 2 nascendo de um incidente. Cada bug, em vez de só um conserto, vira uma pergunta: que guarda-corpo do sistema deixou isso passar? A resposta vira test suite, review automatizado ou refactor. O erro comum é parar feliz no fix: você fecha a issue, sente que resolveu — e o mesmo tipo de bug volta por outra porta, porque o cadeado nunca foi comprado.

Juntando tudo: um sistema auto-melhorável é feito de vários laços que se reforçam. Pocock nomeia três ingredientes concretos: test suites (que pegam regressões antes de chegarem ao usuário), human reviews (que dão insight no sistema, não só no código) e refactor (que reduz a chance de o próximo bug aparecer). Cada incidente alimenta esses laços: virou teste, virou checklist de review, virou uma parte mais limpa do código.

O detalhe crítico — e aqui ele cruza com o módulo 4.4 (Loops × Filas) — é que "auto-melhorável" não significa "deixa um loop infinito rodando sozinho e some". Significa montar gatilhos (cron, telemetria, label) que colocam tarefas numa fila, e laços de feedback que tornam cada passagem melhor que a anterior. Você continua sendo o rei: prioriza, revisa os pontos perigosos, ajusta os gatilhos. O erro comum é fantasiar um sistema 100% autônomo que se conserta para sempre sem supervisão — isso não existe; o que existe é um sistema que faz o trabalho repetitivo e te chama nos momentos que importam.

A tese que fecha o módulo é a frase mais importante de Pocock aqui: "revise não só o código — revise também o SISTEMA que produz o código." Na era agêntica, quem escreve a maior parte do código é o agente. Então seu foco de revisão sobe um andar: menos "essa linha está certa?" e mais "o processo que gerou essa linha é confiável?". Os prompts, as skills, os crons, os gates de review — é esse encanamento que, afinado, faz o próximo bug nem nascer.

Isso também responde uma pergunta perigosa que aparece no próximo módulo (4.6): "quem revisa a IA que diz que está tudo bem?" Resposta: você, revisando o sistema. Por isso vale checar, de vez em quando, alguns PRs que o agente garantiu estarem ok — não por desconfiança paranoica, mas para melhorar o sistema com o tempo. Abaixo, o resumo prático em forma de checklist copiável — rode-o sempre que um bug escapar, para transformar o conserto em melhoria de sistema:

Bug escapou? Antes de fechar a issue, COMPRE O CADEADO:
[ ] CAUSA RAIZ — por que esse bug existiu tanto tempo sem ninguém notar?
[ ] TESTE — adicionei um teste que pegaria esse caso na próxima vez?
[ ] DETECÇÃO — meu cron de security/review olharia essa parte? Se não, ajusto o rodízio.
[ ] PROCESSO — que gate (review, lint, label) deixou isso passar? Reforço ele.
[ ] SISTEMA — revisei o código OU o sistema que produz o código? (era pra ser os dois)
Se você só corrigiu o bug, comprou outra bike. Instale o cadeado.