Facilitando el desarrollo evolutivo de bases de datos: ramificación de bases de datos con Lakebase, la conclusión

La metodología descrita en Evolutionary Database Design y puesta en práctica en Refactoring Databases: Evolutionary Database Design ha estado clara durante veinte años. Las siete prácticas, el catálogo de más de 70 refactorizaciones registradas, la mecánica de transición: todo ello documentado, revisado por pares y enseñado.

Esa metodología llegó a CI/CD en 2010 con Continuous Delivery (Capítulo 12: Gestión de datos). Las migraciones se convirtieron en artefactos de primer nivel en el pipeline de despliegue. La disciplina de cambios de base de datos como código llegó al movimiento de CI/CD en general. Lo que CD no resolvió fue el aislamiento por pipeline: los pipelines podían ejecutar migraciones, pero aún necesitaban una base de datos de destino, y ese destino era compartido. La práctica n.º 4 (Cada uno tiene su propia instancia de base de datos) ha seguido siendo una aspiración para la mayoría de los equipos, porque las bases de datos reales con formato de producción por desarrollador cuestan tiempo, dinero y ciclos de DBA. La capa de compensación que surgió para salvar esa brecha (objetos simulados [mocks], entornos de staging compartidos, sustitutos de bases de datos en memoria, colas de tickets de DBA) se convirtió en una metodología fundamental por defecto, no por diseño.

En 2026, la ramificación de bases de datos copy-on-write llega a Databricks Lakebase. Una rama de un segundo y sin almacenamiento en su creación de una base de datos de producción a escala de terabytes es ahora una operación O(1). La limitación que hacía que la práctica n.º 4 fuera solo una aspiración ha desaparecido.

Esta serie describe qué cambia cuando desaparece esa limitación: no la metodología (que se mantiene), sino las prácticas que surgen por primera vez, la gobernanza a escala de equipo que se vuelve automática, la evolución del rol del DBA y el nuevo sustrato que los agentes comparten con sus homólogos humanos.

Conoce a Jen

Jen es el personaje desarrollador de Evolutionary Database Design. En ese ensayo, implementó una refactorización de base de datos (dividir un campo inventory_code en location_code, batch_number y serial_number) como una historia de usuario habitual, lo que ilustra que los DBA y los desarrolladores pueden colaborar, los esquemas pueden evolucionar en pequeños incrementos y las migraciones llevan a cabo el cambio de forma segura.

La serie retoma la historia de Jen veinte años después. La metodología que sigue es la misma que seguía en 2003. La novedad es el sustrato que subyace a su flujo de trabajo: la ramificación de bases de datos copy-on-write, que hace que las prácticas sobre las que ha estado leyendo sean operativamente reales a escala de producción. A lo largo de las tres partes de esta serie, ella es la misma Jen en tres ámbitos: su día a día (Parte 1), su nuevo manual de estrategias (Parte 2) y su equipo (Parte 3).

Parte 3: El equipo de Jen a escala

Parte 1 guio a Jen a través de una característica. Parte 2 nombró el manual de estrategias de once prácticas que sigue su trabajo en 2026. La Parte 3 lleva ese mismo manual de estrategias a un equipo de cincuenta desarrolladores, con agentes que crean ramas junto a los humanos, y plantea la pregunta: ¿qué se vuelve estructural a esta escala?

Tres cosas se vuelven fundamentales.

En primer lugar, la topología de niveles, las ramas de larga duración que representan cada entorno en la ruta de promoción. Con un solo desarrollador, tenías una rama de características y producción. Con cincuenta, tienes una jerarquía estructurada con carriles estables y carriles efímeros superpuestos.

En segundo lugar, el modelo de permisos, el marco que define quién puede hacer qué y en qué rama. Con un solo desarrollador, podías confiar en la convención. Con cincuenta, con agentes de por medio, el marco debe diseñarse una sola vez y aplicarse automáticamente.

En tercer lugar, el rol del DBA. Con un solo desarrollador, el DBA era el socio de diseño de Jen en la PR. Con cincuenta, el DBA es el ingeniero de plataforma que diseñó el marco dentro del cual operan Jen y sus compañeros de equipo.

