⏱️ Lectura: 11 min
Zed, la empresa que construye el editor de código escrito en Rust, abrió la lista de espera de DeltaDB: un sistema de control de versiones que no guarda el trabajo solo en el commit final, sino en cada paso intermedio.
📑 En este artículo
La propuesta es simple de explicar y difícil de construir: capturar cada operación que ocurre entre un commit y el siguiente, darle una identidad estable, y conectarla con la conversación de agente de IA que la produjo.
TL;DR
- Zed abrió el acceso anticipado a DeltaDB, un sistema de control de versiones nuevo.
- DeltaDB registra cada operación entre commits, no solo el commit final.
- Cada operación intermedia recibe una identidad estable y se puede recuperar después.
- Cada cambio queda enlazado a la conversación de agente de IA que lo generó.
- El worktree está virtualizado: crear una rama nueva es, según Zed, efectivamente gratis.
- Cualquier punto de la historia, incluso a mitad de una ejecución del agente, puede ser un punto de rama.
- Un compañero de equipo puede sumarse a la conversación mientras el trabajo todavía ocurre.
- El registro se hace con email y usuario de GitHub en zed.dev/deltadb.
Qué pasó
Zed Industries publicó una página de acceso anticipado para DeltaDB en zed.dev/deltadb. El formulario pide un correo y un usuario de GitHub, nada más: no hay descarga pública ni documentación técnica abierta todavía.
El eslogan que eligió el equipo resume la apuesta: “el software se hace entre commits”. La idea central es que git, al registrar solo instantáneas explícitas, descarta justamente la parte del trabajo donde ocurren las decisiones: los intentos fallidos, las vueltas atrás, el ida y vuelta con un agente de IA antes de llegar al resultado final.
DeltaDB propone capturar ese proceso completo. Según la propia descripción de Zed, el sistema graba cada operación intermedia con una identidad estable, para que cualquier momento de esa historia se pueda señalar y recuperar, no solo los puntos que alguien decidió congelar con un commit.
Contexto e historia
Zed nació como editor de código escrito en Rust, con foco en rendimiento y colaboración en tiempo real. Ese origen colaborativo reaparece en DeltaDB: no es un control de versiones pensado para guardar código a secas, sino para guardar el proceso de programar acompañado por un agente.
La motivación detrás de DeltaDB conecta con un problema que se volvió común a medida que los agentes de IA empezaron a escribir código de forma autónoma dentro de editores como el propio Zed: el historial de git muestra el resultado, pero no el razonamiento. Si un agente prueba tres enfoques distintos antes de converger en uno, git solo deja rastro del último si nadie commiteó los intermedios.
Ese vacío es el que Zed dice haber identificado: la conversación (el pedido, la corrección, el “no, así no, probá esto otro”) es tan parte del trabajo como el diff final, pero hoy vive en una terminal o un chat que se pierde apenas se cierra la sesión.
Detalles técnicos y rendimiento de DeltaDB
Zed describe cuatro capacidades concretas para DeltaDB en la página de acceso anticipado, sin publicar todavía especificación técnica ni benchmarks de rendimiento:
- Retroceder a cualquier edición. DeltaDB captura cada operación entre commits y le asigna una identidad estable, así que se puede señalar el código exactamente como estaba en cualquier momento de su evolución.
- Trazar código a conversación. Cada cambio queda enlazado a la conversación del agente que lo produjo. Desde cualquier línea se puede llegar a la conversación que la originó, y desde cualquier mensaje, al código que tocó.
- Ramificar en cualquier momento. Al virtualizar el worktree, crear una rama nueva de agente es, según Zed, efectivamente gratis. Cualquier punto de la historia, incluso a mitad de una ejecución, es un punto de rama válido.
- Compartir el hilo, no el pull request. Un compañero de equipo puede sumarse mientras el trabajo todavía está en curso, hablar con el agente que lo hizo y anotar sobre la marcha, sin esperar a que alguien commitee y pushee primero.
La diferencia con git es de granularidad y de qué se considera la unidad de historia. La siguiente tabla resume el contraste tal como lo plantea Zed:
| Aspecto | Git | DeltaDB |
|---|---|---|
| Unidad mínima de historia | El commit | Cada operación individual entre commits |
| Vínculo con la conversación de IA | Ninguno nativo | Cada cambio enlazado a la conversación que lo generó |
| Costo de una rama nueva | Copia o referencia sobre el working tree existente | Worktree virtualizado, según Zed “efectivamente gratis” |
| Colaborar en trabajo no terminado | Requiere commit y push previos | Un compañero se une a la conversación en curso |
Para entender por qué esto importa, conviene mirar qué guarda git hoy. Un git log típico solo muestra los puntos que alguien decidió congelar:
$ git log --oneline
a1b2c3d Arreglar bug de login
e4f5g6h Agregar tests de autenticacion
9f8e7d6 Refactor del modulo de sesion
Entre e4f5g6h y 9f8e7d6 pudo haber ocurrido cualquier cosa: un agente probando cuatro enfoques distintos para el refactor, dos de ellos descartados. Git no guarda ese proceso porque nunca hubo un commit para esos intentos.
Lo que Zed describe para DeltaDB sería algo conceptualmente parecido a esto (la CLI pública todavía no se publicó, así que esto es una ilustración del flujo, no un comando real):
// Flujo conceptual descrito por Zed (sin CLI publica todavia)
// 1. El agente edita el codigo dentro de una conversacion
// 2. DeltaDB asigna un ID estable a cada operacion intermedia
// 3. Cualquier operacion de esa historia puede convertirse
// en punto de partida de una rama nueva
El siguiente diagrama ilustra la idea de fondo: una serie de operaciones entre dos commits, todas enlazadas a la misma conversación de agente, con la posibilidad de abrir una rama en cualquier punto intermedio.
flowchart LR
A["Commit A"] --> B["Operacion 1: edicion"]
B --> C["Operacion 2: refactor"]
C --> D["Operacion 3: fix"]
D --> E["Commit B"]
B --> F["Conversacion del agente"]
C --> F
D --> F
C --> G["Nueva rama desde este punto"]💭 Clave: la apuesta de DeltaDB no es reemplazar el commit como concepto, sino dejar de tratarlo como la única unidad de historia que vale la pena guardar.
Cómo empezar a probarlo
DeltaDB todavía está en acceso anticipado: no hay paquete para instalar ni repositorio público. El único paso disponible hoy es anotarse en la lista de espera con un correo y un usuario de GitHub en zed.dev/deltadb.
Mientras se abre el acceso, sí se puede instalar y usar Zed, el editor sobre el que Zed Industries construye estas ideas. La instalación es la misma en macOS y Linux:
# macOS y Linux
curl -f https://zed.dev/install.sh | sh
En Windows, Zed distribuye un instalador descargable desde zed.dev, sin necesidad de compilar nada. El código fuente completo del editor, publicado en abierto, está en github.com/zed-industries/zed para quien quiera revisar cómo Zed integra agentes de IA hoy, antes de que llegue DeltaDB.
# Verificar la version instalada de Zed
zed --version
Ese comando confirma que el editor quedó instalado y qué build corre localmente: es el punto de partida razonable para quien quiera estar listo apenas DeltaDB empiece a habilitar cuentas de la lista de espera.
💡 Tip: completar el usuario de GitHub en el formulario de acceso anticipado no es opcional en la práctica; Zed lo pide explícitamente junto al correo, así que conviene tener a mano la cuenta que se quiere asociar.
Impacto y análisis
DeltaDB llega en un momento en que cada vez más código se escribe con un agente de IA operando dentro del editor, no al lado de él. Cuando quien programa es una persona sola, el commit alcanza como unidad de trabajo: la persona decide cuándo el código está listo para guardarse. Cuando el que edita es un agente que itera solo, esa decisión se vuelve menos clara, y perder el proceso intermedio significa perder el motivo real detrás de un cambio.
La función de compartir el hilo en vez del pull request apunta a un problema de revisión concreto: hoy, revisar el trabajo de un agente casi siempre implica esperar a que termine y abra una rama o un PR. DeltaDB propone que un compañero pueda entrar a mitad de la conversación, ver por qué el agente tomó una decisión y corregir el rumbo antes de que el trabajo esté “terminado”.
El riesgo, todavía sin resolver públicamente por Zed, es el volumen de datos: registrar cada operación intermedia de cada conversación de agente implica guardar muchísimo más que un historial de commits tradicional. Zed no publicó todavía cómo planea manejar el crecimiento de ese historial ni si habrá algún mecanismo de poda o resumen.
Tampoco está claro si DeltaDB reemplaza a git o convive con él dentro de un repositorio existente. La página de acceso anticipado no lo especifica, y hasta que Zed publique documentación técnica, esa pregunta queda abierta.
Qué sigue
Zed no publicó una fecha de disponibilidad general para DeltaDB ni un cronograma de invitaciones desde la lista de espera. El próximo paso visible es que la empresa empiece a habilitar cuentas registradas con correo y usuario de GitHub.
Cuando eso ocurra, las preguntas abiertas hoy (interoperabilidad con git, costo real de almacenamiento, si DeltaDB queda atado al editor Zed o funciona con cualquier herramienta) deberían empezar a resolverse con documentación técnica pública.
📖 Resumen en Telegram: Ver resumen
Si querés verlo apenas se abra, anotá tu email y tu usuario de GitHub en zed.dev/deltadb hoy mismo: es el único paso que depende de vos ahora.
Preguntas frecuentes
¿Qué es DeltaDB?
Es un sistema de control de versiones que Zed Industries presentó en acceso anticipado. A diferencia de git, registra cada operación entre commits y la enlaza a la conversación de agente de IA que la produjo.
¿Reemplaza a git?
Zed no lo aclara en su página de acceso anticipado. No hay información pública todavía sobre si DeltaDB sustituye a git dentro de un repositorio o convive con él.
¿Ya se puede instalar?
No. Solo existe una lista de espera en zed.dev/deltadb que pide correo y usuario de GitHub. No hay paquete, CLI ni documentación técnica pública.
¿Qué significa que el worktree esté “virtualizado”?
Según Zed, significa que crear una rama nueva de agente no implica copiar archivos del disco: por eso el equipo la describe como efectivamente gratis, y por eso cualquier punto de la historia, incluso a mitad de una ejecución, puede ser un punto de rama.
¿Cómo se relaciona esto con Zed, el editor?
Zed Industries es la misma empresa detrás del editor de código Zed, escrito en Rust. DeltaDB extiende esa apuesta por la colaboración en tiempo real hacia el control de versiones.
¿Hay que usar Zed para usar DeltaDB?
Zed no lo especifica en la página de acceso anticipado. Lo único confirmado hoy es el proceso de registro con correo y usuario de GitHub.
Referencias
- zed.dev/deltadb: página oficial de acceso anticipado de DeltaDB, con la descripción de sus cuatro capacidades principales.
- zed.dev: sitio oficial del editor Zed, la herramienta base de Zed Industries.
- github.com/zed-industries/zed: repositorio de código abierto del editor Zed.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Mohammad Rahmani en Unsplash
0 Comentarios