Zed DeltaDB
La nueva función DeltaDB de Zed pretende registrar cada cambio de código y vincularlo con conversaciones de agentes de IA, creando en la práctica una capa de “historial local” de grano fino y colaborativa que convive con Git. Los comentaristas están divididos: algunos ven un valor real para flujos de trabajo con varios desarrolladores y asistencia de agentes, un retroceso más fácil entre commits y un posible uso futuro para entrenamiento de modelos, mientras que otros se preocupan por la privacidad, la microgestión y la expansión del alcance a costa de arreglar problemas básicos de estabilidad y UX del editor. El hilo también refleja una inquietud más amplia por las prioridades impulsadas por VC y por la creciente interconexión entre las herramientas centrales de desarrollo y los flujos de trabajo centrados en IA.
Qué pretende hacer DeltaDB
- Se posiciona como una capa sobre Git, no como un reemplazo de Git.
- Rastrea “deltas” de grano fino entre commits, vinculando cada cambio con el agente o la conversación que lo produjo.
- Se construye sobre el trabajo CRDT/multijugador existente de Zed; está pensado para flujos de trabajo colaborativos y agénticos, incluyendo la posibilidad de crear ramas a mitad de ejecución y unirse a trabajo en vivo.
Utilidad percibida
- Quienes lo apoyan lo comparan con el “historial local” de JetBrains/VS Code, pero más rico y compartible: rollback fácil entre commits, recuperación de errores y navegación desde el código hasta la conversación que lo produjo.
- Algunos consideran que esto ayuda a depurar sesiones complejas de agentes o colaboración entre varias personas y varios agentes.
- Otros lo ven como algo de nicho: en años de trabajo rara vez han necesitado este nivel de historial y prefieren commits frecuentes de Git o herramientas como las instantáneas de Jujutsu.
Flujos de trabajo de IA/agentes frente a “solo un editor”
- A muchos les gusta la integración de Zed basada en ACP con agentes externos (Codex, Claude Code, OMP, OpenRouter) y ven DeltaDB como una extensión natural de flujos de trabajo “nativos de agentes”.
- Un grupo considerable quiere que Zed se centre en ser un editor rápido y sólido (corrección de errores, estabilidad de LSP, SSH/WSL, pulido de la interfaz) en lugar de funciones complejas de IA/VCS.
- Algunos usuarios han abandonado Zed por inestabilidad, problemas de rendimiento o funciones “básicas” que faltan, y sienten que DeltaDB tiene una prioridad equivocada.
Preocupaciones sobre privacidad, vigilancia y gestión
- Incomodidad fuerte ante el registro permanente de cada conversación y de cambios parecidos a pulsaciones de teclado.
- Temor a que permita una microgestión (“mala calidad de prompts” como métrica de rendimiento) y retrospectivas de incidentes reproduciendo chats de agentes.
- A algunos les preocupa que se convierta de facto en bossware o en datos de entrenamiento para futuros modelos; otros señalan que riesgos similares ya existen con herramientas empresariales de IA y spyware.
Comparaciones con Git, JJ y otras opciones
- Varios comentarios sostienen que Git, junto con una mejor UX, commits frecuentes o instantáneas de Jujutsu, ya cubre la mayoría de las necesidades.
- Algunos sugieren que Zed podría apoyarse en JJ o integrarse con herramientas existentes en lugar de inventar nueva infraestructura.
- El autoalojamiento es importante para algunos; existe escepticismo hacia un sistema tipo VCS que no pueda autoalojarse.
Preocupaciones de negocio y estrategia
- Muchos relacionan DeltaDB y las funciones de IA con la presión de VC: un editor puro es difícil de monetizar; los flujos de trabajo de IA sí se pueden vender.
- Preocupa que mantener tanto un IDE como un sistema a escala VCS diluya el enfoque, especialmente dado el actual backlog de errores y el soporte desigual entre plataformas.