Esta publicación aborda cada uno de esos puntos y luego se centra en los agentes. Los agentes con la misma capacidad es la Práctica n.º 11. Los agentes son como desarrolladores principiantes: producen código que se ejecuta, pruebas que se superan, migraciones que se aplican y, sin guía, sistemas imposibles de mantener. Las pruebas son la forma en que el equipo los mantiene bajo control. El manual de estrategias de TDD que viene a continuación es la forma en que el equipo logra que las pruebas sean lo primero.

Niveles como ramas de larga duración, no como instancias separadas

En el mundo anterior a las ramificaciones, un entorno era una instancia: un despliegue de Postgres dedicado para staging, otro para UAT, otro para pruebas de rendimiento, cada uno aprovisionado, parcheado, enmascarado y sincronizado por separado. La capa de compensación mencionada en la Parte 2 también existía aquí. La desviación entre entornos era estructural.

A escala de equipo, el modelo de niveles se reduce a ramas de larga duración que parten del mismo elemento principal de Lakebase.

Una rama es una de dos cosas: un nivel (de larga duración, un elemento principal en la jerarquía de promoción) o una característica (efímera, que desciende de un nivel y se elimina al finalizar). Un nivel tiene un elemento principal. La cadena de elementos principales es la jerarquía de promoción.

En la Fig. 1: vemos una jerarquía simple, donde la línea principal es la de producción y las ramas de características se crean cuando es necesario; esta configuración suele ser útil para prototipos iniciales o trabajos en etapas tempranas con un equipo muy pequeño. En equipos maduros con más desarrolladores o muchos entornos, se necesita una configuración como la que se muestra a continuación.

En algunas empresas, es necesario tener un candidato de lanzamiento (RC) que está en desarrollo durante algún tiempo y, tras probarse con éxito, se promociona a producción. La Fig. 3: muestra un diseño que permite desarrollar candidatos de lanzamiento para luego promocionarlos a producción, eliminando después la rama del candidato de lanzamiento,

Los nombres de las ramas son arbitrarios; lo que importa son las convenciones sobre cómo se establecen las relaciones de elementos principales. Se puede implementar una política que no permita transiciones que contradigan la jerarquía de la cadena principal para evitar una fusión directa de características.

Las definiciones de políticas aportan muchas ventajas para la gestión de pipelines:

• Una definición de pipeline que reconoce las ramas. El pr.yml introducido en la Parte 2 se ejecuta con cada PR; el merge.yml se ejecuta con cada promoción. El mismo flujo de trabajo abarca características, niveles y las transiciones entre ellos.
• La promoción es una fusión, no un nuevo despliegue. Pasar de staging a producción es un git merge cuyo efecto posterior es la promoción de una rama de Lakebase. La migración se aplica una vez en cada nivel, validándose primero en el nivel anterior, al igual que se valida el código en las etapas previas.
• Sin desviaciones entre "el entorno de pruebas" y producción. Cada nivel desciende del mismo elemento principal. La diferencia de esquema (schema diff) entre dos niveles cualesquiera es algo real y cuantificable: el esquema es una cadena de páginas con marcadores de divergencia, no dos instalaciones de software de base de datos. Esto permite a los equipos evitar la gestión de una flota de servidores de bases de datos que deben parchearse y actualizarse.

Rollback por redireccionamiento. Una promoción fallida se recupera apuntando la aplicación al snapshot del nivel previo a la promoción. El snapshot en sí es otra rama, lo que permite a los equipos recuperarse de despliegues defectuosos.

Atribución de costos por project_id, branch_id, endpoint_id. Unity Catalog captura los metadatos de forma automática. Una consulta SQL a las tablas de auditoría y facturación responde quién creó cada rama, cuándo se creó y cuánto cuesta mantenerla en funcionamiento.

La gran cantidad de instancias de bases de datos también disminuye drásticamente. Un mundo de seis instancias de entorno (prod, staging, UAT, QA, perf, demo) se reduce a un único elemento principal de Lakebase con una jerarquía vinculada de ramas de larga duración. La instancia utilizada para aprovisionar, monitorear y parchear es ahora una rama lógica con la misma estructura de datos que producción, gobernada por las mismas políticas que producción, que se restablece al estado de producción en un segundo cuando es necesario.

Diferentes convenciones le permiten crear muchos tipos distintos de ramas como principales; una convención común sería mantener una rama que contenga el esquema de la base de datos y cualquier dato de referencia para que cualquiera pueda crear una rama a partir de ella y completarla con datos de prueba o ejecutar pruebas automatizadas que generen datos reales, evitando así conflictos con staging u otras ramas.

