O software é criado entre commits

• DeltaDB é um novo tipo de sistema de controle de versão que versiona junto as conversas com agentes e a árvore de trabalho editada por eles
• O Git é estruturado em torno de commits individuais e não foi projetado para lidar, ao mesmo tempo, com conversas contínuas e mudanças no código enquanto ele segue sendo alterado
• O DeltaDB registra não apenas commits, mas todas as operações que acontecem durante o trabalho como um fluxo detalhado de deltas, atribuindo a cada delta um identificador estável
• As mensagens e as edições geradas por essas mensagens são registradas lado a lado, e várias pessoas e agentes podem editar simultaneamente o mesmo arquivo em máquinas diferentes
• A colaboração pode acontecer de forma mais direta dentro da conversa e da árvore de trabalho, em vez de depender de um processo de revisão posterior a commits e pushes

---

Contexto e problema

• A equipe do Zed não estava acostumada ao modelo de pull request e construiu confiança e entendimento compartilhado trabalhando junta na mesma árvore de trabalho e discutindo enquanto escrevia o código
• O GitHub só permite falar sobre o código depois de fazer commit e push, mas as conversas mais importantes da equipe do Zed normalmente já tinham terminado antes desse ponto
• O Zed começou em 2021 para ir além das limitações do commit, com a proposta de primeiro criar um editor à altura dos melhores desenvolvedores do mundo e depois oferecer dentro dele uma forma melhor de colaboração
• Um problema sobre o qual vinham refletindo havia muito tempo no contexto da colaboração entre humanos ficou ainda mais importante ao colaborar com agentes
• A conversa que gera código está se tornando cada vez mais a verdadeira fonte do software, e essa conversa precisa se referenciar mutuamente com o código, que continua evoluindo e mudando
• Como o Git é estruturado em torno de commits individuais, ele não foi projetado para dar suporte a essa ligação entre conversa contínua e mudanças de código

DeltaDB e os próximos passos

• Não todos os commits, mas todas as operações

  • O DeltaDB divide o trabalho em um fluxo detalhado de deltas e, ao contrário do Git, que armazena snapshots a cada commit, registra todas as operações entre os commits
  • Como cada delta tem um identificador estável, é possível apontar para momentos específicos do processo de evolução mesmo enquanto o código continua mudando
  • A árvore de trabalho passa a ser versionada como o próprio processo de mudança, junto com a conversa que conduz essas mudanças
  • As mensagens e as edições produzidas por elas são registradas lado a lado, sem se separarem
  • O DeltaDB incorpora árvores de trabalho replicadas sem conflito, permitindo que várias pessoas e agentes editem simultaneamente o mesmo arquivo em máquinas diferentes
  • Os arquivos são arquivos reais, os agentes trabalham neles pelo terminal, e o usuário pode montar toda a árvore de trabalho no disco quando quiser para usar suas próprias ferramentas

• O código-fonte agora é a conversa-fonte

  • Como as referências ficam fixadas em deltas, e não em números de linha, elas continuam válidas mesmo quando o código se move para baixo
  • A partir de qualquer linha de uma conversa passada, é possível ir para o código no estado atual ou para o código da época em que o agente o escreveu
  • A partir de qualquer linha de código, é possível encontrar a conversa que criou aquele código e todas as conversas posteriores que o modificaram
  • Os agentes também podem usar essas informações para recuperar o contexto de fundo do código que estão alterando
  • O agente pode chamar o agente que trabalhou anteriormente naquele código e perguntar por que ele foi escrito daquela forma

• Não deveria ser preciso fazer commit para colaborar

  • O objetivo é que a conversa com agentes seja a única conversa necessária para colaborar
  • Um membro da equipe pode entrar enquanto o trabalho ainda está em andamento, conversar com o agente que executou a tarefa e comentar durante o processo
  • Não é preciso esperar primeiro por commit e push para que um colega participe
  • Pull requests, threads de revisão e comentários inline eram procedimentos para recolocar depois no código discussões que estavam em outro lugar
  • Quando código e discussão estão no mesmo lugar, esses procedimentos desaparecem
  • Git e CI permanecem no papel de executar verificações e se conectar ao mundo externo, sem se tornarem o lugar onde a colaboração é forçada a acontecer

