O commit que já não é seu
Duas pessoas do time abrem sessão de agente de IA na mesma manhã: uma pede para revisar o módulo de pagamento, outra pede para ajustar validação no mesmo arquivo. Cada agente entrega um PR limpo, testado, com descrição bem escrita. Só que quando o segundo PR sobe, o merge trava. Ninguém programou para isso: os dois agentes trabalharam ao mesmo tempo, no mesmo trecho, sem saber um do outro.
Isso não é acidente raro. Um estudo publicado em julho de 2026 analisou 33.596 pull requests feitos por agentes de IA em 2.807 repositórios reais do GitHub (dataset AIDev-pop) e mediu quanto desse trabalho roda em paralelo sem coordenação. O resultado: 79,4% dos PRs de agente estavam "co-ativos", ou seja, tinham outro PR de agente tocando o mesmo repositório na mesma janela de tempo. Numa janela de uma semana, o número sobe para 95%.
Quase todo PR de agente tem companhia. E companhia, no Git, nem sempre é coisa boa.
Colisão tem taxa, e ela é alta
O estudo também mediu o que acontece quando esses PRs concorrentes de fato colidem. Quando dois agentes diferentes mexem na mesma área do código ao mesmo tempo, 41,7% dos pares terminam em conflito de merge. Quando é o mesmo agente rodando duas tarefas em paralelo contra si mesmo, a taxa cai para 19,8%, e ainda assim é alta para qualquer padrão de engenharia que valha a pena copiar.
| Situação | Frequência entre pares co-ativos | Taxa de conflito de merge |
|---|---|---|
| Mesmo agente, duas tarefas em paralelo | a maioria dos casos | 19,8% |
| Agentes diferentes na mesma área | 0,5% dos pares | 41,7% |
A leitura rápida engana. Colisão entre agentes diferentes é rara, só 0,5% dos pares co-ativos, mas quando acontece, quase metade vira conflito de verdade. Colisão do mesmo agente contra ele mesmo é comum, e mesmo assim conflita em um a cada cinco casos.
Por que o time humano não sente isso do mesmo jeito
Com pessoas, a contenção se resolve informal: alguém avisa no canal que está mexendo no módulo de pagamento, outra pessoa espera ou pega outro arquivo. Esse acordo tácito não existe entre agentes. Um agente não sabe que outro processo, humano ou de IA, está editando o mesmo trecho agora. Ele só vê o estado do repositório no momento em que foi chamado, entrega o PR e vai embora.
Quanto mais tarefas de IA um time dispara em paralelo sem um jeito de dizer "esse arquivo já tem dono agora", mais aquele número de 79,4% vira gargalo real: revisor gastando a manhã resolvendo conflito em vez de olhar lógica de negócio.
O custo disso não aparece na fatura do modelo, aparece na agenda de quem revisa. Uma hora de engenheiro sênior resolvendo merge de PR gerado por agente é uma hora que não foi gasta olhando a lógica de negócio que o agente também errou. E como o agente devolve o PR pronto, com testes passando e descrição bem escrita, o conflito costuma chegar tarde, já perto do deploy, quando é mais caro de destrinchar.
O que dá para fazer amanhã de manhã
O primeiro ajuste é declarar escopo antes de disparar a tarefa, não depois. Antes de abrir uma sessão de agente, escreva qual arquivo ou módulo ela vai tocar. Um lock simples resolve:
# .agent-locks
pagamentos/validacao.ts: em uso por agente-a, desde 09:14
Escopo pequeno e declarado tem um efeito colateral bom: o PR sai menor e merga mais rápido, o que reduz o tempo em que outra tarefa pode pisar no mesmo lugar antes do merge acontecer.
O segundo ajuste é trocar disparo livre por fila. Se duas tarefas miram o mesmo módulo, a segunda espera a primeira mergear. Isso é configuração de orquestração, não excesso de cuidado: um coordenador simples que checa o lock antes de iniciar a próxima tarefa já corta boa parte dos 41,7% de conflito entre agentes diferentes.
É esse tipo de decisão de processo, e não de ferramenta, que sustenta o jeito que a Overflow monta desenvolvimento sob medida com IA: ciclos curtos, escopo pequeno, e nenhuma tarefa de agente roda sem alguém sabendo o que ela vai tocar antes de começar.
O time que já roda dois ou três agentes ao mesmo tempo não precisa esperar o próximo conflito para descobrir isso. Basta abrir o histórico de PRs da semana e contar quantos tocaram o mesmo arquivo na mesma janela de tempo. Se o número chegar perto de 79%, o processo é o que precisa mudar, não a ferramenta.
O lock não precisa ser sofisticado. Um arquivo de texto versionado no repositório, checado antes de cada tarefa começar, já resolve a maior parte do problema. Sofisticação entra depois, quando o time perceber que mesmo um lock manual já derrubou o número de conflitos da semana.
