Em 2005, quando Linus Torvalds criou o Git, o problema a solucionar era coordenar o desenvolvimento do kernel Linux, um projeto global com milhares de contribuições simultâneas. A resposta foi um sistema distribuído, capaz de lidar com múltiplas linhas de desenvolvimento sem depender de um servidor central.
Por quase duas décadas, essa arquitetura não apenas funcionou, ela se tornou o padrão da indústria. Com a ascensão de plataformas como o GitHub, o Git ganhou uma camada social e operacional que simplificou colaboração, revisão e distribuição de código em escala global.
Mas o cenário que moldou essas decisões já não é mais o mesmo.
Quando a infraestrutura começa a falhar
Os primeiros sinais de desgaste não vieram de iniciantes, mas de nomes experientes. Mitchell Hashimoto, cofundador da HashiCorp, decidiu migrar um de seus projetos para fora do GitHub após enfrentar lentidão recorrente e interrupções no fluxo de trabalho.
A crítica dele não foi ao Git em si, mas ao ecossistema que cresceu ao redor: pull requests lentos, filas acumuladas, pipelines sobrecarregados. Em outras palavras, a engrenagem que transformou o Git em uma plataforma global começou a dar sinais de saturação.
Seria tentador atribuir isso apenas à gestão da plataforma, mas os dados apontam para algo mais estrutural.
O fator que mudou o jogo: agentes de IA
A explosão recente de código gerado por IA não é apenas quantitativa, é qualitativa. Em 2025, houve um crescimento superior a 200% em projetos criados com apoio direto de agentes automatizados. Esses sistemas não se limitam a sugerir código. Eles operam dentro do fluxo:
- Criam branches;
- Abrem pull requests;
- Executam testes;
- Iteram sobre erros.
Esse comportamento altera profundamente a dinâmica do desenvolvimento. O volume de mudanças cresce, mas também cresce a instabilidade associada a essas mudanças. Estudos indicam que pull requests gerados por IA tendem a produzir mais issues do que aqueles feitos por humanos, o que amplia o número de ciclos de revisão e correção.
O resultado é um aumento exponencial na carga sobre sistemas que foram projetados para um ritmo muito mais lento e deliberado.
O fluxo tradicional do Git é baseado em etapas discretas: commit, push, revisão, merge. Cada uma dessas fases pressupõe intervenção humana, decisão consciente, pausa. Esse modelo funciona bem quando o gargalo é humano.
Mas agentes operam de forma contínua. Eles não “esperam por revisão” no mesmo sentido. Produzem, ajustam e tentam novamente em ciclos rápidos. Esse descompasso cria fricção: o sistema exige checkpoints, enquanto os agentes trabalham em fluxo.
Segundo Peco Karayanev, da Autoptic, isso pressiona o Git a operar de forma mais contínua, algo para o qual ele não foi originalmente projetado.
Mesmo antes da IA, o Git já era conhecido por sua complexidade. Seu modelo mental baseado em árvores, commits, referências e estados é poderoso, mas pouco intuitivo. Esse fator sempre foi tolerável porque desenvolvedores aprendiam a lidar com ele. Mas agentes precisam de abstrações mais diretas, previsíveis e menos ambíguas. O que antes era apenas uma barreira de entrada passa a ser um gargalo operacional.
Reimaginando a interface
Ferramentas como o GitButler surgem justamente nesse espaço. A proposta não é substituir o Git, mas reconstruir a forma como interagimos com ele.
Isso inclui:
- Trabalhar com múltiplos fluxos simultâneos;
- Reorganizar commits sem fricção;
- Manter sincronização constante com o código upstream;
- Evitar conflitos acumulados.
Mais do que facilitar a vida do desenvolvedor, esse tipo de abordagem aponta para a necessidade de uma camada intermediária que traduza o Git para novos tipos de usuários, incluindo agentes.
O paradoxo da centralização
Há um elemento estrutural que amplifica todos esses problemas: a centralização. O Git foi concebido como um sistema distribuído, mas o desenvolvimento moderno se concentra em poucas plataformas. O GitHub sozinho reúne centenas de milhões de usuários e repositórios.
Esse acúmulo cria um ponto único de pressão. Quando agentes entram na equação, aumentando drasticamente o número de operações, essa centralização deixa de ser apenas uma conveniência e passa a ser um risco.
A ironia é evidente: um sistema criado para descentralizar acabou sustentando um dos ecossistemas mais centralizados da história do desenvolvimento de software.
Um limite arquitetural
Algumas críticas vão além da interface e apontam para a própria arquitetura do Git. Empresas como a Diversion argumentam que o modelo atual não escala bem em cenários com alta concorrência.
Segundo essa visão, o Git não é verdadeiramente distribuído, mas replicado, e muitas operações fundamentais continuam sendo processadas de forma sequencial. Em ambientes com múltiplos agentes operando simultaneamente, isso pode se tornar um gargalo significativo.
Embora essa crítica venha de um concorrente e deva ser analisada com cautela, ela reflete uma preocupação crescente no setor.
Nem todas as respostas passam por ruptura. Projetos como o Jujutsu buscam manter a compatibilidade com o Git enquanto introduzem melhorias de usabilidade, como undo nativo e maior flexibilidade na gestão de conflitos. Já o Gitoxide tenta modernizar a base técnica do sistema, explorando o paralelismo e a segurança de memória.
O próprio Git também segue evoluindo. Sob liderança de Junio Hamano, a próxima versão introduz mudanças importantes na forma como referências são armazenadas, reduzindo gargalos em repositórios grandes.
Essas melhorias são relevantes, mas atuam principalmente na eficiência, não no modelo de uso. O ponto central dessa discussão não é performance isolada, mas alinhamento.
O Git foi projetado para um mundo onde humanos eram o principal agente de mudança no código. Esse mundo agora inclui sistemas autônomos que operam em escala e velocidade diferentes.
Isso exige mais do que otimizações.
Exige repensar:
- Como mudanças são registradas;
- Como conflitos são resolvidos;
- como fluxos de trabalho são estruturados.
O cenário mais plausível não é o abandono do Git, mas sua abstração.
Assim como sistemas operacionais, compiladores e protocolos de rede continuam existindo, mas raramente são expostos diretamente, o Git pode se tornar uma camada invisível, operando por baixo de ferramentas mais adequadas ao novo contexto.
Para o desenvolvedor, humano ou agente, o que importa não é o commit, mas o fluxo.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!