Por qué una GUI de base de datos nunca debería escribir directamente

Toda GUI de base de datos tiene un momento en el que un clic se convierte en una escritura contra producción. Decidimos que ese momento no debería existir. En DynoTable, nada de lo que haces —ni la edición de un Item, ni un borrado masivo, ni el cambio de un agente de IA— toca DynamoDB directamente. Cada escritura aterriza en un área de preparación como un diff revisable por atributo, y solo se envía cuando un humano lo confirma.

El modelo mental hacia el que construimos es git: un área de preparación para revisar, y una confirmación que se comporta como git push --force-with-lease — solo tiene éxito si el remoto sigue teniendo el aspecto que viste por última vez. Esta entrada es la ingeniería que hay debajo: el bug entre pestañas que reformó todo el diseño, la refactorización cuyo principal resultado fue código eliminado, y por qué la llegada de los agentes de IA convirtió una comodidad de UX en el muro de seguridad de carga.

Las escrituras son diffs

Las ediciones se acumulan en una preparación local respaldada por SQLite y se muestran como tarjetas de diff —valor antiguo, valor nuevo, por atributo— en un panel lateral. Las filas se tiñen en la cuadrícula para que el estado preparado sea visible desde los datos, no solo desde el panel. Confirmar envía el conjunto preparado como transacciones de DynamoDB, troceadas según los límites del servicio (100 Items por transacción, con presupuestos de bytes por operación y por petición), secuencialmente, con un tiempo de espera de 30 segundos por trozo.

La documentación de preparación cubre el flujo de trabajo diario. Lo que no cubre es cuál es la clave de la preparación —lo que resultó ser la decisión más trascendental del sistema.

Indexada por la tabla, no por la pestaña

La primera versión limitaba cada preparación a la pestaña que la creó. Ese diseño produjo un bug real: la herramienta de preparación de la IA derivaba su objetivo de la pestaña activa, y su protección se saltaba las pestañas que no son vistas de tabla. Así que si le pedías al asistente que arreglara una fila mientras una pestaña del Workbench de SQL estaba enfocada, la edición se preparaba en la preparación del Workbench —y el chip de «revelar el cambio preparado» abría la pestaña equivocada.

Peor aún, el bloqueo de confirmación también era por pestaña. Dos pestañas que veían la misma tabla mantenían dos bloqueos independientes —lo que significa que ambas podían confirmar las mismas filas preparadas en el DynamoDB real de forma concurrente. Una condición de carrera de doble confirmación contra producción, incorporada en el modelo de datos.

La solución fue reindexar todo por identidad de tabla — {profile, region, tableName}— en lugar de por pestaña:

• Una preparación por tabla, visible desde cada vista de ella, que sobrevive al cierre y la reapertura de pestañas. La IA puede preparar sin ninguna pestaña de tabla abierta.
• Un bloqueo de confirmación por tabla. La condición de carrera de doble confirmación no está «gestionada»: es irrepresentable.
• La clase de bug de la pestaña equivocada desaparece por construcción: no hay pestaña en la clave.

Y reindexar eliminó más código del que añadió. ¿El barrido de arranque que recolectaba como basura las preparaciones de las pestañas cerradas? Un revisor lo señaló como destructor de funcionalidad bajo el nuevo modelo —las preparaciones ya no mueren con las pestañas— así que se eliminó de raíz. El descarte al cerrar la pestaña y su diálogo de confirmación: eliminados. El único huérfano verdadero que queda es un perfil de conexión eliminado, que se propaga en cascada de forma explícita.

La migración en sí fue la primera del repositorio que mutaba filas: una reconstrucción manual de la tabla SQLite que deduplicaba las filas heredadas por pestaña con una ventana ROW_NUMBER() OVER (PARTITION BY …) (gana la edición más reciente) y rellenaba la nueva clave con separadores char(0), idénticos byte a byte al constructor de claves del runtime. Las migraciones que mutan filas tuvieron su propio arnés de pruebas de sembrar-y-migrar ese día.

--force-with-lease, para DynamoDB

Una interfaz de revisión no vale nada si lo que revisaste no es lo que se escribe. Entre preparar y confirmar, alguien más puede haber cambiado la fila. Así que cada operación de confirmación lleva expresiones de condición que fijan la escritura a la instantánea exacta que revisaste — bloqueo optimista, atributo por atributo:

• Un create afirma que el Item no existe ya.
• Un update afirma que cada atributo que estás cambiando aún tiene el valor que viste cuando lo preparaste.
• Incluso una eliminación afirma que el atributo aún es igual a su valor antiguo —si un compañero de equipo cambió note de "old" a "new" mientras tu eliminación de note estaba preparada, la confirmación no debe borrar en silencio su edición.

Cuando una condición falla, DynamoDB cancela toda la transacción y nos dice qué Item se desvió. Esa fila obtiene un banner de conflicto —hacer rebase contra el valor en vivo o abortar— en lugar de una sobrescritura silenciosa en cualquier dirección.

