O Criador do BitTorrent Diz que o Git está Quebrado…

💡 TL;DR (Longo Demais; Não Li)

Principais conclusões em 60 segundos:

Bram Cohen (criador do BitTorrent) acaba de publicar o Manyana — uma prova de conceito de controle de versão baseada em CRDTs onde os merges nunca falham. 470 linhas de Python. Domínio público. A apresentação de conflitos por si só já está uma geração à frente dos marcadores opacos <<<<<<< / >>>>>>> do Git.

Jujutsu (jj) acumulou silenciosamente mais de 27.000 estrelas no GitHub e conta com uma equipe de engenharia do Google por trás. Ele envolve a camada de armazenamento do Git com uma experiência de usuário radicalmente melhor: a cópia de trabalho funciona como um commit, sem área de staging, undo nativo e uma linguagem de consulta para commits chamada revsets.

O teste de estresse dos agentes: O Git foi projetado para humanos fazendo cerca de 10 commits por dia. O enxame de compiladores da Anthropic gerou mais de 100 mil linhas de código com 16 agentes. O FastRender da Cursor lançou 600 agentes em um navegador, gerando 3.342 commits com uma taxa de falha de CI de 88%. A heurística de merge de três vias do Git quebra sob fluxos de trabalho de agentes massivamente paralelos.

CRDTs são o encaixe natural para enxames de agentes: merges comutativos significam que a ordem não importa, resultados determinísticos significam que a reprodutibilidade é garantida, e a contagem de gerações lida com os ciclos de adição/exclusão que os agentes produzem na velocidade das máquinas.

Três filosofias estão surgindo: Manyana (focado em CRDT, merges nunca falham), Jujutsu (focado na UX, compatível com Git) e Pijul (focado na teoria, patches como cidadãos de primeira classe). O Git não morrerá — ele se tornará o TCP/IP. A questão é o que o envolverá.

Resumo: Se você está construindo orquestradores de agentes, estude CRDTs. Se você é um engenheiro Staff+ cansado das ginásticas do git stash, experimente o jj em um projeto pessoal esta semana. O futuro do controle de versão não é substituir o Git. É fazê-lo sobreviver à era dos agentes.

A Coceira de 21 Anos

Em abril de 2005, Linus Torvalds estava furioso. O BitKeeper havia revogado a licença gratuita do kernel Linux, e mil desenvolvedores subitamente ficaram sem sistema de controle de versão. Linus sentou-se e, no que continua sendo um dos feitos mais impressionantes de engenharia movida pelo ódio, construiu o Git em 10 dias.

O Git resolveu brilhantemente um problema de 2005. Equipes de 10 a 50 desenvolvedores. Commits manuais. Merges semanais. Um modelo de branching onde os humanos conseguiam manter todo o grafo de dependências em suas cabeças. A filosofia distribuída que tornava cada clone um repositório completo foi revolucionária — e escalou majestosamente por 20 anos.

Mas 2026 não é 2005.

Em fevereiro, a Anthropic encarregou 16 agentes Claude Opus 4.6 de construir um compilador C do zero — mais de 100.000 linhas de Rust, sem dependências, 99% de aprovação na suíte de testes do GCC. Quase ao mesmo tempo, a Cursor apontou 600 agentes GPT-5.2 para construir um navegador web — 3.342 commits em 7 dias, mais de 1 milhão de linhas de código e uma taxa de falha de CI de 88%. Os agentes não eram ruins. A infraestrutura de coordenação é que era.

Quando centenas de agentes fazem commits em paralelo, a heurística de merge de três vias do Git — uma aproximação brilhante projetada para colaboração em escala humana — começa a produzir falhas catastróficas. Os conflitos de merge multiplicam-se combinatoriamente. Os pipelines de CI engasgam. A suíte de testes, que deveria ser a orquestradora, torna-se o gargalo.

O Git não está quebrado. Ele tem 21 anos, e o mundo mudou sob seus pés.

Nesta semana, dois projetos aterrissaram no Hacker News representando os desafios mais credíveis ao modelo de merge do Git em uma década. Um é uma prova de conceito de 470 linhas do criador do BitTorrent. O outro é uma ferramenta apoiada pelo Google com 27.000 estrelas que seus colegas nem notarão que você está usando.

Manyana: Quando os Merges Nunca Falham

Bram Cohen não precisa de introdução, mas vamos dar uma de qualquer forma: criador do BitTorrent, um dos protocolos de sistemas distribuídos mais elegantes já projetados. Ele vem pensando em controle de versão há pelo menos 15 anos (seus posts no LiveJournal de 2010 discutiam algoritmos de merge), e foi coautor do Codeville, uma tentativa precoce de um VCS melhor.

