Como coordenar agentes de código em paralelo

O risco de agentes de código em paralelo aparece menos na execução isolada e mais na integração combinada. Três tarefas pequenas podem virar uma única mudança grande, difícil de entender e mais difícil ainda de aceitar, se a equipe não definir fronteiras, dependências, ordem de integração e revisão do comportamento final.

Critérios para colocar agentes de código em paralelo

Agentes de código em paralelo fazem sentido quando as tarefas têm baixo acoplamento, critério de aceite verificável e fronteiras explícitas. O paralelismo útil não nasce da vontade de ocupar todos os agentes disponíveis. Nasce de uma análise simples: se duas mudanças terminarem ao mesmo tempo, elas poderão ser revisadas, testadas e integradas sem transformar o conjunto em uma aposta?

Uma tarefa tende a ser boa candidata para paralelismo quando altera uma área delimitada do código, não muda o mesmo fluxo de usuário de outra tarefa em andamento e pode ser validada por testes automatizados, execução local ou inspeção objetiva. Um ajuste de texto em uma tela administrativa e uma correção isolada em um job de limpeza de dados podem coexistir melhor do que duas alterações pequenas no cálculo final de um pedido.

O DORA recomenda trabalhar com unidades pequenas, independentes e testáveis para obter retorno mais cedo e revisar hipóteses antes. A mesma orientação alerta para a dificuldade de revisar e integrar grandes mudanças geradas com IA, segundo o material sobre lotes pequenos. Esse ponto é especialmente relevante quando vários agentes produzem pull requests ao mesmo tempo. Cada saída pode parecer pequena, mas o efeito integrado pode não ser.

Paralelizar, portanto, é uma decisão de desenho do trabalho. Não é uma fila automática.

Como desenhar fronteiras antes de iniciar as tarefas

A fronteira de uma tarefa precisa dizer ao agente o que pode ser alterado, o que deve permanecer fora do escopo e qual comportamento precisa continuar preservado. Isso vale para agentes de programação e também para pessoas. A diferença é que, com IA, a ambiguidade tende a aparecer em forma de código plausível, não em forma de dúvida explícita.

Uma boa fronteira combina quatro elementos:

Área permitida: módulos, arquivos, camadas ou componentes que podem ser alterados.
Área proibida: partes do sistema que não devem ser tocadas sem autorização humana.
Contrato esperado: entradas, saídas, eventos, APIs internas ou regras que precisam permanecer compatíveis.
Critério de aceite: teste, inspeção ou execução que permite encerrar a tarefa.

A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico dentro de uma janela limitada, conforme o texto sobre engenharia de contexto para agentes. Em termos práticos, isso significa que a fronteira não deve ficar apenas na cabeça da liderança técnica. Ela precisa entrar no contexto de trabalho.

Se a tarefa diz apenas “melhore a autenticação”, o agente pode alterar middleware, sessão, mensagens de erro, testes, componentes de interface e documentação. Se a tarefa diz “ajuste a validação de expiração do token neste módulo, sem alterar o contrato da API nem a tela de login, e atualize apenas os testes relacionados”, a equipe reduziu o espaço de colisão.

Esse cuidado se conecta a uma disciplina maior de especificação. Quando a organização já pratica uma escrita mais clara de escopo, a coordenação fica menos dependente de conversas soltas e mais próxima de um acordo verificável. Por isso, a fronteira precisa virar instrução operacional, não apenas intenção de liderança.

Como evitar que tarefas independentes criem um problema único

Duas tarefas podem ser independentes no repositório e dependentes no comportamento. Esse é o conflito que mais engana em trabalhos assistidos por IA. Não há conflito de merge, os arquivos são diferentes, os testes locais passam, mas o produto mudou de forma incoerente.

Antes de acionar agentes em paralelo, a equipe deveria procurar conflitos semânticos. Eles aparecem quando duas tarefas tocam:

