Unidades de trabajo atómicas, reversibilidad y trazabilidad
¿Qué ocurre cuando le pides a un agente cuatro mejoras distintas a la vez y, tras modificar 30 archivos, tres mejoras funcionan pero la cuarta introduce un fallo grave que no logras aislar? Te quedas atrapado en un dilema costoso: o tiras a la basura todo el trabajo hecho (incluidas las tres mejoras que sí funcionaban) o pasas horas intentando desenredar línea por línea qué cambio rompió qué. La solución lógica para no perder jamás el control de un proyecto se llama atomicidad y reversibilidad del trabajo.
Objetivos y conocimientos previos
Partiendo de Especificar y delegar en el bucle HITL y del concepto de atomicidad visto en el Curso II, aprenderás a descomponer cualquier evolución de un sistema en unidades de cambio atómicas, a utilizar puntos de control reversibles y a conservar la trazabilidad de las decisiones arquitectónicas.
La ley de la atomicidad aplicada al trabajo de desarrollo
En el Curso II aprendimos que una transacción de base de datos es atómica cuando agrupa operaciones que forman una única intención lógica: o se completan todas dejando el sistema coherente, o se revierte el conjunto entero como si nada hubiera ocurrido.
El desarrollo de software asistido por IA funciona con la misma ley lógica:
Una unidad de trabajo es atómica cuando responde a un único propósito coherente, puede verificarse por sí misma sin dejar el sistema roto y puede revertirse limpiamente sin arrastrar cambios ajenos.
Compara estos dos modos de dirigir la evolución de un producto:
| Dimensión | Trabajo en bloque mezclado (No atómico) | Trabajo en unidades atómicas y reversibles |
|---|---|---|
| Encargo al agente | «Cambia el esquema de clientes, añade el cálculo de recargos, rediseña el menú de navegación y actualiza tres librerías». | Cuatro unidades separadas, ejecutadas y verificadas una a una en orden lógico. |
| Claridad al auditar | Muy baja: hay decenas de archivos mezclando estilos visuales con reglas financieras y cambios de versión. | Muy alta: en cada paso solo se tocan los archivos estrictamente necesarios para esa única responsabilidad. |
| Diagnóstico si algo falla | Difícil: no sabes si el fallo lo causó la nueva librería, el cambio en la tabla de clientes o la fórmula del recargo. | Inmediato: como el paso anterior estaba verificado en verde, el fallo solo puede provenir del pequeño cambio recién introducido. |
| Coste de volver atrás (Reversibilidad) | Deshacer el cálculo de recargos obliga a perder también el rediseño del menú o a editar archivos a mano con riesgo de romper más cosas. | Reviertes únicamente esa unidad de cambio y vuelves en un segundo al punto de control anterior que ya funcionaba. |
Cómo descomponer una funcionalidad compleja en pasos atómicos
Cuando quieras construir una capacidad nueva de extremo a extremo, divídela siguiendo las capas naturales del sistema (Cursos II, III y IV). Cada paso debe dejar el proyecto compilando y con sus pruebas pasando:
- Unidad 1 (Datos): Definir el esquema de entidades, tipos y restricciones de integridad + Verificar y consolidar Punto de Control 1
- Unidad 2 (Dominio): Implementar la regla de negocio, sus invariantes y su transacción + Verificar casos límite y consolidar Punto de Control 2
- Unidad 3 (Frontera y Contrato): Exponer la operación en el servidor con autenticación, autorización e idempotencia + Consolidar Punto de Control 3
- Unidad 4 (Presentación): Conectar la interfaz del cliente con el contrato del servidor + Verificar recorrido completo y consolidar Punto de Control 4
Observa la ventaja de esta secuencia: si al llegar a la Unidad 4 (Presentación) el agente comete un error al diseñar el formulario en pantalla, tus Unidades 1, 2 y 3 (Datos, Dominio y Seguridad en el servidor) ya están consolidadas y a salvo en el Punto de Control 3.
Reversibilidad: pensar siempre en el camino de vuelta
Dirigir con criterio no consiste en suponer que nunca nos equivocaremos, sino en asegurar que cualquier error sea barato y rápido de revertir.
Antes de autorizar un cambio, hazte siempre esta pregunta: «Si dentro de diez minutos descubrimos que este cambio no funciona como esperábamos, ¿cómo volvemos exactamente al estado anterior?»
- En cambios de código: mantener unidades atómicas registradas en el historial de versiones permite deshacer el último paso sin afectar al resto.
- En cambios de datos y esquemas (Curso II): borrar una columna o sobrescribir importes sin conservar historial no es fácilmente reversible. Por eso, las migraciones de datos deben hacerse primero añadiendo lo nuevo de forma compatible antes de retirar lo antiguo, y contando siempre con respaldo verificable.
Trazabilidad: conservar el «porqué» y no solo el «qué»
El código de un programa muestra qué hace el sistema hoy, pero rara vez explica por qué se descartó otra alternativa o qué límite conocido se acordó asumir.
Si no registras de forma breve y clara la intención de cada unidad de trabajo (por ejemplo, en el mensaje que describe cada punto de control y en el documento de arquitectura del proyecto), ocurrirá un problema clásico al trabajar con agentes en sesiones sucesivas:
- En la sesión del lunes acordaste que las facturas emitidas nunca se borran, sino que se anulan con un movimiento compensatorio.
- El jueves, en una nueva sesión, otro agente (o tú mismo) ve que no existe botón de borrar factura y, por desconocer la razón, añade un borrado destructivo que rompe la auditoría contable.
Un buen registro de trazabilidad responde en pocas líneas a tres cosas:
- Qué cambió y con qué intención (ej. «Añadir movimiento compensatorio para anulación de facturas»).
- Por qué se eligió ese diseño («Para conservar trazabilidad e inmutabilidad de las facturas ya emitidas»).
- Qué se verificó («Comprobado que anular una factura deja saldo 0 sin eliminar el registro original»).
Practica
Tienes que incorporar al sistema de control de gastos una nueva capacidad: «Permitir que los gastos puedan registrarse en distintas monedas (Euros y Dólares), convirtiéndolos a la moneda base del cliente según el tipo de cambio del día del gasto, y actualizar además el logotipo y los colores de la pantalla de inicio».
- Explica por qué pedir todo eso en una sola instrucción y guardarlo como un único cambio gigante viola la atomicidad y la reversibilidad.
- Divide el trabajo en al menos tres unidades atómicas independientes, indicando en qué orden las ejecutarías y qué verificarías antes de consolidar el punto de control de cada una.
- En la unidad correspondiente al modelo de datos del gasto y su tipo de cambio: ¿por qué guardar únicamente el importe convertido final y sobrescribirlo cada vez que cambie la cotización del dólar sería un error irreversible de modelo (Curso II), y qué debería escribirse en la nota de trazabilidad para que ningún agente futuro lo rompa?
Criterio de comprensión: debes separar por completo el cambio estético (logotipo y colores) de la funcionalidad multimoneda; secuenciar la funcionalidad en modelo de datos (guardando importe original, moneda original y tipo de cambio histórico aplicado ese día), lógica de cálculo/validación y presentación; y dejar documentado que el tipo de cambio de un gasto histórico nunca debe recalcularse con cotizaciones futuras.
Profundiza con IA
Aquí tienes mi descomposición en unidades atómicas y mi regla de trazabilidad para el registro de gastos en múltiples monedas: [tu respuesta]. Evalúa si cada unidad que propuse es realmente verificable y reversible por separado. Después, plantéame un escenario donde a mitad de la Unidad 3 descubrimos que necesitamos cambiar un detalle de la Unidad 1, y explícame cómo gestionarlo de forma ordenada sin mezclar cambios.
Siguiente lectura
Ya sabes cómo dividir el desarrollo en unidades atómicas y reversibles. Para cerrar el recorrido de LogicAdemy, ¿qué condiciones lógicas deben cumplirse cuando decidimos que esos cambios salgan de nuestro entorno de trabajo para compartirse con el equipo o publicarse ante usuarios reales? Continúa con Decisiones de ciclo de vida: aceptar, compartir y publicar.