Em 22 de março de 2026, Cohen publicou o Manyana — uma prova de conceito para controle de versão baseado em CRDT. Toda a implementação tem 470 linhas de Python. É de domínio público. E contém ideias que influenciarão a forma como pensamos sobre merges na próxima década.

O Insight Central

CRDTs — Conflict-Free Replicated Data Types (Tipos de Dados Replicados Sem Conflitos) — são uma estrutura de dados do mundo de sistemas distribuídos que garante a consistência eventual. As propriedades fundamentais: os merges são comutativos (merge(A, B) = merge(B, A)) e associativos (merge(merge(A, B), C) = merge(A, merge(B, C))). Os sistemas de controle de versão tradicionais aproximam essas propriedades com heurísticas. CRDTs as fornecem como garantias matemáticas.

Verified SourceGitHub — bramcohen/manyana

O algoritmo de merge do Manyana sempre produz um resultado. Não há caso de falha. Mas "sem conflitos" não significa "sem conflitos que valha a pena mostrar ao usuário".

É aqui que todas as tentativas anteriores de um VCS baseado em CRDT estagnaram. Se os merges nunca falham, o que significa um "conflito"? A resposta de Cohen é elegante: um conflito é evidenciado quando edições concorrentes estão muito próximas uma da outra — linhas adjacentes ou linhas separadas apenas por espaços em branco. O merge ainda produz um resultado determinístico. No entanto, o usuário vê uma saída anotada que explica o que cada lado fez, não apenas como cada lado ficou.

O Problema de Excluir vs. Inserir

Considere o caso mais difícil. Dois desenvolvedores criam branches de um arquivo contendo uma função. Um exclui a função inteira. O outro adiciona uma linha de log no meio.

O Git fornece dois blocos opacos separados por marcadores de conflito. Você precisa reconstruir mentalmente o que aconteceu. O Manyana rotula cada seção com a ação e qual lado a executou: begin deleted left, begin added right, begin deleted left. Você consegue ver a estrutura do conflito: a esquerda excluiu a função, a direita inseriu uma linha na região excluída.

Isso não é uma melhoria cosmética. É um modelo fundamentalmente diferente de apresentação de conflitos — um que dá ao revisor informações suficientes para tomar uma decisão fundamentada sem precisar comparar os branches manualmente.

O Weave e a Contagem de Gerações

Sob o capô, o Manyana utiliza um weave — uma estrutura linear única contendo cada linha que já existiu no arquivo, intercalada com metadados. Cada linha carrega três informações: profundidade (codifica a estrutura de árvore das inserções), direção da âncora (se uma linha foi inserida acima ou abaixo de sua vizinha) e uma contagem de geração (um número inteiro que incrementa a cada ciclo de adição/exclusão — ímpar significa presente, par significa excluído).

A contagem de geração merece atenção porque resolve o "problema do desfazer local" que derrubou todas as tentativas de semânticas de merge baseadas em princípios. Cohen detalha um caso de cruzamento (criss-cross) em seu README que demonstra por que interpretar exclusões como desfazeres locais leva a situações onde um filho sofrido no merge não se parece com nenhum de seus pais — um resultado que viola as expectativas básicas do usuário. A contagem de geração é simples, determinística e nunca produz esses paradoxos.

A Armadilha do Cherry-Pick

Cohen identifica três abordagens para o cherry-picking em um sistema CRDT e chama explicitamente duas delas de armadilhas. Patches combinados (squashed) podem fazer com que código de aparência idêntica resulte em linhas duplicadas no merge (uma consequência do histórico estrutural). Reaplicar patches exatos funciona, mas é frágil. Sua abordagem recomendada — marcar um intervalo de commits como "já aplicados" — é a mais limpa, mas exige que o sistema rastreie a procedência do merge.

Este nível de honestidade sobre as compensações (trade-offs) é o motivo pelo qual as discussões no Hacker News e Lobsters foram tão substantivas. Cohen não está vendendo um produto. Ele está publicando um documento de design coerente com 470 linhas de prova executável.

Jujutsu: O Git que Você Gostaria de Ter tido

Se o Manyana é um avanço teórico, o Jujutsu (jj) é a revolução prática que já está acontecendo.

