Mais agentes, mais PRs: como organizar a revisão

Imagine dois agentes trabalhando no mesmo projeto. Um corrige o filtro da lista de pedidos; o outro ajusta a paginação. Os dois terminam e abrem PRs, os pedidos de integração de código. Só que ambos dependem da mesma pessoa para revisar.

Essa pessoa ainda precisa entender as mudanças, conferir o comportamento e decidir se elas podem entrar juntas. Enquanto isso, seria fácil abrir mais duas tarefas para aproveitar os agentes disponíveis.

Eu começaria pela fila que já existe. Antes de aumentar o paralelismo, vale combinar quem vai revisar cada mudança e o que precisa chegar junto com ela. Se os PRs ficam esperando por dias, produzir outro diff, o conjunto de alterações, pode só aumentar o trabalho acumulado.

Ferramentas de revisão ajudam a encontrar o caminho

O Change Review do Android Studio Rabbit 2 organiza trechos relacionados das alterações em uma leitura guiada e apresenta correções recomendadas. Esse tipo de recurso ajuda a entender uma mudança que passou por vários arquivos sem seguir apenas a ordem em que o Git os lista.

Ainda cabe a quem revisa conferir o diff completo e buscar o contexto necessário. Um agrupamento automático pode facilitar a leitura, mas não demonstra que todos os comportamentos afetados foram verificados. O resumo também pode deixar de fora justamente o trecho que precisava de atenção.

Há outro custo no trabalho em paralelo: transportar todas essas mudanças. O Pando, backend Git usado no monorepo da OpenAI, lida com muitas leituras e pushes concorrentes. É um problema de infraestrutura em outra escala. Uma equipe pequena não precisa reproduzir essa arquitetura para perceber a diferença entre conseguir enviar mais branches e conseguir revisar o que chegou nelas.

Dá para melhorar a segunda parte com um acordo simples por PR, usando as ferramentas que o projeto já tem.

Defina o aceite antes de pedir a correção

Vamos ficar com a tarefa do filtro, em um exemplo hipotético de aplicação web. O comportamento esperado pode ser este: ao escolher um status, a lista mostra os pedidos correspondentes; ao limpar o filtro, volta à listagem sem filtro de status. Se a consulta falhar, a tela informa o erro e permite tentar novamente.

Também vale escrever o que fica fora: preservar o contrato atual da API, não trocar a biblioteca de dados e não aproveitar a correção para refatorar o módulo inteiro. Se a solução exigir mexer em uma dessas partes, o agente deve apontar a necessidade antes de ampliar o trabalho.

Isso dá uma referência para a revisão. Em vez de avaliar se a solução parece boa, a pessoa consegue comparar o código com um comportamento combinado. Se o aceite estiver ambíguo, resolva a dúvida antes de mandar outro agente trabalhar na mesma área.

O tamanho do PR vem depois dessa decisão. Separar uma mudança coesa em cinco PRs dependentes pode tornar a revisão mais difícil. Para esse filtro, eu preferiria uma alteração que desse para entender e verificar como um comportamento completo.

Entregue uma ficha curta junto com o diff

A descrição do PR pode reunir o que a pessoa precisa para começar a revisão. Não precisa repetir cada linha alterada nem virar um relatório do chat.

Uma ficha para preencher no projeto poderia ser assim. Os campos abaixo são um modelo, não resultados de testes executados:

Tarefa: corrigir o filtro de status da lista de pedidos.
Aceite: filtrar, limpar o filtro e permitir nova tentativa após falha.
Fora do escopo: alterar o contrato da API ou refatorar o módulo.
Base e proposta: preencher os identificadores dos commits.
Mapa da mudança: indicar as partes que precisam ser lidas juntas e por quê.
Verificações: registrar o estado verificado, a execução e seu resultado.
Pendências: registrar o que ainda não foi verificado.
Revisão e integração: indicar responsável, dependências e próxima ação.

No mapa da mudança, importa a relação entre as partes: como a seleção de status chega à consulta e como a resposta atualiza a lista. Uma lista de nomes de arquivos ajuda a localizar o código, mas ainda deixa essa explicação para quem revisa descobrir.