Qué hacer ahora: el modelo de permisos

Práctica n.º 10 En la Parte 2 de la guía analizamos la gobernanza diseñada una vez y heredada por rama. Veamos cómo se implementa.

El trabajo de diseño no bloquea el tiempo de ejecución. Es un diseño estructural que luego las tareas comunes pueden aplicar.

Las decisiones que debe tomar ahora, antes de que el equipo crezca o se agreguen agentes:

• Creación de ramas a partir de cada nivel. Bifurcar desde producción requiere un permiso diferente en comparación con bifurcar desde staging o desde una característica. Por defecto, las características deben bifurcarse desde el nivel de entrada (inferior), nunca desde producción. Las bifurcaciones de producción están reservadas para flujos de hotfix y recuperación.
• Promoción entre niveles. Una promoción de “característica a staging” es un asunto de revisión de código. Una promoción de “staging a producción” es un asunto de coordinación de lanzamientos. Ambos son puntos de control independientes con revisores distintos, lo que otorga independencia a los equipos de negocio y de desarrollo.
• Lectura frente a escritura. El acceso de lectura a datos con estructura de producción en una rama no requiere el mismo permiso que el acceso de escritura a esa rama. Muchos roles de ingeniería necesitan acceso de lectura; pocos necesitan el de escritura.
• Políticas de Unity Catalog. Las políticas de Unity Catalog como el enmascaramiento, los filtros de filas y los permisos a nivel de columna se aplican en producción. Estas políticas se heredan en cada rama descendiente de forma predeterminada; las excepciones específicas de cada nivel (por ejemplo, un nivel de QA con PII sintetizada para pruebas de carga) se declaran una sola vez.
• Registro de auditoría. Cada creación de rama, cada promoción, cada aplicación de migración y cada patrón de acceso, en un único lugar consultable.

El principio que hace que esto funcione a escala de equipo: los roles declaran; la política aplica. El ingeniero de plataforma declara la jerarquía de niveles, el modelo de permisos, las rutas de promoción y la postura de la política de Unity Catalog. La política rechaza cualquier transición que contradiga lo declarado. No hay forma de que un humano o un agente anule un límite declarado reintentando la operación con una estructura diferente.

Este es el trabajo que debe hacerse hoy, antes de que el equipo sea de cincuenta desarrolladores y los agentes creen ramas más rápido de lo que cualquier humano podría revisar. El marco de trabajo es lo que mantiene unido al equipo con convenciones y medidas de protección compartidas. Todo lo demás funciona dentro de él.

El nuevo rol: de DBA a ingeniero de plataforma

Hace veinte años, el cierre del ensayo de 2003 Evolutionary Database Design reflejaba lo siguiente:

«Usar las técnicas que describimos aquí puede parecer mucho trabajo, pero en realidad no requiere una gran cantidad de personas. En muchos proyectos hemos tenido unos treinta desarrolladores y un tamaño de equipo (incluyendo QA, analistas y gestión) de cerca de cien personas. En un día cualquiera, tendríamos alrededor de cien copias de varios esquemas en las estaciones de trabajo de la gente. Sin embargo, toda esta actividad requería solo un DBA a tiempo completo y un par de desarrolladores que entendieran el funcionamiento del proceso y del flujo de trabajo».

Ese argumento se mantiene vigente para 2026 con cinco argumentos de refuerzo.

1. La proporción se mantiene, con más margen de maniobra por DBA. Un DBA a tiempo completo por cada ~100 personas, con las mismas más de cien ramas simultáneas en curso, conlleva un menor costo por rama porque la creación de ramas es ahora una operación de metadatos de un segundo. La proporción no es lo importante. Lo que importa es lo que el DBA hace con esas horas.

2. El trabajo se desplaza hacia arriba en la pila. Las horas que en 2003 se dedicaban al aprovisionamiento de infraestructura, aprovisionamiento de esquemas, control de acceso e intervenciones manuales ocasionales, ahora se destinan al diseño de políticas de ramificación, políticas de enmascaramiento, flujos de trabajo de promoción y observabilidad del registro de auditoría. Los artefactos concretos: bots de diferencias de esquema (schema-diff) que publican en cada PR, tareas programadas que restablecen las ramas de desarrollo por la noche, tableros de observabilidad que realizan el seguimiento del ciclo de vida de las ramas y el cumplimiento de TTL, y definiciones de CI que controlan las fusiones mediante la validación de esquemas. Este es un trabajo de diseño de plataformas; un trabajo de un nivel mucho más alto que antes.

