O cofundador do GitHub recebeu 17 milhões de dólares da a16z, criando o Git na era dos agentes

Escrevendo: Leo

Você já pensou que a programação pode ter mudado completamente?
Os desenvolvedores estão deixando de usar ferramentas de IA de forma simples, para passar a enxergar a IA como uma nova base para construir software.
Não é uma pequena mudança, mas uma transformação de paradigma total.
Imagine só, aqueles conceitos centrais que sempre consideramos — controle de versão, ramificações, revisão de código, até mesmo a definição de “colaboração” — estão sendo redefinidos por fluxos de trabalho impulsionados por agentes de IA.
E o que me surpreende ainda mais é que o Git que usamos todos os dias foi originalmente criado para um fluxo de trabalho de patches em uma lista de emails de há 20 anos, e agora precisa atender a um cenário onde humanos desenvolvedores e uma turma de agentes de IA trabalham simultaneamente.

Essa é a razão pela qual a notícia de que o GitButler recebeu recentemente uma rodada de financiamento de 17 milhões de dólares me fez parar para refletir seriamente.
Essa rodada foi liderada pela a16z, com follow-ups da Fly Ventures e A Capital.
Mais interessante ainda é que o CEO do GitButler, Scott Chacon, é um dos cofundadores do GitHub, e escreveu aquele livro que quase todo desenvolvedor já leu, o “Pro Git”.
Uma pessoa que já conquistou grande sucesso na área de controle de versão, por que voltaria ao caminho do empreendedorismo para repensar um problema que parece estar “resolvido”?
Ele foi direto na mensagem: “Não estamos construindo um ‘Git melhor’, estamos construindo a próxima geração de infraestrutura para construção de software.”
Por trás dessa frase, há uma visão profunda sobre o futuro do desenvolvimento de software.

O impasse de 20 anos do Git: uma ferramenta feita para listas de emails

Muita gente não conhece bem o contexto histórico do Git.
Ele foi criado inicialmente pela equipe do kernel Linux em 2005, com uma filosofia profundamente enraizada na tradição Unix.
Scott mencionou numa entrevista um detalhe interessante: o núcleo do Git nunca foi pensado para uma interface amigável ao usuário.
Eles seguiram a filosofia Unix, construindo uma série de comandos de “pipeline” de baixo nível, cada um fazendo uma coisa simples, que podia ser encadeada com scripts Perl para fazer qualquer coisa.
Essa abordagem fazia sentido na época, pois eles presumiam que apenas especialistas — como a equipe do kernel Linux — usariam essa ferramenta.

Depois, o que aconteceu todo mundo sabe.
Um desenvolvedor chamado Pasquy escreveu alguns scripts Perl, empacotando uma interface unificada para o Git, que virou o que hoje chamamos de comandos CLI.
Esses scripts ficaram populares, foram incorporados ao núcleo do Git, formando a camada de “porcelana” (porcelain).
Curiosamente, esses comandos, desde 2005-2006, praticamente não mudaram.
Inicialmente escritos em Perl, depois reescritos em C, mas a lógica central e a interface de usuário permanecem quase iguais.
Scott disse que, ao escrever a primeira edição do “Pro Git” em 2009, ele descreveu esses comandos, que ainda podem ser usados exatamente do mesmo jeito.

Essa estabilidade, de certa forma, é uma coisa boa.
A equipe do Git valoriza muito a compatibilidade retroativa, e reluta em remover funcionalidades existentes, para não quebrar fluxos de trabalho atuais.
Por outro lado, isso traz um problema fundamental: as hipóteses centrais com que o Git foi projetado estão em desacordo com as práticas modernas de desenvolvimento de software.
O Git foi feito para enviar patches por lista de emails.
Naquela época, o desenvolvedor fazia uma alteração local, gerava um patch, enviava por email para o mantenedor, que revisava e decidia aceitar ou não.
Todo esse fluxo era assíncrono, baseado em texto, single-thread.

E agora?
Temos integração contínua, deploy contínuo, equipes distribuídas colaborando em tempo real, ferramentas de revisão de código, pipelines automáticos de testes e deploys.
E, mais importante, temos agentes de IA escrevendo código em larga escala.
Scott fez uma observação que me impressionou:
Estamos ensinando uma turma de agentes de IA a usar uma ferramenta que foi feita para patches em listas de emails.
Essa dissonância é como colocar um Tesla numa estrada feita para carruagens.