Criado por Martin von Zweigbergk no Google em 2019, o Jujutsu acumulou mais de 27.000 estrelas no GitHub, mais de 11.000 commits e quase 1.000 forks. O Google o utiliza internamente em alguns dos maiores repositórios do mundo. Ele é escrito em Rust. E aqui está o detalhe crítico: ele utiliza o formato em disco do Git. Seu diretório .git permanece o mesmo. Seus colegas continuam usando git. Seus pipelines de CI/CD não mudam. Você apenas ganha uma interface melhor.

O que o Jujutsu Corrige

A cópia de trabalho é um commit. No Git, a cópia de trabalho é um estado nebuloso que existe fora do grafo de commits. É por isso que o git stash existe — você precisa engavetar temporariamente o trabalho não finalizado. No Jujutsu, fazer o checkout de um commit cria um novo commit de cópia de trabalho sobre ele. Cada edição faz parte automaticamente do grafo de commits. O git stash torna-se desnecessário. O erro "Error: Your local changes to the following files..." nunca aparece.

As operações são imutáveis. Cada ação cria uma nova entrada em um log de operações. Cometeu um erro? jj undo. Isso não é o git reflog — um mecanismo de recuperação que a maioria dos desenvolvedores nem sabe que existe. É um desfazer de primeira classe, integrado ao modelo mental central.

Revsets. O Jujutsu inclui uma linguagem de consulta para selecionar commits. Quer todos os commits da Alice que tocam arquivos Python? jj log -r "author(alice) & file(*.py)". Isso transforma a navegação de commits de "ler um paredão de texto no git log" para "consultar um banco de dados estruturado". Para qualquer pessoa que já utilizou fluxos de trabalho avançados do Git, os revsets parecem a funcionalidade que o Git deveria ter tido desde o início.

Sem área de staging. O index — a "área de staging" do Git — é um dos conceitos mais confusos para desenvolvedores de todos os níveis. O Jujutsu o elimina inteiramente. As mudanças são rastreadas automaticamente. Você descreve seu commit quando está pronto, não quando dá um git add.

As Limitações Honestas

O ecossistema do Jujutsu é jovem. As integrações com IDEs são escassas em comparação com as décadas de ferramentas do Git — embora a extensão JJK para o VS Code e a TUI jjui estejam se desenvolvendo ativamente. O fluxo de trabalho de pull requests do GitHub exige contornos (bookmarks em vez de branches). E a comunidade, embora apaixonada, é uma fração da do Git.

ReportedDEV Community — Jujutsu review, March 2026

Para grandes organizações com fluxos de trabalho de Git profundamente enraizados, integrações de CI e centenas de desenvolvedores, o Jujutsu pode ainda não estar pronto. A camada de compatibilidade com o Git significa que você pode usá-lo, mas encontrará arestas onde a abstração fica tênue.

Mas a história da migração é convincente. Como o Jujutsu lê e escreve no mesmo diretório .git, a adoção é incremental e individual. Um desenvolvedor em uma equipe pode mudar para o jj sem que ninguém perceba. Se não der certo, basta excluir a pasta .jj e você estará de volta ao Git puro. Risco zero.

O Teste de Estresse dos Agentes

É aqui que a perspectiva do gsstk adiciona algo de que ninguém mais está falando.

Passamos os últimos dois meses documentando o que acontece quando agentes de IA usam o Git como protocolo de coordenação. Os resultados são contundentes:

O projeto do compilador da Anthropic usou 16 agentes com uma arquitetura de enxame plana baseada em git. Sem orquestrador central — a própria suíte de testes era a orquestradora. Resultado: mais de 100.000 linhas de Rust, 99% de aprovação no teste do GCC. O insight principal: com apenas 16 agentes e uma suíte de testes rigorosa, o modelo de merge do Git aguentou.

O projeto FastRender da Cursor usou mais de 600 agentes com um pipeline hierárquico de planejador/executor/juiz. Resultado: 3.342 commits, mais de 1 milhão de linhas de código, uma taxa de falha de CI de 88% e uma base de código que não compilava. A infraestrutura de merge cedeu sob a explosão combinatória de mudanças paralelas.

O padrão é claro: o merge de três vias do Git funciona na escala humana e até em escalas de pequenos enxames (16 agentes). Ele quebra na escala de grandes enxames (600 agentes). O modo de falha não é culpa do Git — o merge de três vias nunca foi projetado para isso. É uma heurística que assume um número gerenciável de branches concorrentes com sobreposição limitada.

Por que CRDTs são Naturais para Enxames de Agentes

CRDTs resolvem isso por design:

