Você Sabe o que Acontece Entre Dois Commits?

Pensa comigo: você abre um projeto, faz 47 edições, conversa com um agente de IA, refatora três arquivos, muda de ideia duas vezes, e no final digita git commit -m "fix: ajusta validação". Pronto. Tudo que aconteceu entre o commit anterior e esse? Sumiu. O Git guardou o antes e o depois, mas a história do meio, a parte que mais importa, morreu.

Eu sempre achei isso um absurdo silencioso. A gente aceita porque “é assim que funciona”. Mas o pessoal do Zed decidiu que não precisa ser assim. E criaram o DeltaDB.

O que é o Zed DeltaDB

O DeltaDB é um sistema de versionamento criado pela Zed Industries (a mesma empresa por trás do editor Zed) que funciona de um jeito radicalmente diferente do Git. Em vez de gravar snapshots do código em pontos discretos (commits), ele grava cada operação individual que acontece no seu código. Cada edição, cada mudança, cada interação com um agente de IA: tudo vira um “Delta” com identidade própria.

Nathan Sobo, fundador do Zed, resumiu assim: “O DeltaDB captura cada operação entre os commits e dá a cada uma um identificador estável.”

Na prática, isso significa que você pode apontar para qualquer momento na evolução do seu código. Não só para o commit das 14h32, mas para aquela edição específica que o agente de IA fez na linha 47 do arquivo auth.ts às 14h17. Cada micro-mudança tem nome, endereço e contexto.

Por que o Git não resolve mais

Antes que alguém feche a aba pensando “mais um que quer reinventar o Git”, vale entender o problema real. O Git foi criado em 2005 por Linus Torvalds para versionar o kernel Linux. Funcionou absurdamente bem por duas décadas. Mas o jeito que a gente escreve código mudou.

Em 2026, boa parte do código é escrito (ou co-escrito) por agentes de IA. Você conversa com o Claude, o Copilot, o Cursor Agent, e eles editam seus arquivos. O problema é: quando você faz git log, não tem nenhum registro dessa conversa. O commit diz “refatora módulo de auth”, mas não diz que o agente sugeriu três abordagens diferentes, que você rejeitou duas, e que a terceira foi modificada manualmente antes de funcionar.

Esse contexto é ouro. É o “porquê” por trás do “o quê”. E o Git simplesmente joga fora.

Como funciona por baixo: CRDTs e Deltas

O DeltaDB usa CRDTs (Conflict-free Replicated Data Types) como base técnica. Se você nunca ouviu falar, CRDTs são estruturas de dados que permitem edição simultânea sem conflitos. É a mesma tecnologia que faz o Google Docs funcionar sem aquele inferno de “alguém está editando este arquivo”.

Cada operação no seu código vira um Delta. Pense num Delta como um commit atômico, mas de verdade: uma inserção de caractere, uma deleção de bloco, uma renomeação de variável. Cada Delta recebe um identificador único e persistente.

 Delta #a7f3 → inseriu função validateToken() em auth.ts Delta #a7f4 → agente adicionou tratamento de erro (conversa #12) Delta #a7f5 → dev removeu console.log de debug Delta #a7f6 → agente refatorou para usar early return (conversa #12) 

O pulo do gato: esses Deltas são linkados às conversas que os produziram. Então o Delta #a7f4 sabe que foi o resultado da mensagem “adiciona tratamento de erro para tokens expirados” na conversa #12 com o agente.

Você pode navegar nos dois sentidos: do código para a conversa (“por que essa linha existe?”) ou da conversa para o código (“o que aquela sugestão do agente mudou?”).

Referências que não quebram

Todo dev já passou por isso: alguém comenta num PR “olha a linha 47 do auth.ts” e quando você vai ver, a linha 47 já virou a linha 52 porque outro commit mexeu no arquivo.

No DeltaDB, referências apontam para Deltas, não para linhas. Como cada Delta tem identidade própria, a referência sobrevive a qualquer mudança posterior no arquivo. Você pode mover o código, refatorar, renomear o arquivo, e a referência continua apontando para o lugar certo.