A filosofia Unix do Git também trouxe outro problema: ela tenta atender tanto o computador quanto o humano com uma mesma interface.
Se você roda “git branch”, por padrão, só verá uma lista de ramificações, sem interface de usuário.
Isso porque o Git precisa garantir que a saída seja legível tanto para humanos quanto para outros programas.
Essa concessão resulta em um sistema que não é amigável ao usuário, nem otimizado para máquinas.
Embora alguns comandos tenham a opção “–porcelain” para saída legível por máquina, ela não é padrão, e muitos comandos nem oferecem essa opção.

Novos desafios na era dos agentes de IA: um único diretório de trabalho já não basta

Quando a IA começa a participar massivamente da programação, as limitações do Git ficam mais evidentes.
Recentemente, tentei usar múltiplos agentes de IA trabalhando simultaneamente e percebi que o conceito básico do Git — um desenvolvedor, uma ramificação, um fluxo linear — já não funciona mais.
Os desenvolvedores modernos não trabalham de forma linear.
Você pode ter vários agentes rodando ao mesmo tempo: um consertando bugs na interface, outro otimizando consultas ao banco, um terceiro atualizando documentação.
Mas o sistema de indexação do Git entra em colapso nesse cenário, pois presume que sua cópia local representa uma modificação única, atômica, no repositório.

A solução tradicional é usar worktrees, criando múltiplas cópias do repositório para tarefas paralelas.
Porém, isso traz novos problemas:
Se cinco agentes trabalham ao mesmo tempo, você precisa de cinco cópias completas do repositório, consumindo espaço em disco.
E esses agentes ficam isolados, sem visibilidade do que os outros estão fazendo, até tentarem mesclar e encontrarem conflitos.
Quando isso acontece, o custo de resolver conflitos é alto demais.

O GitButler propõe uma solução inovadora: ramificações paralelas (parallel branches).
É uma ideia que me chamou atenção.
São como ramificações normais, mas você pode abrir várias ao mesmo tempo.
Você consegue os benefícios do worktree (isolamento lógico), sem precisar copiar todos os arquivos.
Todos os agentes operam na mesma pasta de trabalho, mas suas modificações ficam em ramificações virtuais diferentes.
Scott descreveu uma cena que achei genial: eles fizeram dois agentes trabalharem ao mesmo tempo, ambos querendo editar o mesmo arquivo, mas de formas incompatíveis.
O que aconteceu?
Um agente empilhou sua ramificação sobre a do outro, continuou trabalhando e fez commit na sua pilha.
Essa resolução inteligente de conflitos, que no fluxo tradicional do Git seria quase impossível, é uma inovação.

Um experimento que achei interessante foi uma tentativa de criar um canal de comunicação entre múltiplos agentes, para que eles trocassem informações sobre o que estavam fazendo.
Scott disse que parecia uma ideia muito legal, eles poderiam ver as conversas entre agentes, e até liberar isso.
Porém, após testes, perceberam que essa comunicação explícita não ajudava.
Os agentes, ao perceberem que outro agente estava modificando um arquivo, automaticamente deduziram o motivo e ajustaram sua estratégia.
Eles não precisavam de uma comunicação explícita, pois ela gerava overhead e tornava tudo mais lento.
Essa descoberta é reveladora: não podemos simplesmente aplicar o modo de colaboração humano aos agentes.
Eles têm seu próprio jeito de trabalhar.

Redesenho da interface: para humanos, agentes e scripts

O CLI do GitButler, lançado recentemente, chamou minha atenção.
Não é só um wrapper do Git, mas uma repensada completa de como uma ferramenta de linha de comando deve ser projetada.
Scott comentou uma observação interessante: cerca de 80% dos desenvolvedores ainda usam a linha de comando para interagir com o Git, mesmo com várias interfaces gráficas disponíveis.
A razão é simples: a maioria das GUIs do Git só empacotam comandos, sem acrescentar funcionalidades, e acabam tornando o processo mais lento.
Se você já sabe o comando, digitar direto é mais rápido.

Porém, o CLI do GitButler é diferente.
Ele oferece diferentes formatos de saída para diferentes cenários.
Se você roda um comando, ele fornece uma saída otimizada, legível por humanos, com dicas e sugestões.
Se você adiciona “–json”, ele devolve um JSON estruturado, fácil de usar em scripts.
Eles até pensam em um “–markdown” para agentes, pois esse formato é mais fácil de inserir no contexto de IA.

Mais interessante ainda: eles observam o comportamento dos agentes para melhorar o design.
Perceberam que, mesmo com “–json”, os agentes preferem usar a saída legível, e depois processar com jq ou Python.
Outro ponto é que, após qualquer comando que modifique o repositório, os agentes quase sempre executam “git status” para verificar o estado.
Por isso, adicionaram uma opção “–status-after” em todos esses comandos, que exibe o status automaticamente após a operação.
Essa abordagem, que contraria a filosofia Unix tradicional, é perfeita para agentes, mesmo que não seja ideal para scripts.