O mesmo fluxo de usuário.
A mesma entidade de domínio.
A mesma tabela ou coleção de dados.
O mesmo contrato de API.
A mesma regra de negócio.
A mesma suíte de testes ou massa de dados de teste.
O mesmo componente compartilhado.

Se duas tarefas tocam o mesmo fluxo de usuário, elas não são paralelas no sentido operacional. Elas podem até ser executadas ao mesmo tempo para explorar alternativas, mas precisam de uma ordem de integração e de uma revisão do conjunto. O risco não é apenas quebrar o build. É aprovar duas soluções corretas isoladamente e contraditórias juntas.

Aqui entra uma distinção útil: conflito de arquivo é o que a ferramenta mostra; conflito de decisão é o que a equipe precisa enxergar. Um agente pode alterar a validação de um formulário, outro pode alterar a mensagem exibida para o mesmo erro, e ambos podem estar tecnicamente corretos. A pergunta é se o comportamento final faz sentido para quem usa o produto e para quem opera o sistema.

Como organizar a ordem de integração

A ordem de integração deve ser definida antes de os agentes terminarem, não improvisada quando os pull requests chegam. Uma sequência simples reduz ambiguidade:

Primeiro, mudanças estruturais pequenas que estabilizam contratos internos, nomes, dependências ou organização de módulos.
Depois, alterações funcionais que dependem dessa estrutura.
Por fim, ajustes cosméticos, limpeza, reorganização de testes e documentação complementar.

Essa ordem não é uma lei universal. Em alguns casos, um teste novo deve entrar antes da implementação para registrar o comportamento esperado. Em outros, uma correção urgente precisa interromper a fila. O ponto é haver uma fila de integração consciente, com responsável e critério, em vez de uma corrida para aprovar o primeiro pull request que parece pronto.

O DORA descreve integração contínua como integração frequente ao código principal, acompanhada de construção e testes automatizados. Também afirma que corrigir uma construção quebrada deve ter prioridade sobre novas mudanças, na orientação sobre integração contínua. Para agentes em paralelo, isso muda a pergunta operacional: o time não deve perguntar apenas “o PR está bom?”, mas “este PR é o próximo que deve entrar para manter o código principal compreensível e testável?”.

Uma fila curta de integração costuma ser mais saudável do que vários merges simultâneos. Se uma construção quebra, a equipe precisa pausar a entrada de novas mudanças e entender o impacto. Continuar integrando saídas de agentes sobre uma base instável aumenta a dificuldade de diagnóstico.

Como revisar o conjunto, não apenas cada entrega

A revisão de código gerado por IA precisa ter duas camadas. A primeira é local: a tarefa cumpriu o escopo, preservou contratos, passou pelos testes previstos e não alterou áreas proibidas? A segunda é sistêmica: depois de integrar as mudanças, o comportamento combinado continua coerente?

A documentação do GitHub descreve recursos de agentes com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas, na página sobre GitHub Copilot Agents. Essa supervisão não deveria ser tratada como carimbo final. Ela é parte do desenho do fluxo.

Na revisão local, as perguntas são mais próximas do pull request:

A mudança respeitou a fronteira definida?
O agente alterou arquivos fora do escopo?
O critério de aceite foi demonstrado?
O código novo é legível para manutenção humana?
Há testes suficientes para o comportamento alterado?

Na revisão sistêmica, as perguntas mudam:

O comportamento final do produto é o esperado?
Dois agentes resolveram o mesmo problema de formas diferentes?
Alguma regra de negócio foi duplicada?
A arquitetura ficou mais coerente ou apenas mais espalhada?
A documentação mínima para a próxima pessoa foi atualizada?
Alguma decisão deveria ser registrada antes de novas mudanças?

Essa revisão conjunta decide se as entregas isoladas formam uma mudança coerente. O ganho aparente de múltiplos agentes desaparece se ninguém assume responsabilidade pelo desenho final. A revisão humana não é uma correção tardia da máquina. É a escolha de manter julgamento no lugar certo.

Um cenário fictício de checkout com três agentes