• Próximos passos

  • O software agora toma forma não em commits, mas em conversas
  • O DeltaDB é um sistema de controle de versão para isso e deve ser disponibilizado a usuários iniciais nas próximas semanas
  • Se quiser experimentar antes, você pode entrar na lista de espera

[GN⁺]

Comentários do Hacker News

• O trabalho entre commits é uma sopa bagunçada, então olhar para isso não é útil para ninguém. Reescreva o histórico com git rebase para tornar cada commit pequeno e atômico, e faça a história contada pelos commits explicar por que ela ficou do jeito que está agora
  O que realmente aconteceu em ordem cronológica não importa. Concordo que revisar pull requests é tarde demais, mas o problema é que os pull requests são projetados para revisar de uma vez o resultado do branch inteiro, o que dificulta a revisão de commits individuais. A solução deveria ser incentivar commits pequenos e atômicos, para que o trabalho inicial possa ser revisado antes que a funcionalidade ou a correção esteja pronta, em vez de compartilhar todo o ruído

  • Pelos comentários aqui e pela minha rede profissional, as pessoas em geral se dividem em dois grupos. Um usa o Git como uma espécie de salvamento automático bruto e junta tudo na hora de fazer merge; o outro prefere commits atômicos totalmente funcionais e bem organizados
    Pela minha experiência, o 1º é mais comum, talvez porque o GitHub naturalmente dê mais suporte a esse jeito e porque commits cumulativos podem resolver parte dos problemas da opção 2. Se eu tiver de escolher, acho que a opção 1 faz muito mais sentido
  • Isso não é menos um problema de ferramentas como Phabricator ou Gerrit e mais simplesmente um problema do GitHub?
  • Seja uma sopa bagunçada ou não, se disco ou custo não forem um problema, tudo bem alguém — provavelmente um agente — poder ver o que eu fiz
    Não tenho uma convicção fortíssima, mas acho que agentes preferem informação adicional, mesmo que para algumas pessoas isso seja ruído
  • Eu já esperava esse tipo de reação. Ao ler o texto, fiquei com a lembrança de sempre me decepcionar ao ver o mesmo sentimento toda vez que se fala de controle de versão
    Muita gente descarta o histórico com facilidade demais para fazê-lo parecer “limpo”. Não faz sentido, mas de algum modo parece coerente dentro de uma certa lógica de programador que é surpreendentemente comum
    Meu jeito é commitar com frequência, dezenas de vezes por dia. Um commit é um registro do que aconteceu, e eu quero preservar o máximo possível desse registro. Já aconteceu várias vezes de git bisect apontar para um commit minúsculo, de uma linha, que não parecia ter problema nenhum, e assim encontrar um bug sutil descoberto só muito depois
    Na minha visão, controle de código-fonte existe para encontrar esse tipo de coisa. Se eu tivesse que vasculhar todas as linhas de commits grandes, esses problemas seriam muito mais dolorosos
    Por isso realmente não entendo quando vejo pessoas juntando de propósito commits no tamanho de um PR inteiro e abrindo mão da única parte realmente útil do controle de versão. Como há bastante gente no grupo do comentário acima, o plano do autor de manter um registro mais detalhado provavelmente vai ser uma luta difícil
  • O jeito como você usa commits parece parecido com a forma como eu uso PRs empilhados no trabalho
    Boa higiene de commits é difícil de impor no nível do time, mas curiosamente, no nível de PR, as pessoas costumam colaborar bastante para escrever boas explicações e manter os conjuntos de mudanças organizados

• Isso parece uma forma de auto-commit frequente com menos confiança no Git. O Git consegue lidar muito bem com auto-commits frequentes
  Se você quiser preservar a “conversa” dos auto-commits ao longo do tempo enquanto os consolida em commits superiores mais “limpos”, basta usar git merge --no-ff de vez em quando e focar nos commits superiores com ferramentas como --first-parent, em vez dos commits de “conversa”
  O backend do Git já tem muita otimização de banco de dados delta no Git pack e em outras ferramentas e, na verdade, o que precisa de alguns ajustes é o frontend do Git — principalmente --first-parent — e a infinidade de UIs de Git “priorizando/exclusivas para mapa de metrô”. Muita gente acha esse mapa feio, confuso e desagradável, então deveria haver mais UIs de drill-down correspondentes a --first-parent

  • Eu também faço assim. Os commits do branch normalmente eu não olho, mas eles ficam lá se eu precisar. Também dá para configurar o git blame para usar --first-parent