Eles também exploram como fornecer mais contexto ao agente na saída.
Por exemplo, incluir dicas como “se quiser fazer isso, rode tal comando”.
Embora isso pareça redundante para humanos, para agentes é uma informação valiosa que acelera a tomada de decisão.
Scott comentou que esse é um problema de UX muito interessante, pois precisamos tratar o agente como uma nova “persona” de usuário, com necessidades e comportamentos diferentes.

A mudança essencial no desenvolvimento de software: de escrever código para escrever especificações

Durante a entrevista, Scott trouxe uma ideia que me fez refletir:
No futuro, os melhores engenheiros de software podem não ser aqueles que escrevem o código mais bonito, mas os que melhor comunicam, escrevem bem e descrevem suas ideias claramente.
Isso parece contraintuitivo, pois muitos escolhem programação justamente para evitar interação com pessoas.
Porém, faz sentido: com IA gerando código de forma eficiente, o gargalo não é mais a implementação, mas a capacidade de descrever claramente o que se quer.

Scott compartilhou seu fluxo de trabalho:
Hoje, ele passa a maior parte do tempo escrevendo especificações detalhadas de funcionalidades.
Quando precisa de uma decisão de projeto, ele descreve para a IA implementar, testa o resultado, e ajusta a especificação se necessário.
Esse ciclo é rápido, pois ele não precisa escrever todo o código manualmente.

O aspecto mais interessante é que isso permite um “show and tell” mais ágil.
Ao invés de criar um protótipo completo para validar uma ideia, você gera rapidamente uma versão funcional, que a equipe pode experimentar.
Assim, o ciclo de validação fica muito mais curto.

Por outro lado, isso traz um novo desafio:
A colaboração em equipe passa a depender mais de um entendimento comum do que se quer, do que de uma implementação específica.
Scott disse que muitos desenvolvedores, especialmente os mais confiantes, acham que seu código é a melhor documentação.
Porém, na era da IA, essa postura não funciona mais.
É preciso ser capaz de explicar claramente suas intenções, criar especificações compreensíveis por humanos e IA.
Escrever bem virou uma habilidade fundamental.

Isso também me faz pensar no futuro das revisões de código.
Scott fez uma pergunta provocativa:
Se você perguntar para a maioria dos engenheiros, eles realmente leem cada linha de um PR?
Eles testam localmente?
Ou só dão uma olhada rápida, aprovando se não parecer problemático?
A maioria faz o último, pois uma revisão completa é cara e o benefício nem sempre compensa.

Na era dos agentes de IA, isso pode mudar.
Agentes podem revisar cada linha, rodar testes, detectar problemas potenciais com precisão.
Eles não se cansam, não ficam impacientes, mantêm um padrão consistente.
Assim, o trabalho humano na revisão pode focar em questões mais estratégicas: se a mudança faz sentido para o produto, se atende às necessidades reais, se a arquitetura está adequada.
Detalhes de implementação, bugs sutis, podem ficar por conta da IA.

PRs e Issues: a evolução de um modo de colaboração que já dura 20 anos

O sistema de Pull Requests do GitHub virou padrão na colaboração open source, mas Scott acredita que há problemas fundamentais nele.
PRs são baseados em ramificações, não em patches.
Isso gera uma quantidade enorme de “lixo” — commits que só corrigiram um bug pequeno, ou esqueceram de incluir um arquivo.
No fluxo de PR, o que importa é o conjunto de mudanças na ramificação, não os commits individualmente.
Por isso, a qualidade das mensagens de commit muitas vezes é negligenciada, e o próprio histórico fica perdido após a fusão.

Na era do email, isso não era problema.
Cada patch tinha uma mensagem bem escrita, que funcionava como uma descrição do PR.
A revisão era baseada em patches, cuja qualidade dependia da mensagem.
Hoje, com o GitHub, perdemos essa disciplina.
Scott acha que o futuro da revisão deve voltar a um modelo baseado em patches, mas com as vantagens das ferramentas modernas.
A revisão deve ser local, você deve poder testar e rodar o código.
Agentes podem ajudar a automatizar testes, marcar problemas, deixando o humano focar no que realmente importa.

Outro ponto importante é a comunicação entre equipes.
Scott apontou que uma das maiores falhas no desenvolvimento é a falta de comunicação em tempo real.
Se você está mexendo em um arquivo, e seu colega também, só vai descobrir na hora de fazer merge, e aí pode ter conflitos.
Se fosse possível saber o que o outro está fazendo em tempo real, evitaríamos muitos problemas.
Para humanos, isso é difícil, pois exige coordenação constante.
Para agentes, não.
Eles podem usar o tempo ocioso para conversar, entender o que os outros agentes ou humanos estão fazendo, detectar conflitos antecipadamente ou ajustar suas tarefas.