3. Los agentes entran en juego. Algo con lo que el ensayo de 2003 no tuvo que lidiar fue con agentes que escriben código. Neon reporta alrededor de medio millón de ramas al día, con más del 80 % de ellas creadas por agentes. Un solo DBA no puede gestionar ese volumen mediante tickets. La evolución del rol hacia arquitecto de plataformas es el único enfoque que funciona a escala de agentes.

4. Las cifras se vuelven concretas. Un equipo de seis desarrolladores suele generar más de 30 tickets operativos por sprint en el modelo antiguo (aprovisionamiento, revisiones de esquemas, actualizaciones de datos, concesiones de acceso). En el modelo nativo de ramas: menos de 5 revisiones de políticas de alto valor por sprint. El trabajo rutinario del DBA disminuye de más de 20 horas por semana a menos de 5, y el MTTR se reduce de más de 4 horas a menos de 30 minutos. Esta reducción del trabajo rutinario puede ayudar al DBA a colaborar estrechamente con los desarrolladores para alcanzar soluciones óptimas para las características en desarrollo.

5. El registro de auditoría se convierte en un tablero estratégico. Lo que antes requería cruzar referencias de tres servicios y tres lenguajes de consulta es ahora una única consulta SQL contra las tablas del sistema de la plataforma. Cada rama, cada acción, cada costo y cada evento de gobernanza en un solo lugar. El DBA no está creando esta vista manualmente; es la plataforma la que lo hace.

En el prólogo de Refactoring Databases (2006), Martin Fowler esperaba que el libro representara «solo un primer paso» hacia herramientas que automatizaran la refactorización de bases de datos de la misma manera que los IDEs automatizan la refactorización de código. La ramificación es ese siguiente paso. Lo que Fowler esperaba en 2006, un cambio disciplinado en las bases de datos a la velocidad del código, es lo que la plataforma ofrece ahora. El DBA diseña la disciplina; la plataforma la aplica.

El título del nuevo rol varía (ingeniero de plataforma, propietario de la plataforma de base de datos, o todavía DBA de nombre). La esencia es la misma: la persona que diseña el marco de trabajo dentro del cual operan todos los demás.

Agentes con la misma capacidad

Práctica n.º 11 En la Parte 2 describimos al agente de programación como profesional con la misma capacidad de ramificación. Analicemos esto.

Los agentes obtienen acceso a las ramas, no a producción. Las mismas reglas de flujo de trabajo que se aplican a Jen se aplican al agente. Las pruebas se ejecutan contra una base de datos real en una rama, no contra mocks que un agente podría modificar o eliminar. Las diferencias de esquema se aplican en cada PR, independientemente de quién haya creado la migración. Las políticas que protegen a Jen protegen al agente.

Los agentes, si se dejan sin dirección, son como desarrolladores junior.

Un desarrollador júnior, al recibir un ticket de funcionalidad sin más orientación, puede producir código que compila, pruebas que pasan y un script de migración que se aplica limpiamente. Es posible que el código también duplique lógica que ya existía en otra parte de la base de código, lo que introduce duplicación. La migración podría agregar una columna con el nombre correcto pero con el tipo incorrecto. La prueba podría pasar porque solo evalúa el camino feliz. Ninguno de estos fallos aparece en la ejecución exitosa de CI; aparecen seis semanas después, cuando otra persona tiene que ampliar el trabajo.

Los agentes hacen lo mismo, pero mucho más rápido y a mayor volumen.

Sin una guía explícita, un agente hará lo siguiente:

• Reinventar un patrón que la base de código ya tiene.
• Crear un cambio de esquema que parece correcto pero omite la mecánica de transición de la refactorización designada (por ejemplo, eliminar una columna sin mover primero los datos, o agregar una columna NOT NULL sin actualizar las filas existentes).
• Escribir pruebas que pasan con la estructura de datos que imaginó, no con la estructura de datos que existe en producción.
• Crear migraciones que se aplican pero producen un estado inconsistente al revertirlas (rollback).
• Superponer capas de abstracción sobre otras abstracciones para realizar un cambio menor.

