La regla que uso para decidir cuándo descartar el código de una IA

¿Alguna vez le explicaste algo a alguien con calma, por escrito, y aun así terminó haciendo justo todo lo contrario de lo que habían acordado? Ese momento incómodo de "pero si esto ya lo hablamos" te deja dudando entre reírte o frustrarte. A mí me pasa seguido dirigiendo IA para programar.

Trabajo en Work Connect, un producto que ayuda a hospitales a cubrir rápido los turnos de enfermería que quedan vacíos cuando alguien avisa que no puede venir. Ahí un error no es solo una molestia. Si un turno se queda sin cubrir, alguien tiene que resolverlo rápido, y las alternativas normales (llamar a todo el mundo, pagarle de más a una agencia externa) son lentas y caras. Por eso ahí no hay margen para "ya lo arreglamos después".

Y fue justo en ese contexto donde, trabajando en una funcionalidad nueva, la IA que dirijo terminó construyendo exactamente todo lo contrario de lo que habíamos decidido hacer.

Una spec que manda sobre el código

En Work Connect, antes de que la IA escriba una sola línea, ya existen los documentos: una especificación del producto, un documento de requisitos por funcionalidad con sus criterios de aceptación, un blueprint técnico y las órdenes de trabajo que lo dividen en piezas. Recién ahí la IA convierte todo eso en código, y yo reviso 3 cosas: los documentos que definen qué hay que construir, la funcionalidad que realmente quedó implementada, y los tests que la respaldan.

Cuando lo implementado y el plan no coinciden, lo que se corrige es lo implementado. Nunca el plan.

El momento en que dije "esto no sirve"

Pasó con una funcionalidad cualquiera, una de esas que ya tenía su plan completamente definido antes de empezar. La IA leyó ese plan, escribió el código, y terminó construyendo justo lo contrario de lo que ese plan pedía.

El resultado fue un enfoque duplicado, uno que ya habíamos evaluado antes y descartado por escrito. El plan no solo decía qué hacer. En el fondo también decía "esto ya lo pensamos, y no es el camino".

Cuando vi que la IA lo había hecho de todas formas, no lo dudé mucho: cerré esa rama de trabajo y volví al plan original.

¿Por qué no simplemente corregir lo que la IA ya había hecho?

Porque lo que la IA construyó no era un detalle a ajustar: contradecía directamente una decisión que ya habíamos tomado por escrito. Arreglarlo en el momento hubiera dejado esa decisión equivocada viviendo a medias en el código, como un mal ejemplo que la próxima persona (o la misma IA) iba a copiar sin saber que ya la habíamos descartado.

Tampoco fue un bug puntual. Lo que se implementó iba en contra de una decisión ya tomada, y eso significa que la instrucción que la IA siguió estaba mal desde la raíz, no solo en el detalle. Una instrucción mal entendida en un lugar puede repetirse en otros.

Preferí perder ese trabajo, y quedarme con un plan limpio, antes que quedarme con un arreglo a medias sobre una base que ya sabía que estaba mal.

El mismo principio, ahora dentro de un equipo de 6 agentes

Ese episodio fue sobre una sola funcionalidad, que yo revisé antes de que llegara a producción.

Pero en Work Connect también hay una parte que no pasa por ese tipo de revisión humana caso por caso: un equipo de 6 agentes de IA que automatiza, todos los días, buena parte del proceso de cubrir un turno. Ahí ese mismo criterio (nunca dar algo por bueno sin verificarlo) no podía depender de que yo revisara cada acción a mano. Tenía que convertirse en una regla que el propio sistema cumpliera solo.

Cada uno de esos 6 agentes hace una parte del trabajo que antes hacía una persona a mano: se dan cuenta cuando una enfermera avisa que no puede venir, buscan un reemplazo, revisan a los candidatos que se postulan, y hasta hacen la llamada para confirmar que a alguien no le falte una credencial antes de que empiece su turno.

Pero ninguno actúa por su cuenta así porque sí. Todos empiezan apagados, y solo se activan sobre una regla que un coordinador del hospital escribió explícitamente, en lenguaje simple.

Antes de que esa regla se aplique de verdad, el panel le muestra a esa persona qué fue lo que el agente entendió, para que la confirme. Y si algo no queda claro, el agente no improvisa: el turno pasa a la cola manual, para que lo resuelva una persona.

Este mismo dilema, cuánto confiarle a la IA sin que alguien lo revise todo a mano, se está discutiendo en público este año, y no soy el único con la duda. La razón de fondo es simple: una IA puede producir trabajo mucho más rápido de lo que una persona puede revisarlo con cuidado.

Hay proyectos de código abierto que cerraron sus programas de recompensas por bugs porque les llegaban más reportes generados con IA de los que su equipo humano podía verificar, y GitHub está evaluando frenos de emergencia para pull requests que, en la práctica, nadie termina revisando de verdad.

No es que la IA sea mala. Es que si nadie le pone un límite, la velocidad gana y la revisión pierde.

Si diriges IA en algo donde un error de verdad importa, ya sabes de qué hablo. Y si todavía no te ha pasado, te va a pasar. La pregunta no es si la IA se va a salir del plan alguna vez. Es qué vas a hacer tú cuando pase. Gracias por leer hasta acá. 🙂