• Concordo com “software é feito entre os commits”, mas não concordo com “o DeltaDB captura todo o trabalho entre cada commit”
  Primeiro, isso parece intrusivo. Eu também não quero uma gravação de tela rodando 24 horas enquanto trabalho. Não diria que é errado minhas falhas aparecerem, mas se estou fazendo bem o meu trabalho, o valor que produzi fica contido nos commits, e isso parece muito menos intrusivo
  Em segundo lugar, eu uso várias ferramentas e não quero integrar tudo isso em algum banco de dados esquisito. Se em certo ponto tudo termina com “um processo externo fez alguma coisa”, qual é o sentido de capturar tudo? É legal que o Zed possa integrar muita coisa, mas isso não quer dizer que eu vá usar tudo o que está integrado ao Zed. Da última vez que vi, ao usar Claude Code via ACP no Zed, nem dava para voltar e editar mensagens anteriores
  Por fim, pessoalmente acho que já perdemos a essência do commit. A maioria das pessoas faz um conjunto arbitrário e ilimitado de mudanças, depois roda git commit, esse conjunto de mudanças é revisado como um blocão enorme e então os commits são unidos. Não é o fim do mundo, mas commits bem lapidados à mão são realmente excelentes. Rode git blame em um projeto que força esse estilo e você vai entender na hora o que quero dizer
  Algo como o DeltaDB só reforça e cristaliza ainda mais o hábito de agrupar commits de qualquer jeito. Se quiser saber o que aconteceu, agora basta bisbilhotar e reproduzir a conversa que a pessoa teve com o LLM
  Esse último ponto é interessante, mas também irritante. Eu não consegui convencer colegas a documentar mudanças e motivações só porque isso era uma boa prática de engenharia útil para o time, mas todo mundo explica de boa para o LLM. Em grande parte isso acontece porque o LLM precisa disso para fazer o trabalho, mas é interessante o quanto as pessoas passam a fazer coisas que antes não fariam só para satisfazer o LLM. De repente, coisas estranhamente não documentadas passam a ser documentadas no CLAUDE.md

