Quando o review vira botão de fix, o tamanho do lote importa

O botão "Fix with Copilot" parece pequeno.

Mas ele troca uma pergunta bem comum do code review. Antes era algo como: "eu concordo com esse comentário?". Agora começa a virar: "eu entrego esse pedaço de trabalho para um agente resolver?".

Essa troca parece sutil. Não é.

Porque o problema real não é se a IA consegue aplicar uma sugestão simples. Muitas vezes consegue. O problema é saber qual pacote de comentários, testes quebrados e ajustes de CI ainda cabe dentro de um diff que um humano consegue revisar sem fingir que revisou.

E esse, para mim, é um dos skills mais subestimados de quem está usando agente de código hoje: montar lotes bons.

Automação ajuda muito quando o trabalho é chato e localizado

Tem um tipo de tarefa que cansa mais do que deveria:

ajustar nome de variável depois de review;
aplicar feedback localizado em um componente;
corrigir lint;
investigar teste quebrado por detalhe de setup;
refazer uma pequena validação depois que o CI reclamou;
atualizar teste porque o comportamento esperado já mudou.

Nada disso é "nobre". Também não é sempre trivial. Mas é o tipo de coisa que interrompe fluxo, principalmente em time pequeno.

Você está pensando em regra de negócio, alguém comenta um detalhe de nomenclatura. Você está revisando arquitetura, o CI cai por snapshot quebrado. Você está tentando fechar uma entrega, aparece uma falha de Actions que exige ler log, reproduzir, corrigir e subir outro commit.

Quando um agente consegue pegar uma falha de CI, investigar log, propor correção e mandar o diff para revisão, isso economiza energia mental. Quando um comentário de review pode virar uma tarefa delegável, melhor ainda.

Eu não vejo isso como "a IA substituiu o dev". Vejo como uma fila de interrupções pequenas saindo da cabeça de quem está tentando manter contexto.

Só que tem uma pegadinha.

Quanto mais fácil fica delegar, mais fácil fica delegar coisa demais de uma vez.

O lote grande parece eficiente até virar um diff impossível

Imagina um PR com dez comentários:

renomear uma função;
simplificar uma condição;
corrigir um teste;
trocar uma dependência;
rever um comportamento de erro;
ajustar copy;
melhorar tipagem;
refatorar um hook;
mexer no workflow do CI;
alterar uma regra de validação.

É tentador selecionar tudo e mandar: "resolve esses comentários".

Parece produtivo. Talvez até seja, por alguns minutos. O agente vai voltar com um diff, talvez passando nos testes, talvez com uma explicação convincente.

Mas agora o seu review ficou pior.

Você não está mais revisando "a sugestão do comentário 3". Está revisando um pacote que mistura estilo, teste, refactor, comportamento, dependência e pipeline. Se algo estranho entrar no meio, vai ser mais difícil perceber. Se o diff ficar grande, a chance de você revisar no piloto automático aumenta bastante.

Esse é o custo escondido do lote grande: ele transforma uma automação útil em dívida de revisão.

Não adianta o agente economizar 20 minutos de execução se ele cria um diff que exige 40 minutos de auditoria desconfiada.

Agrupe por risco, não por quantidade

A regra prática que eu usaria é simples: agrupe por tipo de risco.

Não por quantidade de comentários. Não por ordem em que apareceram no PR. Não por "aproveitar que o agente já está aberto".

Por risco.

Um lote bom pode ser:

"aplique apenas comentários de lint, formatação e nomes";
"corrija os testes quebrados sem mudar comportamento de produção";
"faça o refactor local deste módulo sem tocar contrato externo";
"investigue a falha do CI e pare se precisar alterar workflow, secret ou dependência";
"ajuste a validação deste formulário, mantendo a API igual".

Percebe a diferença?

O lote já diz o que pertence e o que não pertence ao trabalho. Isso ajuda o agente, mas ajuda principalmente você. Na hora de revisar, dá para perguntar: "ele respeitou a fronteira?".

Se o lote mistura tipos de risco, a revisão vira adivinhação.

Um comentário de copy e um comentário de arquitetura não deveriam cair no mesmo pacote só porque estão no mesmo PR. Uma falha de lint e uma falha intermitente de integração também não são a mesma coisa. Uma sugestão de renomear variável não tem o mesmo peso de alterar regra de negócio.

Quando tudo vira "fix", o botão fica perigoso.