O sistema de metadados que o GitButler está explorando também é fascinante.
Querem poder anexar registros de diálogo, processos de raciocínio dos agentes, e contexto relevante às ramificações ou commits.
Hoje, o suporte do Git a esse tipo de metadado é limitado.
Mas esses dados podem ser valiosos para entender por que uma decisão foi tomada, qual foi o raciocínio por trás do código.
Porém, há um problema de volume de dados:
Mesmo armazenando textos, esses metadados podem crescer rapidamente.
Eles precisam usar técnicas de grandes repositórios, como as usadas por equipes como Chrome ou Microsoft Office, para gerenciar essa escala.

Reflexões finais sobre essa transformação

Depois de conhecer a história do GitButler e as ideias de Scott, tenho algumas impressões profundas.
A engenharia de software está passando por uma mudança de paradigma radical, e o sistema de controle de versão, como infraestrutura, precisa evoluir junto.
O design do Git, que foi inovador há 20 anos, hoje virou uma limitação.
O que precisamos não é de um “Git melhor”, mas de uma infraestrutura redesenhada para os fluxos de trabalho modernos e a era da IA.

Scott falou algo que ressoa comigo:
Ele mencionou a ideia de “ponto lógico final”.
Durante uma startup de aprendizado de idiomas, muitas pessoas diziam que a tradução em tempo real tornaria o aprendizado de línguas obsoleto.
Ele discordou: mesmo com tradutores perfeitos, você ainda precisa usar o tradutor, e a experiência de comunicação não é tão boa quanto falar na mesma língua.
Ele passou uma semana no Japão usando tradutores, e mesmo assim, a comunicação não era natural.
Para programação, é semelhante.
Por mais avançadas que sejam as IAs, elas não substituem completamente o julgamento, a criatividade e a comunicação humanas.

Sobre o futuro do GitHub, Scott tem uma visão realista.
O maior trunfo do GitHub é sua base de usuários; sua maior limitação é ser uma grande corporação, lenta para inovar.
O setor todo busca o “próximo GitHub”, mas Scott aponta que essa questão pode estar mal colocada.
O GitHub não é uma evolução de algo, mas uma criação de um novo modo de colaboração.
No futuro, podem surgir formas de colaboração totalmente diferentes, que ainda nem imaginamos.

Acredito que o valor do GitButler não está só nas funcionalidades específicas, mas na forma de pensar que ele representa.
Eles questionam hipóteses que damos como certas:
Por que só podemos trabalhar em uma ramificação de cada vez?
Por que os commits precisam ser lineares?
Por que agentes e humanos usam a mesma interface?
Por que colaboração depende de PRs e issues?
Pensar a partir de princípios fundamentais é o que mais precisamos nesse mundo de rápidas mudanças.

Percebo também que, como desenvolvedores, precisamos desenvolver novas habilidades.
Escrever especificações claras, comunicar ideias de forma eficaz, entender o funcionamento dos agentes de IA — essas podem ser habilidades mais importantes do que apenas codificar.
Para muitos, isso será um desafio, especialmente para quem escolheu programar para evitar interação social.
Mas também é uma oportunidade de nos libertar dos detalhes de implementação, focando em tarefas mais criativas: definir problemas, projetar soluções, fazer trade-offs.

O financiamento de 17 milhões do GitButler é só o começo.
Nos próximos anos, veremos mais iniciativas de repensar a infraestrutura de desenvolvimento de software.
Controle de versão, revisão de código, gerenciamento de projetos, testes, deploys — tudo isso foi criado antes da era da IA, e precisa ser revisitado.
Aqueles que se adaptarem primeiro terão uma vantagem competitiva enorme.

No final, o desenvolvimento de software se tornará mais centrado na comunicação, colaboração e tomada de decisão, e menos na sintaxe e detalhes de implementação.
Isso pode assustar alguns programadores tradicionais, mas vejo como algo positivo.
Torna a programação mais próxima de resolver problemas, menos presa a detalhes técnicos.
Quando não precisarmos mais memorizar comandos complexos do Git, resolver conflitos manualmente ou gastar horas escrevendo código repetitivo, poderemos focar no que realmente importa: entender o usuário, criar soluções elegantes, desenvolver produtos valiosos.
Esse é o verdadeiro núcleo do desenvolvimento de software, e é para isso que o GitButler parece nos conduzir de volta.