El sustrato hace que la barra verde sea honesta (sin mocks; una base de datos real en una rama). Lo que no hace es que el código sea mantenible.

El equipo hace que el código sea mantenible a través de cuatro refuerzos:

• Guardrails: el modelo de permisos. Los agentes no pueden crear ramas a partir de producción, no pueden promover entre niveles, ni pueden aplicar migraciones a un nivel que no les pertenece. El sustrato lo rechaza.
• Patrones: las refactorizaciones designadas. El catálogo de 2006 en databaserefactoring.com nombra más de 70 refactorizaciones con mecánicas de transición explícitas. Un agente guiado para "aplicar la refactorización de dividir columna" produce una migración diferente a la de un agente guiado para "dividir esta columna".
• Flujo de trabajo: la máquina de estados de gestión de control de código fuente (SCM). Los agentes siguen una secuencia de estados con filtros de control (gates) bloqueantes entre ellos. El sustrato rechaza las transiciones que no cumplen con el contrato declarado.
• Revisión: humanos en el ciclo de PR. Diferencias de esquema (schema-diff) visibles en cada PR, con el DBA en la ruta de revisión. La práctica n.º 1 reformulada de la Parte 2 hizo que esto fuera asíncrono; a escala de equipo, con agentes en el proceso, esa revisión asíncrona es lo que detecta los errores que las pruebas no detectaron.

El flujo de trabajo de SCM es el pilar fundamental. En el Lakebase App Dev Kit, la gestión de control de código fuente abarca más que la rama de código: cubre la ramificación emparejada (la rama de código y la rama de Lakebase gestionadas como una sola unidad, como se presentó en la Parte 1). Esta ramificación emparejada, proporcionada como una característica en el sustrato común del Lakebase App Dev Kit, aplica guardrails comunes como fusiones (merges) que contradicen la jerarquía, la migración que viaja con la rama, los filtros de CI y la fusión que aplica la migración al nivel primario. El kit de desarrollo incluye este flujo de trabajo de SCM como una máquina de estados ejecutable.

La Fig. 4 anterior describe los cinco estados durante el desarrollo: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Cada transición entre diferentes estados es impulsada por un comando de CLI (lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge). Cada comando de CLI valida las condiciones previas antes de trabajar, realiza la transición y escribe el nuevo estado en .lakebase/workflow-state.json (una superficie de control validada por esquema). Un filtro de control fallido deja la máquina en un estado recuperable anterior. Los filtros de control son bloqueantes, no informativos.

Los agentes llaman a estas CLI; no pueden inventar una ruta paralela. El sustrato se niega a avanzar en la máquina de estados ante un fallo de condición previa: se rechaza una rama de funcionalidad cuyo origen está en el nivel incorrecto; se deniega un intento de fusión antes de que la CI esté en verde; un archivo de estado inconsistente bloquea el siguiente filtro de control. Los contratos de entrega pertenecen al rol de scrum master; el sustrato los hace cumplir. Las decisiones estructurales (la jerarquía de niveles, el nivel de origen para una funcionalidad, la ruta de promoción) pertenecen al arquitecto o al scrum master, se registran y luego el sustrato las respeta. El sustrato nunca inventa un nivel o un elemento primario; respeta lo declarado y rechaza las transiciones que lo contradigan.

Este es el marco de trabajo que rompe con la forma en que los equipos han estado usando los agentes hasta ahora. La integración ingenua trata a un agente como a un ingeniero sénior en una ventana de chat: volcar el contexto, pedir un resultado, iterar. Eso funciona a escala de un solo desarrollador, pero falla a escala de equipo, porque el "contexto" del agente no se puede revisar, gobernar ni reproducir. En su lugar, trate al agente como a un desarrollador júnior: dele una tarea específica y documentada dentro de una máquina de estados ejecutable, valide su resultado frente a un esquema, avance el filtro de control y repita. El sustrato hace cumplir las reglas; el archivo de estado de flujo de trabajo es la API.

Entradas del manual de estrategias para las prácticas a escala de equipo

La Parte 2 presentó las prácticas n.º 10 y n.º 11 en las Prácticas emergentes para 2026