Y ante el fallo de cualquier trozo, el confirmador se detiene. Los trozos confirmados permanecen confirmados, el trozo fallido se revierte de forma atómica, no se intenta nada más. Rechazamos deliberadamente la continuación de mejor esfuerzo: una herramienta de revisión que sigue escribiendo más allá de un conflicto está aplicando un conjunto de cambios que nadie revisó.

La refactorización que eliminó un subsistema

Las confirmaciones son de larga duración: la app registra cada una en un registro de reproducción para que una recarga del renderizador —o una segunda ventana— pueda volver a engancharse y verla terminar. Con el tiempo, tres rutas de código distintas enganchaban cada una dos observadores por confirmación, y todo un mecanismo de arbitraje creció alrededor de una pregunta: ¿a qué observador se le permite liberar el bloqueo de confirmación? Tenía su propio nombre aterrador (ownsLockOnBeforeRegistration), un bloque de comentarios que explicaba una condición de carrera de orden de IPC y un rastreador de toasts de 230 líneas.

La solución fue un único dueño: una Sesión de confirmación que se engancha exactamente una vez por confirmación, posee el bloqueo en exclusiva, proyecta el progreso en el store y garantiza que su llamada de inicio se resuelve en cada ruta de salida —nunca se cuelga, nunca rechaza. La maquinaria de arbitraje y el rastreador no se reubicaron; se eliminaron. El benchmark de memoria que machaca el panel de preparación redujo alrededor de un tercio de su heap. El mejor comentario de revisión de código que recibimos ese mes: «este PR es en su mayoría rojo».

Dos comportamientos se derivan de ese modelo de propiedad que consideramos imprescindibles para cualquier herramienta que escribe en producción: una confirmación en curso sobrevive a una recarga del renderizador (la sesión se vuelve a enganchar y se completa), e incluso sobrevive a que tu licencia pase a solo lectura a mitad de la confirmación —las nuevas confirmaciones se bloquean, pero una escritura ya en curso se observa hasta su final, nunca se abandona aplicada a medias.

Por qué el formato de cable es deliberadamente feo

Los valores preparados se almacenan como envoltorios tipados en crudo de DynamoDB —{N: "42"}, {S: "42"}— no como JSON amigable sin marshalling. Dos razones. El diff debe ser consciente del tipo: {N: "1"} y {S: "1"} son valores distintos, y un hash de clave primaria construido sobre valores sin marshalling los haría colisionar. Y el viaje de ida y vuelta debe ser sin pérdidas: los envoltorios de números sin marshalling del SDK no sobreviven a la serialización a JSON en SQLite y de vuelta, y la igualdad profunda contra la entrada del usuario se rompe. La ruta de confirmación usa el cliente en crudo por la misma razón: lo que revisaste es, byte a byte, lo que se condiciona y se escribe.

Entonces llegaron los agentes

La preparación es anterior a nuestras funciones de IA, pero es la razón por la que estas pudieron lanzarse siquiera. La herramienta de escritura del asistente prepara; su propia descripción le dice al modelo —al pie de la letra:

The user reviews + commits from the staging panel —
this tool never writes to DynamoDB directly.

No hay herramienta de confirmación. Ni protegida por permisos, ni auditada: ausente. El servidor MCP expone el mismo límite de forma estructural: su alcance de consentimiento intermedio se llama literalmente «lectura + preparación». Un agente con inyección de prompts en ese alcance puede proponer basura, y el radio de explosión es una tarjeta de diff que un humano lee. Y como las confirmaciones llevan bloqueos optimistas por atributo, ni siquiera una edición obsoleta de un agente puede pisar en silencio una edición humana concurrente — aflora como un conflicto, como todo lo demás.

Escribimos sobre cómo hacer fiables las consultas del agente; la preparación es la otra mitad: hacer que sus escrituras sean aburridas.

Qué exigir a cualquier herramienta que escribe en tu base de datos

• Un paso de revisión entre la intención y la escritura —diffs, no diálogos de confirmación.
• Concurrencia optimista sobre la instantánea revisada, incluyendo borrados y eliminaciones —nunca gana-el-último-que-escribe.
• Lotes atómicos con detención ante el fallo, no continuación de mejor esfuerzo más allá de un conflicto.
• Una ruta de escritura que sobrevive a un fallo o a una recarga sin dejar un conjunto aplicado a medias.
• Para la IA: la preparación como la única primitiva de escritura que tiene un agente —una capacidad ausente es mejor que una protegida.

La documentación de preparación muestra el flujo de trabajo, y editar datos de DynamoDB cubre lo básico que protege. O descarga DynoTable, prepara unas cuantas ediciones con ⌘S, y observa cómo un cambio masivo se convierte en algo que de verdad puedes leer antes de que ocurra.