Zed DeltaDB
O novo recurso DeltaDB do Zed pretende registrar toda alteração de código e vinculá-la a conversas de agentes de IA, criando efetivamente uma camada colaborativa de “histórico local” de granularidade fina que fica ao lado do Git. Os comentadores se dividem: alguns veem valor real para fluxos de trabalho com múltiplos desenvolvedores e assistência de agentes, reversão mais fácil entre commits e treinamento de futuros modelos, enquanto outros se preocupam com privacidade, microgestão e expansão de escopo às custas de corrigir a estabilidade básica do editor e problemas de UX. O debate também reflete uma inquietação mais ampla com prioridades dirigidas por VC e com a crescente interligação de ferramentas centrais de desenvolvimento com fluxos de trabalho centrados em IA.
O que o DeltaDB pretende fazer
- Posicionado como uma camada por cima do Git, e não como substituto do Git.
- Acompanha “deltas” de granularidade fina entre commits, vinculando cada alteração ao agente ou conversa que a produziu.
- Construído sobre o trabalho existente de CRDT/multiplayer do Zed; destinado a fluxos de trabalho colaborativos e agentic, incluindo ramificação no meio da execução e entrada em trabalho ao vivo.
Utilidade percebida
- Apoiadores comparam a “local history” do JetBrains/VS Code, mas mais rica e compartilhável: reversão fácil entre commits, recuperação de erros e navegação do código de volta para a conversa que o produziu.
- Alguns consideram isso útil para depurar sessões complexas de agentes ou colaboração multiusuário e multiagente.
- Outros veem como algo de nicho: em anos de trabalho, raramente precisaram desse nível de histórico e preferem commits frequentes no Git ou ferramentas como os snapshots do Jujutsu.
Fluxos de trabalho de IA/agentes vs “apenas um editor”
- Muitos gostam da integração baseada em ACP do Zed com agentes externos (Codex, Claude Code, OMP, OpenRouter) e veem o DeltaDB como uma extensão natural de fluxos de trabalho “agent-native”.
- Um grupo considerável quer que o Zed foque em ser um editor rápido e sólido (correções de bugs, estabilidade do LSP, SSH/WSL, polimento da UI), em vez de recursos complexos de IA/VCS.
- Alguns usuários abandonaram o Zed por instabilidade, problemas de desempenho ou falta de recursos “básicos” e acham que o DeltaDB está sendo priorizado de forma equivocada.
Preocupações com privacidade, vigilância e gestão
- Forte desconforto com registrar permanentemente toda conversa e toda mudança semelhante a teclas digitadas.
- Medo de que isso permita microgestão (“baixa qualidade de prompts” como métrica de desempenho) e retrospectivas de incidentes reproduzindo chats com agentes.
- Alguns temem que isso se torne, na prática, bossware ou dados de treinamento para modelos futuros; outros observam que riscos semelhantes já existem com ferramentas de IA corporativas e spyware.
Comparações com Git, JJ e outras ferramentas
- Vários comentários argumentam que Git somado a uma UX melhor, commits frequentes ou snapshots do Jujutsu já cobre a maior parte das necessidades.
- Alguns sugerem que o Zed poderia se apoiar em JJ ou integrar ferramentas existentes em vez de inventar nova infraestrutura.
- Auto-hospedagem é importante para alguns; há ceticismo em relação a um sistema semelhante a VCS que não possa ser auto-hospedado.
Preocupações de negócio e estratégia
- Muitos relacionam o DeltaDB e os recursos de IA à pressão de VC: um editor puro é difícil de monetizar; fluxos de trabalho de IA são vendáveis.
- Há receio de que manter tanto um IDE quanto um sistema de escala de VCS dilua o foco, especialmente dado o atual backlog de bugs e o suporte desigual às plataformas.