Práctica n.º 10: Gobernanza diseñada una sola vez, heredada por rama

Regla. El modelo de permisos y las políticas de Unity Catalog para gestionar el control de acceso y la captura del registro de auditoría se diseñan una sola vez en la rama principal (trunk) y son heredados automáticamente por cada rama descendiente.

¿Por qué es este un hábito duradero ahora? A escala de equipo, la gobernanza debe ser una función del DBA o del ingeniero de plataforma, no una disciplina que el desarrollador deba recordar. Las ramas se crean y destruyen en segundos; la configuración manual de la gobernanza por rama consumiría el ahorro de tiempo generado por la ramificación.

Mecánica:

• Declarar la jerarquía de niveles: qué ramas de larga duración existen, cuáles son sus enlaces primarios y qué postura de gobernanza tiene cada nivel.
• Declarar los límites de permisos: quién puede crear ramas a partir de cada nivel, quién puede promover entre niveles y quién tiene permisos de lectura frente a los de escritura.
• Declarar la herencia de políticas de Unity Catalog: enmascaramiento, filtros de filas y qué permisos a nivel de columna se heredan del elemento primario de forma predeterminada; las excepciones específicas de cada nivel se declaran una sola vez. La autopropagación en todos los tipos de políticas de Unity Catalog está terminando de implementarse; diseñe el marco de trabajo para el estado de destino.
• Declarar la captura del registro de auditoría: cada creación de rama, cada promoción, cada aplicación de migración y cada patrón de acceso se registran automáticamente en tablas del sistema consultables.
• El DBA o el ingeniero de plataforma lo hacen cumplir mediante políticas. Se rechaza cualquier transición que contradiga el modelo de gobernanza declarado.

Antipatrón. Configurar la gobernanza por rama en tiempo de ejecución. El objetivo de declararlo una sola vez es que el marco de trabajo se mantenga incluso cuando las ramas se crean más rápido de lo que un humano puede revisarlas. La configuración manual por rama vuelve a crear el cuello de botella que la ramificación acababa de eliminar.

Dónde se extiende el equipo de Jen. El ingeniero de plataforma o DBA de Jen declaró la jerarquía de niveles al crear el proyecto. Cada rama que crean Jen, sus compañeros de equipo o los agentes del equipo hereda la configuración declarada de enmascaramiento, permisos y auditoría. Cuando el equipo añade un nuevo nivel, el framework registra el nuevo enlace principal; las funciones en curso conservan su elemento principal original (sin reasociación retroactiva); las nuevas funciones se bifurcan a partir del nuevo nivel de entrada.

Práctica n.º 11: El agente como profesional con la misma capacidad de ramificación

Regla. Los agentes operan dentro de la máquina de estados ejecutable del flujo de trabajo de SCM: cinco estados, puertas de bloqueo entre ellos y archivos de estado validados por esquema. Las mismas reglas de flujo de trabajo rigen para Jen y para el agente; un sustrato común las hace cumplir independientemente de quién esté actuando.

¿Por qué es este un hábito duradero ahora? La creación de ramas es una operación de metadatos, por lo que el volumen impulsado por agentes es viable. El sustrato desarrollado para que lo aprovechen los agentes puede rechazar transiciones que contradigan la jerarquía de niveles declarada o el estado de puerta registrado. No hay un contexto de ventana de chat al que recurrir; solo el artefacto en el disco (workflow-state.json) cruza el límite entre las transiciones de puerta.

Mecánica:

• La máquina de estados de SCM tiene cinco estados: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Cada transición es impulsada por una CLI; cada CLI valida las condiciones previas antes de realizar el trabajo.
• La superficie de la puerta es .lakebase/workflow-state.json, validada frente a scm-workflow-state.schema.json. Cada transición escribe el nuevo estado y las invariantes que necesita la siguiente puerta.
• Las decisiones estructurales (jerarquía de niveles, nivel de origen por función, ruta de promoción, contratos de entrega) pertenecen a los roles (arquitecto o scrum-master), se registran y luego el sustrato las hace cumplir.
• Los agentes llaman a las CLI. El sustrato se encarga de hacer cumplir las reglas; los agentes no pueden evadirlas. Una puerta fallida deja la máquina de estados recuperable en el estado anterior; el agente no "vuelve a intentarlo de otra forma".
• Las puertas de CI que se ejecutan dentro de pr-ready a ci-green prueban un Postgres real en una rama, con la diferencia de esquema publicada en la PR. El estado real de la base de datos es aquello con lo que se mide el trabajo del agente.