Comutatividade significa que a ordem não importa. Quando 600 agentes estão fazendo commits em paralelo, a ordem em que o trabalho deles é mesclado é não determinística. Com o Git, diferentes ordens de merge podem produzir resultados diferentes (ou conflitos diferentes). Com CRDTs, merge(A, merge(B, C)) é sempre igual a merge(B, merge(A, C)). O orquestrador não precisa impor uma ordenação canônica.

Determinismo significa reprodutibilidade. Se dois orquestradores diferentes mesclarem o mesmo conjunto de saídas de agentes, eles obterão exatamente o mesmo resultado. Isso é crítico para a auditabilidade — você pode reproduzir qualquer sequência de merge e verificar o resultado.

A contagem de gerações lida com ciclos de adição/exclusão na velocidade das máquinas. Agentes iteram muito mais rápido que humanos. Um agente pode adicionar uma função, testá-la, excluí-la, reescrevê-la e fazer o commit — tudo em segundos. A contagem de gerações rastreia isso naturalmente, sem a complexidade de monitorar operações individuais.

O log de operações do Jujutsu é infraestrutura de auditoria gratuita. Cada operação do jj cria uma entrada de log imutável. Quando os agentes estão fazendo mudanças na velocidade das máquinas, ter um histórico completo e consultável de cada operação — não apenas de cada commit — é exatamente o tipo de observabilidade que o OWASP Agentic Top 10 recomenda.

O insight mais profundo: os orquestradores de agentes precisam de um VCS que se comporte como um banco de dados com consistência eventual, não como uma ferramenta projetada para travamento (locking) otimista em escala humana. CRDTs preenchem essa lacuna.

O Cenário: Três Filosofias

O cenário do controle de versão além do Git é mais rico do que a maioria dos desenvolvedores imagina. Três filosofias distintas estão surgindo:

Manyana: CRDT-First

Filosofia: Reconstruir as semânticas de merge a partir de fundamentos matemáticos sólidos. Os merges nunca falham. Os conflitos são anotações informativas, não estados de erro.

Armazenamento: Baseado em weave, autossuficiente. Todo o histórico de um arquivo vive em uma única estrutura.

Maturidade: Prova de conceito. 470 linhas de Python. Sem gerenciamento de repositórios, sem protocolo de rede, sem CLI. Isto é um documento de design com código executável, não um produto.

Prontidão para Agentes: A mais alta em teoria. Comutatividade e determinismo são exatamente o que as arquiteturas de enxame precisam. Mas a anos de distância do uso em produção.

A questão do Pijul: O sistema de controle de versão Pijul utiliza CRDTs para merges desde 2021, com uma abordagem focada na teoria baseada em álgebra de patches. A discussão no Lobsters perguntou imediatamente se Cohen havia reinventado o Pijul. A resposta é matizada — Manyana e Pijul compartilham a base em CRDT, mas diferem na apresentação de conflitos e nas estruturas de dados específicas utilizadas. A contribuição de Cohen reside principalmente na camada de UX: como evidenciar conflitos significativos em um sistema onde os merges são tecnicamente livres de conflitos. Ainda assim, qualquer pessoa interessada no Manyana deve estudar a documentação do Pijul. A polinização cruzada entre esses projetos será mais valiosa do que a competição.

Jujutsu: UX-First

Filosofia: Não reinventar o armazenamento. O modelo de objetos do Git é bom. Corrigir a interface.

Armazenamento: Formato em disco do Git, lido e escrito diretamente. Total interoperabilidade com repositórios e plataformas de hospedagem Git.

Maturidade: Pronto para produção para indivíduos e pequenas equipes. Mais de 27.000 estrelas no GitHub. Utilizado no Google. Desenvolvimento ativo com lançamentos regulares (versão mais recente: v0.39+). Ecossistema crescente de TUIs e extensões para o VS Code.

Prontidão para Agentes: Moderada. O log de operações imutável fornece excelente auditabilidade. Os revsets permitem consultas programáticas de commits. No entanto, o algoritmo de merge ainda é o do Git por baixo dos panos — as melhorias na UX não mudam a semântica de merge.

Sapling: Scale-First

Vale uma breve menção: o Sapling da Meta é um fork do Mercurial com um backend de Git, projetado para monorepos massivos. Ele resolve o problema de escala (escala do Facebook), mas não aborda semânticas de merge ou fluxos de trabalho de agentes. É uma ferramenta de poder para um caso de uso específico, não uma evolução de propósito geral.

Para Onde Isso Está Indo

O Git não morrerá. Ele é infraestrutura — como o TCP/IP, como o POSIX. O diretório .git persistirá como um formato de armazenamento e protocolo de intercâmbio por décadas.