Considere um exemplo fictício em uma loja digital. A equipe decide usar três agentes no fluxo de checkout. Um agente altera o cálculo de frete. Outro ajusta a aplicação de cupom de desconto. Um terceiro reorganiza testes automatizados do checkout para reduzir duplicidade.

À primeira vista, as tarefas parecem paralelas. O cálculo de frete está em um serviço, o cupom está em outro módulo e os testes ficam em uma pasta separada. Não há, necessariamente, conflito de arquivos.

Mas as três tarefas tocam o mesmo comportamento final: o total a pagar. O frete influencia o subtotal final. O cupom pode ter regra de aplicação antes ou depois do frete. Os testes reorganizados podem apagar, alterar ou enfraquecer cenários que revelariam essa interação.

Nesse caso, a coordenação deveria tratar as tarefas como paralelas apenas na execução inicial, não na integração final. Um desenho possível seria:

Autorizar o agente de testes a mapear cenários existentes, mas não remover cobertura antes das mudanças funcionais entrarem.
Integrar primeiro a regra de frete, com testes específicos do cálculo.
Integrar depois a regra de cupom, explicitando se o desconto incide sobre produtos, frete ou total.
Só então reorganizar os testes, preservando cenários que validam o total a pagar.
Fazer uma revisão conjunta do checkout integrado, não apenas dos três pull requests.

Nenhum efeito positivo deve ser presumido nesse exemplo. A hipótese a medir é que a ordem de integração reduz ambiguidade e facilita revisão. A equipe ainda precisaria observar se os testes cobrem o comportamento combinado, se a regra ficou compreensível e se o código principal permaneceu em condição segura para novas mudanças.

O erro seria aprovar os três pull requests em qualquer ordem porque cada um “passou nos testes”. O checkout não é a soma administrativa de arquivos alterados. É um fluxo de negócio percebido como uma unidade.

Checklist para autorizar, pausar ou integrar tarefas paralelas

Use este checklist como instrumento de coordenação antes de colocar agentes de código em paralelo. Ele não substitui desenho técnico, priorização ou revisão humana. Serve para decidir se uma tarefa pode correr junto, se deve esperar outra mudança ou se está ambígua demais para ser executada.

Autorize o paralelismo quando

A fronteira de código está explícita, com módulos, arquivos ou camadas permitidos.
As áreas proibidas estão claras.
A tarefa altera comportamento independente de outras mudanças em andamento.
O critério de aceite pode ser verificado por teste, inspeção ou execução local.
A saída de um agente não depende de decisão, contrato ou refatoração produzida por outro.
Há uma ordem de integração definida.
Existe uma pessoa responsável por revisar o conjunto integrado.

Pause antes de executar quando

O escopo usa verbos amplos, como melhorar, revisar ou modernizar, sem limite operacional.
A tarefa toca o mesmo fluxo de usuário de outra mudança em andamento.
O aceite depende de interpretação subjetiva.
O agente precisaria decidir uma regra de negócio não documentada.
A mudança mexe em área crítica sem testes ou sem pessoa disponível para revisão.

Integre com cuidado quando

Não há conflito de arquivos, mas há conflito possível de regra, entidade, cálculo ou contrato.
Uma refatoração muda a base sobre a qual outra tarefa foi gerada.
Testes foram reorganizados ao mesmo tempo que funcionalidades foram alteradas.
O código principal está instável ou com construção quebrada.
A revisão local foi concluída, mas ninguém avaliou o comportamento final.

O critério de interrupção é simples de formular e difícil de sustentar: se fronteira, aceite, dependência, ordem de integração ou revisão conjunta não estiverem definidos, reduza o paralelismo ou transforme a tarefa em sequência curta.

Para fluxos com muitos agentes, o primeiro avanço não é abrir mais tarefas. É decidir quais mudanças podem ser integradas sem perder responsabilidade pelo conjunto.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

Para continuar esta leitura

Como usar IA na investigação de um defeito

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.