Isso é particularmente útil para code reviews. Em vez de “olha a linha X”, você aponta para o Delta específico. E consegue ver o código como ele estava naquele exato momento, ou como ele está agora, depois de todas as mudanças subsequentes.

 # No Git: referência frágil "Veja o arquivo auth.ts, linha 47" # Problema: a linha 47 muda com cada commit  # No DeltaDB: referência estável "Veja o Delta #a7f4" # Aponta para a operação exata, independente de mudanças posteriores 

Colaboração em tempo real (de verdade)

O Git tem um modelo de colaboração baseado em cerimônia: você commita, pusha, abre um PR, alguém revisa, mergea. É um protocolo social, não técnico. Funciona, mas é lento.

O DeltaDB permite que múltiplas pessoas (e múltiplos agentes de IA) editem os mesmos arquivos simultaneamente. Sem conflitos. Sem merge hell. Sem “por favor, pulle antes de pushar”.

Nathan Sobo descreveu: “Um colega pode entrar enquanto o trabalho ainda está acontecendo, conversar com o agente que fez o trabalho, e anotar conforme avança.”

Na prática, isso elimina aquele ciclo doloroso:

1. Dev A pede pro agente refatorar um módulo
2. Dev A commita e pusha
3. Dev A abre PR e espera review
4. Dev B lê o PR sem contexto
5. Dev B comenta “por que você fez assim?”
6. Dev A responde 3 horas depois
7. Repete até o merge

Com DeltaDB, Dev B entra no workspace em tempo real, vê o agente trabalhando, lê a conversa que motivou cada mudança, e faz anotações instantaneamente. O review acontece junto com o desenvolvimento, não depois.

Branches virtualizados: cada ponto é um branch potencial

No Git, criar um branch é relativamente barato, mas não é grátis. Tem overhead mental (nome do branch, checkout, stash do trabalho atual) e overhead técnico (cópia do worktree).

No DeltaDB, qualquer ponto na história, incluindo estados intermediários que nunca viraram commits, pode ser origem de um branch. O worktree é virtualizado, então criar um branch é uma operação praticamente sem custo.

Quer testar uma abordagem diferente a partir daquela edição que o agente fez há 20 minutos? Só criar um branch a partir daquele Delta. Sem stash, sem checkout, sem commit temporário com mensagem “WIP dont merge plz”.

 # Cenário no Git git stash git checkout -b experiment # trabalha... git checkout main git stash pop  # Cenário no DeltaDB # Clica no Delta #a7f4 → "Branch from here" # Pronto. Dois branches coexistem, editáveis em tempo real. 

Agentes de IA como cidadãos de primeira classe

Aqui é onde o DeltaDB mostra que foi pensado para 2026, não para 2005. Agentes de IA não são um add-on ou plugin: são parte fundamental da arquitetura.

Cada agente que trabalha no seu código tem seu histórico de conversas versionado junto com as mudanças. E mais: você pode “convocar” agentes anteriores para perguntar sobre decisões de design.

Imagine: você está debugando um módulo que outro dev (com ajuda de um agente) escreveu há 3 semanas. No Git, você tem o commit e talvez uma mensagem críptica. No DeltaDB, você pode ver a conversa completa entre o dev e o agente, entender por que cada decisão foi tomada, e até invocar o contexto daquele agente para tirar dúvidas.

Isso muda fundamentalmente como equipes trabalham com IA. O agente deixa de ser uma ferramenta descartável (“gera esse código e tchau”) e passa a ser parte do registro histórico do projeto. Seu “raciocínio” fica preservado.

DeltaDB não substitui o Git (pelo menos por enquanto)

Antes de sair deletando seus repositórios: o DeltaDB se posiciona como complemento ao Git, não substituto. O Git continua sendo responsável por CI/CD, integração com GitHub/GitLab, e a camada de “publicação” do código.

O DeltaDB cuida da camada anterior: tudo que acontece antes e entre os commits. A colaboração ao vivo, as conversas com agentes, os experimentos descartados, as decisões de design.

Pense assim:

• DeltaDB = caderno de rascunho versionado (cada rabisco tem história)
• Git = livro publicado (versão final, limpa, com ISBN)

Os dois coexistem. Você trabalha no DeltaDB, e quando está satisfeito com o resultado, faz o commit normal no Git. Mas agora o commit tem um link para todo o contexto que o produziu.

