🎬 Checkpoints & review fluido

Quando o agente trabalha sozinho — em AFK, em PRs, em filas de tarefas — sobra uma pergunta: pra que serve o review? Matt Pocock dá uma resposta dupla. A primeira função é óbvia: o review é um portão (gate) de coisas perigosas — vazamento de segredos, brechas de segurança, mudanças que poderiam, por exemplo, expor o código-fonte do próprio Claude Code. Aqui o review é uma barreira de proteção, e ela importa.

Mas tem uma segunda função que quase todo mundo perde — e Pocock insiste nela: o review te dá insight no seu próprio sistema. Ao ver o agente trabalhar, você descobre como o seu harness (o encanamento que produz o código) se comporta na prática. É observabilidade: você melhora o harness com o tempo, e pra isso precisa ver o que está acontecendo. Nas palavras dele: "estamos revisando não só o código, mas o sistema que produz o código." O erro comum é tratar review só como caça-bugs e, ansioso por velocidade, cortar tudo — você ganha tempo e fica cego. Sem observabilidade, você delega às cegas e nunca afina o motor que produz tudo.

Imagine a linha do tempo de uma tarefa: telemetria detecta um bug → vira uma issue → o agente investiga → propõe o conserto → abre o PR → entra no código (merge). Em cada seta dessas você poderia colocar um checkpoint humano. A pergunta de Pocock é: onde ele rende mais? A resposta é a frase-chave da trilha: "push human-in-the-loop checkpoints further toward the final output" — empurre os pontos de aprovação humana cada vez mais pra direita, em direção à saída final.

Por quê? Porque um checkpoint no começo trava todo o resto: nada anda sem você. Quanto mais tarde o checkpoint, mais trabalho a IA já adiantou sozinha quando chega até você — e mais cada minuto seu rende. O gargalo deixa de ser você. O erro comum é o oposto: gente que revisa cada micro-passo (cada comando, cada arquivo) e, sem perceber, reconstrói o trabalho manual que queria delegar. Lembre da fila do módulo 4.4: você é o rei que prioriza e aprova o resultado — não o soldado que checa cada movimento.

O objetivo, diz Pocock, é remover checkpoints onde der — com cuidado. Nem toda mudança merece o mesmo escrutínio. O exemplo dele é claro: um PR que é só uma refatoração interna — reorganiza o código, mas não muda o comportamento visível — é candidato natural a ter o checkpoint removido. A própria IA pode avaliar e dizer: "isto não precisa de revisão humana, é só limpeza interna."

A regra prática é classificar pelo raio de impacto. Baixo risco (refactor que não muda comportamento, ajuste de texto, atualização de dependência segura) → bom candidato a auto-merge. Alto risco (qualquer coisa que toque segurança, dados de usuário, dinheiro, ou mude comportamento que o cliente vê) → mantenha o humano. O erro comum é binário: ou revisar tudo (gargalo) ou nada (perigoso). O caminho é o gradiente: comece revisando muito e vá soltando os de baixo risco conforme ganha confiança no sistema. Isso conecta com o módulo 4.5 (telemetria → issue → fix → tag auto-merge ou pinga o humano): a decisão "auto-merge ou humano" é exatamente este julgamento de risco.

Aqui mora o paradoxo que Pocock levanta com uma frase afiada: "who reviews the AI that says it's fine?" — quem revisa a IA que diz que está tudo certo? Se você deixa a própria IA decidir que um PR "não precisa de revisão", você criou um juiz que julga o próprio trabalho. Não dá pra confiar nisso de olhos fechados. A solução não é desligar a auto-avaliação — é auditar uma amostra. Você ainda precisa checar alguns dos PRs que o agente declarou ok, e ir melhorando esse julgamento com o tempo.

É a mesma ideia do tópico 1, agora em ação: "we're reviewing not just the code, but the SYSTEM that produces the code." Você não está só conferindo aquele PR específico — está calibrando o sistema de julgamento do agente. Toda vez que você pega um "tá ok" que na verdade não estava, você ajusta a skill, o prompt ou a regra de auto-merge pra acertar mais da próxima vez. O erro comum é o salto de fé: dar auto-merge total sem nunca amostrar. Sem amostragem você não tem como saber se o agente está calibrado — só descobre quando um erro grave já passou.

Este é o truque preferido de Pocock para tornar o review prazeroso, e ele se aplica a qualquer mudança de front-end. A ideia: em vez de te entregar um PR com 30 arquivos alterados pra você ler linha por linha, a própria IA grava um vídeo walkthrough — ela anda pela mudança usando a aplicação de verdade (clica nos botões, navega nas telas novas, mostra o antes/depois). Depois ela chama um TTS e narra por cima, explicando o que mudou. O PR passa a ter, anexado, um vídeo da coisa funcionando.

Por que isso é tão forte? Porque seu cérebro processa um vídeo narrado muito mais rápido do que um diff de código. Você confere o comportamento (funciona? está bonito? é o que eu pedi?) em segundos, em vez de inferir o comportamento a partir do código. Pocock resume o espírito de tudo isso: "optimize for human review, make it faster — we're scratching the surface." Otimize para o review humano, deixe-o mais rápido — estamos só arranhando a superfície do que dá pra fazer. O erro comum é achar que isso é firula: na prática, é o que mantém você capaz de aprovar muitos PRs por dia sem se esgotar.

A última peça é otimizar o review humano em si — porque, como diz Pocock, "o GitHub não foi feito pra era agêntica". A ferramenta foi pensada pra poucos PRs grandes de humanos, não pra dezenas de PRs pequenos de agentes. A jogada esperta: em vez de revisar 20 fixes pequenos um por um, peça pra IA gerar um HTML estilo "teach skill" (lembra da trilha 3?) que destila os padrões comuns daqueles bugs — o que se repetiu, qual a causa raiz, o que aprender. Você revisa o resumo, não as 20 páginas.

Repare o que isso faz: o objetivo é "otimizar pra você melhorar a si e ao sistema". Você não só aprova mais rápido — você aprende o padrão dos erros e ajusta o harness pra eles não acontecerem mais. É o tópico 1 fechando o ciclo: revisar o sistema, não só o código. O erro comum é tratar review como tarefa burra e repetitiva; aqui ele vira um instrumento de melhoria contínua. Use o diagnóstico abaixo para decidir, em qualquer lote de PRs, como acelerar o seu review — copie e cole quando o backlog encher:

REVIEW FLUIDO — como acelerar o review dos PRs do agente

1) CLASSIFIQUE por risco antes de abrir o diff:
   [ ] baixo risco (refactor sem mudar comportamento, texto, dep) -> auto-merge
   [ ] alto risco (seguranca, dados, $, comportamento visivel) -> humano

2) EMPURRE o checkpoint pra direita:
   [ ] o humano aprova perto da SAIDA, nao em cada micro-passo

3) PECA o walkthrough em qualquer mudanca de front-end:
   "Grave um video navegando pela mudanca e narre com TTS o que mudou;
    anexe ao PR." -> reviso comportamento em segundos, nao diff em minutos

4) AGREGUE lotes em vez de revisar 1 a 1:
   "Em vez de 20 fixes soltos, gere um HTML tipo teach skill com os
    padroes comuns desses bugs (causa raiz + o que aprender)."

5) AUDITE a auto-avaliacao da IA:
   [ ] amostre alguns PRs que a IA disse "ta ok"  (quem revisa a IA?)
   [ ] ajuste skill/prompt/regra de merge -> revise o SISTEMA, nao so o codigo