As evidências precisam ser igualmente específicas. Se houve teste automatizado, registre qual foi executado, sobre qual revisão e onde está o resultado. Se houve conferência no navegador, descreva os passos, os dados sintéticos usados e o que apareceu na tela. Se ainda não aconteceu, marque como pendente.

“Testes passaram” perde utilidade quando ninguém sabe se o resultado veio antes ou depois da última alteração. E um CI verde só informa que as verificações executadas passaram naquele estado; ele não cobre, por definição, todo comportamento possível.

A ficha facilita a entrada na revisão. Ela continua ao lado do diff, sem substituí-lo.

Branches separadas ainda podem mudar o mesmo comportamento

Voltemos ao segundo agente, que está ajustando a paginação. Mesmo trabalhando em arquivos diferentes, ele pode tomar uma decisão sobre a consulta que entre em desacordo com a correção do filtro.

Filtrar uma lista paginada pode exigir uma decisão sobre a página atual. Manter a página ou voltar à primeira depende do comportamento combinado para o produto. Se cada agente assumir uma regra diferente, o Git pode integrar os arquivos sem apontar conflito textual, e a tela ainda assim se comportar de forma errada.

Antes de paralelizar, confira essas dependências. Talvez seja melhor combinar o comportamento primeiro, ou concluir uma das mudanças antes de iniciar a outra. Separar branches organiza as alterações, mas não resolve decisões compartilhadas.

Se a branch-base avançar durante a revisão, use o procedimento do projeto para verificar a combinação que será integrada. Isso pode envolver atualização da branch ou verificações de integração já previstas no fluxo. O importante é saber qual estado foi examinado e preservar as proteções do repositório. Um teste aprovado na branch isolada não comprova que a combinação posterior também funciona.

Combine um limite para a espera por revisão

Com a ficha definida, fica mais fácil enxergar quais PRs estão prontos para análise e quais ainda têm trabalho pendente. Aí cabe combinar quantas mudanças podem aguardar cada pessoa responsável pela revisão.

Não há um número que sirva para toda equipe. O limite depende do risco das tarefas e do tempo que as pessoas têm para analisá-las. O acordo precisa dizer o que fazer quando a fila encher: resolver as pendências dos PRs abertos e ajudar na verificação antes de iniciar outra mudança.

Pode sobrar capacidade do agente nesse intervalo. Isso é um custo a considerar, mas manter todo agente ocupado também tem custo: alguém terá de retomar o contexto de cada PR que ficou esperando. Vale observar os dois, em vez de tratar ociosidade como sinal automático de desperdício.

Para quem desenvolve sozinho, o acordo continua útil. Você é a mesma pessoa que delega e revisa; abrir mais frentes não cria mais tempo para conferir o resultado.

Experimente no próximo conjunto de tarefas

Antes de aumentar o paralelismo, registre como algumas tarefas comparáveis percorrem o fluxo atual. Depois, experimente a ficha com um limite de trabalho em andamento combinado pela equipe.

Observe o tempo entre o início da tarefa e a integração aceita, separando a espera por revisão. Anote também as correções pedidas e as falhas encontradas ao combinar mudanças. Use o critério de aceite combinado para encerrar a tarefa, sem se limitar ao momento em que o agente disse que terminou ou o CI ficou verde.

Uma amostra pequena não prova que o novo fluxo causou uma melhora ou uma piora. Ela pode, porém, mostrar algo acionável: PRs sem evidência, dependências descobertas tarde ou uma fila concentrada em uma pessoa.

Eu começaria preenchendo a ficha para o próximo PR e reservando quem vai revisá-lo. Se a espera continuar crescendo, ajuste o escopo e a entrada de trabalho antes de abrir outra frente.

Referências

• Your favorite agents are now integrated in Android Studio, sobre a integração de agentes e o Change Review.
• Scaling Git at OpenAI, sobre o Pando e o custo de operações Git concorrentes. Os resultados relatados são da própria empresa, não uma previsão de ganho para outras equipes.