• O código escrito entre commits faz parte do meu processo de pensamento. Eu penso escrevendo código, apagando e escrevendo de novo
  O código que vai num commit é escrito para que outras pessoas entendam, e é o resultado do processo de escrever para pensar. Não quero que meus pensamentos sejam serializados, versionados e fiquem publicamente acessíveis
  https://www.nature.com/articles/s44222-025-00323-4

  • Havia o mesmo problema com o JJ. Eu não quero que tudo entre commits seja versionado
    Também não tenho certeza de que todos os estados intermediários entre commits sejam relevantes ou úteis. Mas tenho a sensação de que sou minoria
  • É por isso que uso rebase antes do PR, e não gosto de squash. Daqui a 2 anos você não vai lembrar por que escreveu aquele código daquele jeito, e para entender um bug e identificar uma situação de cerca de Chesterton, tudo o que existe são o delta e o histórico de commits
    Se você faz squash, o que sobra como contexto é um código de 400 linhas que você escreveu “de uma vez” e o pedido de funcionalidade ao qual aquele código foi atribuído. Não ajuda em nada
    A pior pessoa que conheci escrevia um módulo novo e não fazia check-in de nada até que estivesse funcionando em algum nível. Acho que isso também estava ligado a um ego frágil que corrigia bugs em segredo sem primeiro falar dos próprios problemas no código. Ele escrevia um código obscuro que exemplificava a lei de Kernighan, e já tinha pelo menos 10 anos de carreira a mais para fazer esse tipo de coisa. Ele se gabava de que o código dele era “poderoso”, o que não é elogio, é presságio. Encontrei bugs várias vezes no código dos commits iniciais. A sensação é de: por favor, deixa qualquer coisa registrada
    Você não precisa confessar que tentou qualquer coisa até encontrar o problema. Depois de descobrir que é possível chegar ao ponto B, basta construir a narrativa desejada de A até B. Você pode reorganizar os commits da forma como os teria escrito se soubesse desde o começo exatamente o que precisava fazer. Pode descartar 90% do código que escreveu e apagou na hora, ou qualquer coisa que não sustente essa narrativa
    Na aplicação da lei existe algo chamado construção paralela. Você pode saber que um suspeito é culpado por fatos que não são admissíveis em tribunal, mas precisa redescobrir esses mesmos fatos seguindo o procedimento. Tipo obter o lixo no dia da coleta, entrevistar vizinhos, reunir evidência circunstancial suficiente para conseguir um mandado de busca e então encontrar de novo aquela prova
  • Parece que isso foi pensado principalmente com agentes de IA em mente. É uma ideia interessante que já vi antes, e é curioso como todo mundo quer reinventar alguma coisa para IA
    Mas sou cético, porque parece que bastaria criar um arquivo de texto e colocar referências de commit. Também não vejo por que não usar Fossil. Como é um banco de dados SQLite, já dá para embutir o que você quiser, e ele vem com todo tipo de recurso integrado para referenciar commits
  • Sou cético quanto à parte de colaboração, mas parece o tipo de recurso feito para clientes corporativos, então entendo a intenção
  • Concordo completamente. Essa sensação de vigilância é muito desagradável. Especialmente a parte que diz “DeltaDB divide o trabalho em um fluxo granular de deltas. Enquanto o Git captura snapshots de cada commit, o DeltaDB captura todo o trabalho entre eles e dá a cada um um identificador estável”
    Eu estava pensando em testar o Zed agora que ele ganhou keymap de emacs, mas agora não mais. Isso é invasivo demais, e eu realmente não quero que colegas revisem cada edição intermediária, no nível de tecla pressionada, até chegar ao commit que foi publicado para review
    Antes de abrir um PR, às vezes eu arrumo um pouco o histórico de commits no magit para deixá-lo mais linear e mais fácil de digerir. Tipo ajustar explicações ou juntar commits adjacentes. Mas esse recurso joga fora por completo um aspecto desse trabalho e basicamente diz: “colega, aqui está a mangueira de incêndio desse delta, engole aí e aproveita”
    O que exatamente significa a frase “O que realmente queremos é simples. Que a conversa com agentes se torne a única conversa de que você precisa”? Não, isso está errado

• Fico mal com a sensação de que é inevitável que a Anthropic ou a OpenAI compre o Zed. A ideia é boa demais e o software é bom demais

  • O harness de coding do Zed é muito melhor que o Claude Code, mas é muito mais caro porque usa a API do Claude diretamente. Se entrar para a mesma família de produtos, isso pode virar algo no nível de definir a categoria do produto
  • E por que parar no Zed? O US$ 1 trilhão em investimentos que as empresas de IA levantaram era, no papel, para datacenters, mas quando os custos sobem e os prazos de conclusão vão além do horizonte normal de planejamento de negócios, fica mais eficiente usar esse dinheiro em outra coisa. Com US$ 1 trilhão dá para comprar o que quiser
  • Para onde Anthropic ou OpenAI parecem estar indo, já não existe mais editor. Pessoalmente, eu queria ferramentas melhores de código somente leitura, ou então a volta da UML

• Tem muitas startups em estágio inicial competindo nesse espaço agora. Nas últimas semanas, fazendo entrevistas, conversei com pelo menos duas
  Para essas ferramentas encontrarem espaço a ponto de terem sucesso em larga escala, a competição vai ser muito intensa. Ainda assim, não consigo deixar de pensar que tudo isso parece permitir um nível de vigilância de desenvolvedores que me deixa muito desconfortável

  • Se um gerente passa o tempo todo observando todas as teclas digitadas por todos os desenvolvedores sob ele, então claramente não faltam tarefas reais nem problemas de negócio com que ele devesse se preocupar

