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 especificación 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 plan 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.

Si el código contradice un requisito aprobado, corrijo el código. No reescribo el requisito para justificar lo que construyó la IA.

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 el código contradecía una decisión que ya habíamos documentado. Arreglarlo con un parche habría dejado parte de ese enfoque descartado en el código, donde otra persona o sesión de IA podría reutilizarlo sin saber por qué lo habíamos rechazado.

Tampoco fue un bug puntual. Lo que se implementó iba en contra de una decisión ya tomada, así que había que volver al requisito original, en vez de hacer un arreglo local. Una instrucción escrita puede volver a interpretarse mal en otro lugar; por eso hay que revisar el resultado.

Cuando el código de una IA contradice un requisito aprobado, prefiero empezar de nuevo a conservar un parche basado en un enfoque que ya descartamos.

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.

Los agentes empiezan apagados. Para los que aceptan reglas delegadas, un coordinador del hospital escribe esas reglas 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.

Por ejemplo, curl cerró su programa de recompensas por bugs después de recibir una avalancha de reportes de baja calidad generados con IA. GitHub también añadió controles para desactivar los pull requests o limitarlos a colaboradores, para que quienes mantienen los proyectos tengan más control sobre las contribuciones que reciben.

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. Si todavía no te ha pasado, igual vale la pena pensar cómo responderías. 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á. 🙂