# O git foi feito para humanos · Diário da fábrica URL: https://www.edugalbs.com/fabrica-24x7/capitulos/o-git-foi-feito-para-humanos > Dois agentes conflitam só por acrescentar uma linha no fim da mesma lista. Com IAs em paralelo, o formato dos arquivos vira arquitetura. Capítulo 06 · 26 de outubro de 2026 ## O git foi feito para humanos Dois agentes conflitam só por acrescentar uma linha no fim da mesma lista. Com IAs em paralelo, o formato dos arquivos vira arquitetura. ⏱️ 10 min de leitura **TL;DR** O capítulo conta a terça à noite em que cinco agentes trabalharam ao mesmo tempo e quatro travaram na hora de juntar o código. O git compara linhas de texto, e dois agentes que acrescentam uma linha no fim da mesma lista entram em conflito sem nenhuma contradição real. A saída foi mudar o formato dos arquivos e reescrever a arquitetura para não conflitar, em vez de ser fácil de ler. O que o formato não resolve, o PO resolve no plano. No capítulo anterior, [**O token mais caro é o de uma IA esperando**](https://www.edugalbs.com/fabrica-24x7/capitulos/o-token-mais-caro) (capítulo 5), contei a execução mais cara do projeto, que não entregou nada, e a regra que nasceu dela: esperar é trabalho de código. No capítulo 1, [**Escala 6x1? Aqui é 24x7**](https://www.edugalbs.com/fabrica-24x7/capitulos/escala-24x7), eu deixei uma noite pela metade. Era terça, e eu coloquei cinco tarefas para rodar ao mesmo tempo. Quatro travaram no último passo. Escrevi que aquela noite tinha me ensinado uma lição, paralelismo é barato para começar e caro para terminar, e que contaria a história aqui. Este capítulo é sobre essa noite e sobre o que veio depois: por que uma ferramenta pensada para pessoas atrapalha quando quem escreve são várias IAs, e por que, com agentes em paralelo, até o formato de um arquivo vira decisão de arquitetura. ### 20h33: cinco agentes, um arquivo Às 20h33 daquela terça, 29 de setembro, a primeira das cinco execuções começou. Cada agente tinha a sua cópia isolada do projeto e não via o trabalho dos outros. Desenvolveram, testaram e revisaram sem esbarrar em ninguém. O problema apareceu no fim. Naquela época, cada tarefa terminava abrindo um pedido de integração no GitHub, o PR: um pedido para juntar o código novo à main, a versão oficial do projeto. Às 22h11, o placar era de quatro falhas em cinco. Todas no mesmo passo, por conflito. Conflito, no git, é quando duas mudanças mexem no mesmo trecho de um arquivo e ele não sabe qual vale. Uma pessoa precisa olhar e decidir. Ou, no meu caso, um agente. Antes de seguir, uma legenda para o resto do capítulo: - ⚙️ **Motor**: o orquestrador da fábrica, um programa comum, sem IA, que faz sempre a mesma coisa do mesmo jeito. - 🤖 **Agente**: uma IA fazendo o trabalho. Resolver aqueles conflitos um por um teria virado uma cascata. Imagine cinco tarefas prontas, esperando para entrar na main: - ⚙️ **Juntar a primeira**: a primeira tarefa entra, e a main muda. - 🤖 **Refazer as outras**: as quatro que sobraram já não se encaixam na main nova. O desenvolvedor é chamado de novo em cada uma, e depois o teste e a revisão. - ⚙️ **Juntar a segunda**: uma das quatro entra, e as três restantes dão conflito outra vez. E assim por diante. ![Uma cascata de conflitos com cinco tarefas prontas em paralelo: a primeira entra na main, as outras quatro voltam para o agente desenvolvedor, testador e revisor; a segunda entra e as três restantes voltam de novo. As etapas de juntar o código estão em verde-azulado, do motor, e as voltas para refazer o trabalho em laranja, do agente](https://www.edugalbs.com/fabrica-24x7/media/capitulo-06-cascata.png) Cada volta da cascata paga de novo desenvolvimento, teste e revisão de um trabalho que já estava pronto. E, com o GitHub no meio, cada volta também rodava de novo a integração contínua. ### Barato para começar, caro para terminar A primeira resposta veio na mesma noite. Às 23h nasceu um fluxo que junta o código no meu próprio computador, sem passar pelo GitHub a cada tarefa. A integração contínua saiu do ciclo curto, e a taxa de sucesso das execuções saltou de cerca de metade para nove em cada dez. Enviar para o GitHub virou uma decisão minha, em lote. Só que o conflito não sumiu. Ele mudou de forma. Antes, a execução com conflito falhava, e o retrabalho virava uma execução nova. Com a junção local, ela não falhava mais: chamava um passo para resolver o conflito, com o desenvolvedor e o revisor de volta em cena. A falha virou uma resolução cara. Nesse período, as execuções com conflito ficaram com quase um terço do custo de todas as execuções. O que mudou o jogo foi o Product Owner de IA, o PO que apresentei no [capítulo 2](https://www.edugalbs.com/fabrica-24x7/capitulos/a-ia-saiu-do-meu-volante). Ele lê o código, junta as tarefas que mexem nos mesmos arquivos em uma execução só e coloca em etapas diferentes os grupos que iriam brigar. A resolução de conflito saiu do momento de juntar o código e foi para o momento do plano. Comparando os três jeitos de trabalhar: - **PRs em paralelo no GitHub**: cerca de uma execução em cada cinco com conflito, e todas essas falharam. - **Junção local, sem o PO**: a mesma proporção de conflitos, nenhuma falha, e quase um terço do custo indo para as execuções com conflito. - **Junção local, com o PO**: cerca de uma execução em cada dez com conflito, e menos de um quinto do custo indo para elas. Uma coisa que eu nunca tinha visto em um time humano: um PO de carne e osso conhece o produto, mas não sabe quais arquivos cada tarefa vai alterar. A IA no papel de PO sabe, porque consegue ler o código antes de planejar. ### O git compara linhas Mesmo com o PO, sobrava uma pergunta: por que tarefas que não tinham nada a ver uma com a outra davam conflito? Porque o git compara linhas de texto e foi feito para pessoas, que mexem em poucas linhas por vez e conversam antes de mexer no mesmo arquivo, enquanto cinco agentes em paralelo acrescentam cada um a sua tela, a sua rota e o seu estilo, todos no mesmo lugar. Na manhã seguinte à noite das cinco execuções, as correções foram todas de formato, sem mudar o comportamento do app: o mesmo jeito de marcar o fim de linha em todos os arquivos, listas com uma entrada por linha e em ordem alfabética, e as tabelas da documentação geradas automaticamente. Os slides mostram o caso que resume tudo, uma linha que carregava vários módulos, e as saídas, da mais simples à que a fábrica adotou depois: > **Com vários agentes em paralelo, o formato dos arquivos passa a ser uma decisão de arquitetura.** ### Onde os conflitos moram O formato resolveu os conflitos mais bobos. Mas eles continuavam aparecendo, e sempre nos mesmos arquivos. Quando a IA contou, entre as 35 execuções da fábrica que tinham entregado código, quantas tinham mexido em cada arquivo, o desenho ficou claro. Metade dos arquivos tinha sido tocada por uma execução só. Já o arquivo principal das telas, o `index.html`, tinha sido tocado por 23 das 35. ![Barras com quantas das 35 execuções da fábrica que entregaram código alteraram cada arquivo: index.html 23, README.md 22, app.js 22, service/index.js 20, style.css 19 e service.test.js 19, os seis destacados, com cerca de 11.600 linhas; depois software-development.yaml 16, backlog.js 15, workflow.js 15 e screenshot.js 13. Metade dos arquivos foi tocada por uma execução só](https://www.edugalbs.com/fabrica-24x7/media/capitulo-06-arquivos-quentes.png) Os conflitos não se espalhavam pelo código. Eles se concentravam em poucos arquivos centrais, os que registram telas, canais, rotas e estilos. Toda funcionalidade nova precisava passar por eles. Os seis primeiros da lista somavam cerca de 11.600 linhas e funcionavam como pontos de encontro obrigatórios. Uma arquitetura organizada para pessoas faz exatamente isso. Um arquivo central, que registra tudo, é ótimo para quem lê: está tudo em um lugar só. Para cinco agentes escrevendo ao mesmo tempo, é uma porta estreita. ### 1º de outubro: a arquitetura reescrita para não conflitar No fim da tarde de quinta, 1º de outubro, a fábrica rodou um épico, um conjunto de tarefas com um objetivo só: reorganizar o próprio código para não conflitar. Nenhuma mudança de comportamento, só de formato. Foi a reorganização que contei de passagem no capítulo 1, antes da segunda noite. O princípio era simples: uma funcionalidade nova acrescenta arquivos, não edita arquivos compartilhados. Na prática: - **Uma pasta por tela**: dez telas saíram do arquivo central e ganharam arquivos próprios. - **Listas geradas**: a lista do que o `index.html` carrega passou a ser montada automaticamente, a partir dos arquivos que existem. - **Estrutura mínima no centro**: o arquivo principal da interface ficou só com o esqueleto do app. Os arquivos que todo mundo tocava encolheram: - **O arquivo principal da interface (`app.js`)**: de 3.932 linhas para 953. - **O `index.html`**: de 1.383 para 334. - **O arquivo central do serviço**: de 1.767 para 115. - **O arquivo gigante de testes do serviço**: dividido por área. ![Antes e depois da reorganização, em linhas: app.js de 3.932 para 953, index.html de 1.383 para 334, o arquivo central do serviço de 1.767 para 115, style.css de 1.264 para 851, e o arquivo de testes do serviço, de 2.163 linhas, dividido por área](https://www.edugalbs.com/fabrica-24x7/media/capitulo-06-antes-depois.png) O resultado é uma arquitetura que não é comum. Para uma pessoa, ela é pior de ler: o que antes estava em um arquivo agora está espalhado em dezenas. Mas o objetivo era outro. Era deixar várias IAs trabalharem ao mesmo tempo sem esbarrar umas nas outras. O próprio épico rodou em seis execuções, sem nenhum conflito. ### A segunda noite, medida A segunda noite, a que eu contei no capítulo 1, foi a primeira depois da reorganização. Com a porta mais larga, o PO colocou até cinco execuções ao mesmo tempo, contra duas na primeira noite. Foram cerca de 25 tarefas. Houve quatro conflitos, e os quatro foram resolvidos sem mim, sem nenhuma falha na hora de juntar o código. Os números por arquivo mostraram que a reorganização tinha funcionado. Antes, um commit em cada três mexia no `app.js` ou no arquivo central do serviço. Naquela noite, foi um em cada oito no `app.js` e quase nenhum no serviço. Mais tarefas por hora, porém, não quis dizer tarefa mais barata. A fábrica entregou quase metade a mais de tarefas por hora de relógio, e cada mil linhas passaram a consumir quase metade a mais de tokens. A reorganização tirou o gargalo da hora de juntar o código, e o custo a mais veio de outro lugar, dos turnos do agente de testes. Essa conta está no capítulo 4, [**O gargalo não é o código, é o teste**](https://www.edugalbs.com/fabrica-24x7/capitulos/o-gargalo-e-o-teste). E novos pontos de encontro já apareciam: a documentação principal do projeto e o script que tira as capturas de tela. Por isso nasceu o mapa de conflitos. Ele é calculado pelo motor ⚙️, sem chamar nenhuma IA, a partir do histórico das execuções: quais arquivos e quais linhas mais execuções tocam. O PO consulta o mapa para montar as etapas e propõe quebrar os pontos quentes antes que eles virem conflito. ### O que o formato não resolve Nem todo conflito é de formato. Quando duas tarefas mudam o mesmo comportamento, por exemplo duas regras diferentes para o que acontece com uma tarefa atrasada, o conflito é real. Nenhuma ferramenta vai decidir qual regra vale. Quando fui atrás de saídas além do git, encontrei três níveis: - **Formato do repositório**: um arquivo por coisa, listas com uma entrada por linha e tabelas geradas. Elimina a maioria dos conflitos de texto, e foi por aqui que eu comecei. - **Junção que entende código**: ferramentas como o Mergiraf comparam a estrutura do código, e não as linhas, e funcionam dentro do próprio git. - **Outro modelo de versionamento**: o Jujutsu, compatível com o git, e o Pijul tratam o conflito como um estado que pode ser guardado e resolvido depois, sem travar o fluxo. Combina melhor com muitos agentes em paralelo. Nenhum dos três resolve o conflito de comportamento. Para esse, a resposta continua sendo planejar antes. O PO prevê os arquivos que cada grupo vai tocar, aponta onde pode haver conflito e separa os grupos em etapas, como um gerenciador de travas de um banco de dados decide quem escreve primeiro. Mesmo assim, o conflito não chegou a zero: com o PO, 3 de 27 execuções ainda precisaram resolver um. **💡 Insight** Não sei se ainda faz sentido várias pessoas trabalharem no mesmo repositório. Hoje, uma pessoa sozinha já consegue gerenciar várias IAs trabalhando nele. A organização que eu vejo é um roadmap, um backlog e um PO por repositório. Quando escrevi isso, a IA concordou com o centro e ajustou a borda. Talvez a fronteira não seja a pessoa, e sim a área do código: se cada pessoa for dona de um módulo, com o seu PO e o seu roadmap, várias ainda cabem no mesmo repositório, desde que as áreas não se cruzem. Um repositório por pessoa seria o caso extremo dessa mesma ideia. Uma coisa não mudou com nada disso. O código é juntado no meu computador, mas mandar para o GitHub continua sendo uma decisão minha, e a automação não atravessa uma aprovação humana. ### O próximo passo Planejar antes resolveu o conflito. O PO prevê os arquivos, separa as etapas, e a noite roda sem esbarrar. Mas nem tudo vale a pena prever. Na manhã depois da primeira noite, eu acordei com telas prontas que ninguém tinha desenhado antes, e percebi que era mais fácil julgar uma tela pronta do que descrever uma que não existia. No próximo capítulo, [**Refinar antes ou reagir depois?**](https://www.edugalbs.com/fabrica-24x7/capitulos/refinar-antes-ou-reagir-depois) (capítulo 7), conto quando vale planejar cada detalhe e quando sai mais barato deixar a fábrica entregar e reagir ao que ficou pronto. [Próximo capítulo**Refinar antes ou reagir depois?**Quando gerar fica barato, o incremento funcionando vira a especificação mais barata que existe.](https://www.edugalbs.com/fabrica-24x7/capitulos/refinar-antes-ou-reagir-depois) [← Todos os capítulos](https://www.edugalbs.com/fabrica-24x7) Newsletter ### Receba os próximos capítulos. Um e-mail quando sair um capítulo novo. Sem spam, e você sai quando quiser.