Antipatrón. Tratar a un agente como a un ingeniero sénior en una ventana de chat usando "volcar contexto y pedir resultados" funciona a escala de un solo desarrollador, pero falla a escala de equipo porque el "contexto" no se puede revisar, gobernar ni reproducir. En su lugar, utilice el modelo de artefacto como API: los agentes LEEN workflow-state.json y las entradas documentadas para su fase; ESCRIBEN las salidas documentadas; los validadores comprueban; la siguiente puerta se activa solo cuando se cumple el contrato.

Dónde se extiende el equipo de Jen. Cada agente del equipo de Jen opera dentro de la misma máquina de cinco estados en la que operan Jen y sus compañeros de equipo. El rol de scrum-master es el propietario de los contratos de entrega; el sustrato rechaza las transiciones que no los cumplan. Un agente no puede entregar una función que se haya bifurcado desde el nivel incorrecto; un agente no puede fusionar antes de que la CI esté en verde; un agente no puede omitir el artefacto de diferencia de esquema. El framework se mantiene independientemente de quién o qué haya iniciado la acción.

TDD como una capa opcional integrada en la parte superior

La práctica n.º 11 establece el flujo de trabajo de SCM como base: todos los usuarios del kit lo siguen, tanto agentes como humanos. TDD es una consideración aparte que se superpone a esa base para los equipos que desean una disciplina de desarrollo guiado por pruebas. Es opcional; las puertas de SCM son obligatorias independientemente del camino.

Por qué son importantes las pruebas, incluso antes de TDD: cuando los agentes crean código, las pruebas son la única forma de control que escala. Kent Beck, en su entrevista de 2026 Pragmatic Engineer, mencionó públicamente este modo de fallo: tiene problemas para evitar que los agentes de IA eliminen pruebas para lograr que se aprueben. La barra verde es fácil de conseguir cuando nada en el bucle obliga al agente a enfrentarse a la forma real del sistema. Los mocks hacen que esto sea trivial. Los sustitutos en memoria también.

La creación de ramas hace que la barra verde sea honesta en la capa de datos. El agente realiza las pruebas contra una base de datos real en una rama real; las restricciones de esquema rechazan las inserciones de filas que no coinciden, las claves foráneas rechazan los huérfanos, la forma real de los datos expone suposiciones que el mock habría absorbido silenciosamente, el agente no puede eliminar tablas. El coste de fingir el cumplimiento aumenta con estas medidas de protección.

Pero el sustrato es necesario, pero no suficiente. Las pruebas tienen que venir de alguna parte. Si el agente las escribe, el agente también puede eliminarlas. Este es el vacío que llena TDD.

El flujo de trabajo de TDD se superpone al flujo de trabajo de SCM. Se activa entre los estados de SCM feature-claimed y pr-ready; realiza llamadas descendentes a SCM para operaciones de rama (las ramas de experimentos de ciclo utilizan la primitiva de SCM subyacente); no realiza llamadas ascendentes a SCM. La dependencia es unidireccional. Los equipos que no deseen la capa de TDD pueden entregar funciones mediante la edición directa en la rama de funciones y aun así cumplir con todas las puertas de SCM.

El Lakebase App Dev Kit incluye el flujo de trabajo de TDD como una segunda máquina de estados con sus propios agentes por rol y validadores de puertas:

• Spec-author convierte la narrativa del solicitante en un artefacto de función estructurado, validado por esquema.
• Architect-reviewer asigna los requisitos no funcionales y los principios de arquitectura de la función a decisiones arquitectónicas, con un resultado en forma de architecture.json más prosa.
• Test-strategist produce la lista de pruebas y los escenarios por criterio de aceptación, con un resultado en forma de test-list.json más markdown renderizado. Cada NFR tiene al menos un criterio de aceptación (AC); cada AC tiene un escenario.
• Scrum-master orquesta los ciclos de compilación. Cada ciclo bifurca una rama de experimento (utilizando el sustrato de SCM subyacente), ejecuta un agente conductor (driver) para implementar el siguiente AC y ejecuta un agente navegador (navigator) para revisar y validar el resultado.
• Driver y navigator son el redactor de pruebas y el redactor de código del bucle interno, emparejados, ROJO-VERDE-REFACTORIZACIÓN.