A Zed Industries e a aposta bilionária

A Zed Industries não é uma startup de fundo de quintal. O editor Zed, escrito em Rust, já conquistou uma base fiel de desenvolvedores que queriam algo mais rápido que o VS Code. Com o DeltaDB, a empresa recebeu aporte da Sequoia Capital (a mesma que investiu em Apple, Google, e Stripe) e está claramente apostando que o futuro do desenvolvimento é colaborativo, em tempo real, e entrelaçado com IA.

O DeltaDB entrou em early access em junho de 2026, com beta aberto para quem se inscrever na waitlist. Ainda não há informações sobre preço, mas considerando que o editor Zed é open source, é provável que exista uma versão gratuita com features premium para times.

Quem deveria ficar de olho

Se você trabalha sozinho em projetos pessoais e usa Git normalmente, o DeltaDB provavelmente não vai mudar sua vida agora. Mas se você se encaixa em algum desses cenários, vale entrar na waitlist:

• Equipes que usam IA pesadamente: o registro de conversas com agentes é game-changer para code review e onboarding
• Pair programming remoto: colaboração em tempo real sem o overhead de Live Share ou tmate
• Projetos com muita rotatividade: o contexto preservado ajuda novos membros a entenderem o “porquê” do código
• Quem sofre com merge conflicts: CRDTs eliminam a categoria inteira de problemas

Como seria o dia a dia com DeltaDB

Para deixar menos abstrato, imagina um cenário real. Você está construindo uma API de pagamentos. Segunda de manhã, abre o Zed, inicia uma conversa com o agente e pede: “cria o endpoint de checkout com validação de cartão”. O agente gera o código, você ajusta uns detalhes, e tudo fica registrado: cada linha que o agente escreveu, cada correção que você fez, a conversa inteira.

Terça, um colega abre o mesmo workspace (em tempo real, sem precisar de push) e vê que o endpoint de checkout existe. Ele clica numa função e vê que foi o agente quem escreveu, a pedido seu, com tal justificativa. Ele discorda de uma decisão arquitetural, anota direto no Delta, e você recebe o feedback instantaneamente.

Quarta, o tech lead entra para revisar. Em vez de ler um diff gigante num PR, ele navega pela timeline de Deltas, entende a evolução do código passo a passo, e aprova. O commit pro Git sai limpo, com uma mensagem decente, e todo o contexto fica preservado no DeltaDB para consulta futura.

Isso não é ficção científica. É o que a Zed está construindo.

O elefante na sala: vendor lock-in

Toda ferramenta proprietária de versionamento carrega esse risco. O Git é aberto, descentralizado, e funciona offline. O DeltaDB, pelo que foi divulgado até agora, depende da infraestrutura do Zed.

Isso não invalida a proposta, mas é algo para ficar atento. Se amanhã a Zed Industries fechar as portas (improvável com Sequoia por trás, mas possível), o que acontece com seus Deltas? Esse é o tipo de pergunta que precisa ter resposta clara antes de qualquer adoção em produção.

A boa notícia é que o editor Zed é open source. Se o DeltaDB seguir o mesmo caminho, o risco de lock-in cai drasticamente.

O versionamento precisa evoluir

Git é brilhante. Linus Torvalds é um gênio. Mas o Git foi desenhado para um mundo onde humanos escreviam código em editores de texto, commitavam em blocos, e faziam review por email (sim, o kernel Linux ainda funciona assim).

Em 2026, agentes de IA escrevem código junto com humanos, equipes colaboram em tempo real, e o contexto por trás de cada decisão vale mais do que a decisão em si. O DeltaDB é a primeira ferramenta que eu vejo tentando resolver isso de forma estrutural, não como um band-aid em cima do Git.

Vai substituir o Git? Provavelmente não tão cedo. Mas vai mostrar que o versionamento pode ser muito mais do que uma sequência de snapshots. E quando a próxima geração de devs olhar para trás, talvez ache tão absurdo perder o contexto entre commits quanto a gente acha absurdo versionar código com pastas zipadas.

Se quiser testar, a waitlist está aberta no site do Zed.