O melhor lote é aquele que você consegue revisar rápido

Eu gosto de uma pergunta bem pé no chão:

Vou conseguir revisar esse diff em cinco minutos e saber se ele está certo?

Se a resposta for não, o lote provavelmente está grande demais ou misturado demais.

Cinco minutos não é uma lei. Tem mudança que exige mais cuidado. Mas a pergunta força um critério saudável: o resultado precisa ser auditável.

Um diff auditável tem algumas características:

toca poucos lugares;
tem uma intenção clara;
separa mudança mecânica de mudança de comportamento;
vem com teste ou validação compatível com o risco;
não resolve "de brinde" problemas que ninguém pediu;
deixa explícito onde o agente parou.

Esse último ponto costuma separar um fluxo bom de um fluxo perigoso.

Agente bom não é o que sempre continua. Às vezes é o que para e diz: "para resolver isso eu preciso mudar contrato de API" ou "essa falha parece depender de credencial que não tenho" ou "o teste está cobrindo comportamento ambíguo".

Isso parece menos mágico, mas é bem mais confiável.

CI automático precisa de fronteira, não de fé

Quando a conversa vai para corrigir CI com um clique, a fronteira deixa de ser detalhe.

Falha de Actions pode ser coisa boba. Um teste que precisa de ajuste. Um linter reclamando. Um comando que mudou. Um snapshot antigo.

Mas também pode ser sintoma de algo maior:

teste frágil;
ambiente mal descrito;
dependência quebrada;
segredo ausente;
contrato instável;
race condition;
mudança de comportamento que ninguém assumiu.

Se todo CI vermelho vira tarefa automática, você corre o risco de tratar sintoma como bug isolado.

Por isso eu gosto da ideia de agente em CI com permissão estreita e saída verificável. Um fluxo decente deveria deixar claro o que o agente pode ler, onde pode escrever, quais comandos pode rodar e que tipo de saída precisa produzir.

O codex-action, por exemplo, chama atenção para decisões que muita demo ignora: sandbox, usuário sem privilégio, modo somente leitura, controle de rede e formato de saída. Sem esse tipo de limite, a automação deixa de ser revisável e vira um processo com permissão demais.

Se o agente roda em CI, ele deveria ter menos liberdade que um dev humano, não mais.

Antes de clicar no fix, faça três perguntas

Eu usaria um checklist curto antes de delegar:

Este lote é mecânico, comportamental ou arquitetural?
O agente consegue resolver sem tocar fora da fronteira combinada?
Eu consigo revisar o diff final sem depender de confiança cega?

Se a resposta para a terceira for não, divida.

Um lote para ajustes mecânicos. Outro para teste. Outro para mudança de comportamento. Outro, talvez, nem deveria ir para o agente ainda.

Não é conservadorismo por medo de IA. É só engenharia normal aplicada a uma ferramenta mais rápida.

Quando um dev humano abre um PR enorme misturando refactor, feature e correção de CI, a gente reclama. Com agente não deveria ser diferente. Talvez devesse ser até mais rígido, porque o agente não carrega o mesmo contexto social do time, não lembra das decisões informais e não sente o cheiro de uma abstração desnecessária do mesmo jeito que alguém que mantém aquele código há meses.

O novo trabalho do review é desenhar delegação

No fim, o botão de fix não elimina o review. Ele muda o centro do review.

Você continua precisando avaliar código, claro. Mas antes disso precisa desenhar a unidade de trabalho:

o que entra no lote;
o que fica fora;
qual risco é aceitável;
qual validação prova que terminou;
qual permissão o agente precisa;
qual tipo de mudança exige parada humana.

Esse desenho é trabalho de engenharia.

E talvez seja a parte que mais vai diferenciar times usando agentes bem de times só empilhando diffs gerados.

O ganho real não vem de clicar em todos os botões de automação. Vem de clicar nos botões certos, com escopo certo, e revisar resultados que ainda cabem na cabeça.

Antes de mandar o próximo "resolve todos esses comentários", tenta uma versão menor:

Corrija apenas os comentários mecânicos deste PR. Não altere comportamento. Não toque no workflow do CI. Rode os testes do módulo afetado. Se algum comentário exigir decisão de produto ou arquitetura, liste e pare.

Isso é menos glamouroso do que "agente, finalize meu PR".

Também é muito mais parecido com trabalho real.