Cada rol tiene entradas y salidas documentadas, validadas frente a un esquema. Cada agente obtiene solo sus entradas documentadas; las salidas se validan antes de que se ejecute el siguiente rol. El artefacto es la API entre roles; el esquema es la comprobación de tipos. Un artefacto faltante se trata como una puerta fallida. Un artefacto malformado se trata como uno faltante. La capa de TDD toma prestado el mismo modelo de artefacto como API que la Práctica n.º 11 estableció para SCM.

La capa de TDD se encuentra en la capa de TDD en la Guía complementaria: Lakebase App Dev Kit (de código abierto, con un libro electrónico complementario para profesionales humanos). Las máquinas de estados de SCM y TDD, los contratos de agentes por rol, las comprobaciones de conformidad de artefactos y los validadores de puertas se incluyen como CLI que cualquier orquestador (el kit, la extensión del IDE, un trabajo de CI, una sesión de shell humana) puede llamar.

La versión corta: SCM es la base (Práctica n.º 11). TDD es una capa superior. La creación de ramas hace que las pruebas sean honestas; TDD hace que las pruebas sean lo primero; el kit hace que ambos flujos de trabajo sean ejecutables.

Lo que muestra el equipo de Jen

La Parte 1 guio a Jen a través de una función: emparejó una rama de código con una rama de Lakebase, ejecutó una migración real contra datos con formato de producción en segundos, realizó pruebas sin mocks, abrió una PR con la diferencia de esquema publicada en línea para su revisión y realizó la fusión con la migración aplicada y las ramas efímeras limpiadas. El cambio de base de datos se convirtió en parte del desarrollo normal.

La parte 2 definió el manual de estrategia: las siete prácticas de 2003, las limitaciones que mantuvieron a cinco de ellas como aspiracionales hasta 2026, las mismas siete reformuladas una vez que llegó la ramificación, además de dos nuevas prácticas que la tecnología habilita para el desarrollador individual. Nueve prácticas en el día a día, dos más que surgen a escala de equipo.

La parte 3 llevó el manual de estrategia al equipo. Definió la topología de niveles, describiendo cómo las ramas de larga duración residen dentro de un elemento primario de Lakebase, cómo el modelo de permisos se convierte en el artefacto de diseño del ingeniero de plataforma, declarado una vez y aplicado por el sustrato (Práctica n.º 10). Cómo el rol del DBA completa su evolución a arquitecto de plataforma, con cinco refuerzos del argumento de dotación de personal de 2003. Los agentes ingresan al flujo de trabajo con la misma capacidad, dentro de la máquina de estados ejecutable del flujo de trabajo de SCM, con el sustrato aplicando las puertas de enlace independientemente de quién o qué esté actuando (Práctica n.º 11). TDD es una capa opcional integrada en la parte superior: disciplina de desarrollo guiado por pruebas con roles dedicados, puertas de enlace y contratos de artefactos, para los equipos que lo deseen.

La Guía complementaria: tutorial del complemento cubre la extensión de SCM para Lakebase para VS Code y Cursor de extremo a extremo.

La Guía complementaria: Kit de desarrollo de aplicaciones de Lakebase, junto con un libro electrónico complementario para profesionales humanos, cubre el flujo de trabajo de TDD anterior: las máquinas de estado de SCM y TDD, los agentes por rol, los validadores de puertas de enlace y los contratos de artefactos que hacen que sea seguro incorporar agentes al equipo.

La metodología estuvo clara durante veinte años. La capacidad técnica llegó en 2026. El manual de estrategia tanto para profesionales humanos como para agentes ya está operativo. El equipo de Jen cuenta con cincuenta desarrolladores y una flota de agentes; el flujo de trabajo es el mismo.

Conclusión: La capacidad de ramificar una base de datos ahora brinda una inmensa flexibilidad al equipo de desarrollo para aprovisionar bases de datos, compilar pruebas con esquemas reales, ejecutar CI para cada creación de PR en su propia base de datos y permitir que los agentes trabajen de esta manera, todo con el marco de gobernanza de Unity Catalog aplicando las políticas.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original