A questão é o que ficará no topo dele. O futuro mais provável:

O Git como camada de armazenamento. Ferramentas estilo Jujutsu como interfaces humanas. Motores de merge baseados em CRDT (descendentes do Manyana) como protocolos de coordenação de agentes. As três camadas servem a diferentes partes interessadas: o Git oferece portabilidade e compatibilidade com o ecossistema, o jj oferece experiência de desenvolvedor e os CRDTs oferecem as garantias matemáticas que as arquiteturas de enxame demandam.

O que Isso Significa para Você

Se você é um engenheiro Staff+ gerenciando fluxos de trabalho de agentes: Comece a avaliar o Jujutsu para o seu desenvolvimento diário. É risco zero (compatível com Git, adotável individualmente) e o log de operações por si só mudará a forma como você pensa sobre o histórico de commits. Instale-o com brew install jj e rode jj git init --colocate em um repositório existente.

Se você está construindo orquestradores de agentes: Estude CRDTs. Leia o README do Manyana de ponta a ponta — é uma aula magna de teoria de sistemas distribuídos aplicada. O modelo de consistência eventual é como os sistemas de coordenação multiagente lidarão com código em produção. Os orquestradores de hoje usam o Git porque ele está lá. Os de amanhã usarão algo que forneça garantias matemáticas sobre o determinismo do merge.

Se você quer contribuir: O Manyana tem 470 linhas de Python em domínio público. Precisa de um algoritmo de diff real (Cohen afirma explicitamente que o SequenceMatcher do Python deve ser substituído por algo como o histogram diff do Git). O Jujutsu precisa de integrações com IDEs — a extensão para o VS Code (JJK) está em desenvolvimento ativo. Ambos os projetos são pequenos o suficiente para que um único contribuidor experiente cause um impacto significativo.

Se você é um líder de engenharia: Da próxima vez que sua equipe debater estratégias de branching, considere que o próprio debate pode estar obsoleto. Quando os merges nunca falham, quando as cópias de trabalho são commits, quando cada operação é desfazível, as cerimônias elaboradas em torno de GitFlow e desenvolvimento baseado em trunk tornam-se menos necessárias. A ferramenta deve servir ao fluxo de trabalho, não o contrário.

O futuro do controle de versão não é substituir o Git. É fazer o Git sobreviver à era dos agentes — a era em que o gargalo não é o quão rápido você consegue digitar git commit, mas o quão rápido 600 agentes conseguem se coordenar em uma base de código sem atropelar uns aos outros.

Bram Cohen acabou de nos mostrar como o algoritmo de merge deveria ser. Martin von Zweigbergk já nos mostrou como a interface deveria ser. A questão é quanto tempo a indústria levará para juntar as peças.

Este artigo foi estruturado por humanos e sintetizado com o auxílio de IA sob a persona de Aether (AI).

Fontes Externas

Manyana — Substack de Bram Cohen — Anúncio original e lógica de design
bramcohen/manyana no GitHub — Código-fonte e README completo
jj-vcs/jj no GitHub — Fonte e documentação do Jujutsu
Discussão no Lobsters sobre Manyana — Feedback técnico da comunidade, incluindo comparação com Pijul
Visualizador de Estado de Merge de Simon Willison — Visualização interativa dos algoritmos do Manyana
Steve Krouse — "Relatos sobre a morte do código são muito exagerados" — Ensaio complementar sobre precisão na programação

Leituras Relacionadas no gsstk

The Scars of War: Por Que Linus Torvalds Criou o Git — A história de origem que explica as decisões de design do Git
Filosofia Distribuída: Como o Git Revolucionou o Desenvolvimento — Por que o modelo distribuído do Git foi uma revolução filosófica
Dominando o Fluxo de Trabalho: Branches, Merges e a Arte da Colaboração — As estratégias de branching que os CRDTs podem tornar obsoletas
Git do Zero ao Deploy — O guia Git moderno e sem enrolação (início da série Git do Aether)
Git Hardcore: Hooks, Submodules, Monorepos — Onde o Git começa a mostrar sua idade com bases de código imensas
O Compilador vs. O Navegador: Dois Exércitos de Agentes de IA — Os experimentos de enxame de agentes que expõem os limites do Git
O Experimento FastRender — 600 agentes, 3.342 commits e o problema da coordenação

O Criador do BitTorrent Diz que o Git está Quebrado — 470 Linhas de Python Provam Isso

✨TL;DR / Sumário Executivo