Lo que un agente de IA no puede decidir

Un cliente tenía una reserva de más de setenta mil abierta contra una orden que el sistema daba por completada. Había que cerrarla. La pregunta era cómo.

Si el pago al proveedor salió, la corrección es liquidar: el dinero baja del bloqueado y también del saldo, porque ya no está. Si el pago nunca salió, la corrección es la contraria: liberar, devolverlo a disponible.

Las dos correcciones son opuestas. Y desde la base de datos son indistinguibles.

Elegir mal en una dirección significa pagarle dos veces al beneficiario. Elegir mal en la otra significa quitarle setenta mil a un cliente que sí los tenía. No hay una tercera opción que sea "más o menos correcta".

Trabajo con agentes de IA todos los días sobre este sistema. Orquesto varios en paralelo, con memoria de dominio persistente y con integración automatizada de cambios. Sostengo mucha más superficie de la que sostendría solo. Y aun así, esa decisión no la tomó ninguno.

El modo de fallo no es el que te imaginas

Cuando alguien desconfía de programar con agentes, casi siempre imagina código malo: funciones rotas, sintaxis inventada, cosas que no compilan.

Ese problema prácticamente no existe. Los tests lo atrapan, el compilador lo atrapa, tú lo atrapas leyendo.

El modo de fallo real es otro: código plausible, entregado con confianza. Una corrección que se ve bien, pasa las pruebas, y está contablemente equivocada. Un agente no tiene forma de saber que la tabla operacional dice "cómo se ven las cosas hoy" y no "qué pasó". Va a leer el estado, va a razonar impecablemente sobre lo que lee, y va a proponer algo coherente con una premisa falsa.

En un CRUD eso cuesta un rato de depuración. En un camino de dinero cuesta dinero de otra gente.

Tres límites que sí funcionan

Memoria de dominio, no memoria de código. Lo que un agente necesita recordar no es dónde está la función. Es que esa columna se dejó en nulo a propósito, que ese "bug" era una feature flag apagada, que ese monto es el neto y no el bruto. Tengo más de ciento cincuenta hechos así, versionados. Sin eso, cada sesión repite el error de la anterior con total seguridad en sí misma.

Alcance acotado por escrito. "Migra esto" es una invitación a que el agente toque siete cosas más que le parecieron mejorables. Los límites explícitos —esta arquitectura, este módulo, no mezcles con el legado— no son burocracia: son lo que evita que una tarea de una hora se convierta en un diff que nadie puede revisar.

La compuerta humana donde el efecto no se deshace. Un agente puede encontrar, medir, proponer y hasta ejecutar casi todo. Lo que no hace es mover dinero de clientes, ni encender un proceso automático sobre datos que nadie midió. No porque no sea capaz de escribir ese código. Porque la consecuencia de equivocarse no es un error en un log: es un saldo mal movido en la cuenta de una persona real.

El error que cometí escribiendo sobre esto

Hace unos días publiqué un caso de estudio sobre aquel wallet congelado. El cierre decía que el saldo se había liberado y la causa raíz corregido.

La causa raíz sí se corrigió. El saldo no se liberó: se derivó a reconciliación con el proveedor y a compliance, precisamente porque liberarlo a ciegas era el error que este artículo describe. El texto publicado afirmaba un resultado que no ocurrió, y sonaba bien.

Lo detecté cotejando contra el estado real de los tickets. No contra mi recuerdo, ni contra lo que parecía razonable.

Ese es exactamente el modo de fallo del que vengo hablando, aplicado a mí mismo. Plausible, coherente, presentable, y falso. La verificación no es un paso ceremonial que se hace cuando sobra tiempo: es lo único que separa lo que crees que pasó de lo que pasó.

Lo que mido ahora

Dejé de medir cuánto código sale por hora. Empecé a medir otra cosa: cuántas de las decisiones que tomó el sistema esta semana eran reversibles.

Un agente que escribe el triple de código y toma una decisión irreversible equivocada te dejó peor que antes de empezar. Uno que escribe la mitad pero nunca cruza esa línea te deja construyendo durante años.

La velocidad no vale nada si rompe la contabilidad. Y la contabilidad no avisa cuando se rompe: eso lo descubres semanas después, cuando un cliente pregunta por su dinero.

(Por esto mismo estoy construyendo LedgerCore: si cada retención y cada liberación son asientos de primera clase, la pregunta "¿esto ya salió o no?" tiene respuesta en los libros. Y una decisión con respuesta deja de necesitar adivinación, humana o artificial.)