Revisando Saídas em Escala
Aqui está o problema honesto: quando agentes estão escrevendo centenas de linhas em várias tarefas, você não consegue ler cada linha do jeito que revisaria um diff de dez linhas. Fingir que consegue leva ou a carimbar sem olhar (você aprova sem verificar) ou à paralisia (você nunca confia em nada). Nenhum dos dois entrega resultado.
O caminho é travar em algumas camadas em vez de ler tudo:
- Testes são o piso. Nenhuma saída de agente entra em merge sem os testes relevantes verdes e o verificador de tipos limpo. Isso é inegociável e é automático — a máquina faz essa parte.
- Revise pontualmente as partes de risco. Você não consegue ler tudo, então leia as partes onde o raio de impacto é alto: qualquer coisa que toque autenticação, dinheiro, exclusão de dados ou chamadas externas. Passe os olhos no resto atrás dos sinais de alerta do capítulo sobre construir funcionalidades — arquivos que não deveriam ter sido tocados, coisas apagadas silenciosamente, um pedido pequeno que gerou um diff enorme.
- Leia o diff, não o código inteiro.
git diff --statconta em segundos o quê mudou e o quanto. Uma tarefa delimitada a um módulo que mostra mudanças em seis é um sinal para olhar com mais cuidado, antes mesmo de ler uma única linha. - Rode. Uma suíte de testes verde não é um app funcionando. Clique na coisa. A checagem final é sempre a mesma de todos os outros capítulos: isso realmente faz o que você pediu, na sua frente?
A delimitação compensa duas vezes aqui. Uma tarefa que você delimitou de forma apertada produz um diff que você consegue de fato revisar; uma tarefa que você soltou produz um que você não consegue. O problema da revisão é, em grande parte, resolvido lá atrás, no briefing.