• Commits são úteis porque foram organizados primeiro. A tentativa e erro entre eles é o lugar onde se tenta alguma coisa e se apagam becos sem saída, e a maior parte disso deveria ser descartada
  Salvar todas as mudanças e mensagens de agente só faz esse lixo continuar existindo

• O Google provavelmente já faz isso há uns 10 anos com o citc. Não sei quando exatamente o Gemini vai usar isso de verdade, mas o Google já tem, há pelo menos 10 anos, um registro praticamente completo de quase todos os desenvolvedores em unidades de Ctrl-S
  Se o Gemini parece meio burro agora, é só porque estão economizando na alocação de recursos computacionais
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• Aqui eu não entendo qual é a proposta de valor. Já vi várias empresas sugerirem mais ou menos esse tipo de funcionalidade, mas nenhuma apresentou um motivo convincente para essa tecnologia precisar existir.

  • É interessante como sua experiência e seu fluxo de trabalho são tão diferentes dos meus. Isso é uma funcionalidade que afirma resolver um problema real que eu enfrento todos os dias.
    Nossa empresa é totalmente remota, e a maioria dos meus colegas não mora perto de mim. Nós nos vemos por videochamada algumas vezes por dia, mas nos comunicamos principalmente pelo Slack.
    Estamos bem à frente na curva de adoção de agentes de LLM para escrever bom código. Graças a modelos bons e às proteções muito boas de um determinado harness de programação, hoje em dia os LLMs escrevem a maior parte do nosso código.
    Normalmente, meu dia começa pegando um ticket, apontando-o para o LLM e começando a resolver o problema junto com ele. Tomo decisões de arquitetura, faço um plano e executo. A funcionalidade mais recente que publiquei teve um custo de tokens de 19 dólares, e, no auge, o LLM ficou trabalhando por cerca de 30 minutos sem nenhuma entrada minha.
    Quando não tenho certeza de qual direção é melhor, às vezes posto uma pergunta no chat da equipe para pedir a opinião dos colegas. Mas muitos tickets são concluídos de forma totalmente autônoma.
    Depois eu abro um PR e posto o link do PR no Slack pedindo revisão, e é nesse momento que meus colegas veem a implementação pela primeira vez. Às vezes eles fazem perguntas. Como comentários no GitHub não funcionam bem para conversas rápidas em tempo real, muitas vezes eles colocam as perguntas em uma thread no Slack em vez de nos comentários do PR.
    As respostas para essas perguntas estão no log de conversa com o LLM no meu notebook, mas não há uma forma fácil de mostrá-las aos colegas. Então eu acabo fazendo essa brincadeira de telefone sem fio de copiar a pergunta do colega do Slack para o chat com o LLM e depois colar a resposta de volta.
    A ideia de meus colegas, o LLM e eu podermos participar com mais facilidade da mesma conversa é muito atraente.
    Isso não quer dizer que a equipe do Zed esteja indo na direção certa, e talvez nossa equipe trabalhasse melhor de outra forma. Mas a abordagem atual tem sido “bem-sucedida” demais, então não existe muita pressão organizacional para mudá-la.

• O trabalho de uma equipe de software é aprender colaborativamente modelos que funcionem de forma eficaz em algum domínio. Nós expressamos esses modelos e aprendizados em código, testes e documentação relacionada.
  Então, por um lado, eu concordo totalmente que pull requests e revisão de código prejudicam esse processo de forma fatal, mas também me incomoda a ideia de criar imediatamente mais outro procedimento secundário e mais entregáveis que nos distraiam. Tudo isso deveria aparecer na base de código.
  Não em alguma coisa separada. Nem em mensagens de commit ou em um conjunto de ADRs. Se a base de código não consegue explicar completamente, por si só, o quê e o porquê tanto para humanos quanto para IA, então ela fracassou, e passaremos o resto da vida criando mais procedimentos para administrar esse fracasso.

  • Branching barato para funcionalidades e experimentos, a capacidade de reverter rapidamente um commit específico e ler a mensagem do commit da última vez em que uma linha de código foi alterada são coisas extremamente importantes, e são viabilizadas pelos sistemas distribuídos de controle de versão.
    O estado atual do código, por si só, não é suficiente para o desenvolvimento moderno de software.