Cuatro agentes de IA construyen mi código. El más valioso es el que no sabe nada.

Cómo reparto el trabajo entre agentes de IA con roles cerrados, y por qué el último —el que llega sin contexto— es el que encuentra lo que a todos los demás se nos escapa.

Hace poco terminé un cambio en una plataforma de KPIs y nómina en ocho pasos. Cada paso lo verifiqué yo mismo, con mis propios ojos, antes de dar el siguiente. Al final, un agente al que no le conté nada de eso encontró dos problemas que se me habían pasado del todo.

Este artículo explica cómo trabajo con agentes de IA, quién hace qué, y por qué ese último agente vale más justamente porque no sabe nada.

La regla que lo cambia todo

La IA construye; yo dirijo. Yo no escribo el código: escribo las instrucciones, reparto el trabajo y verifico lo que vuelve. Suena a delegar, y lo es. Pero tiene una trampa que tardé en ver: dirigir no es revisar. Quien dirige la obra sabe demasiado sobre ella para mirarla con ojos limpios.

Para que la analogía sirva, piensa en una obra de construcción con cuatro personas: un inspector, un albañil, un jefe de obra y, al final, un perito externo. Cada uno tiene un rol cerrado y una lista de cosas que tiene prohibido hacer.

1 · El inspector escribe la prueba antes de que exista la pared

En software, una prueba es un pequeño programa que comprueba una sola cosa: «si entra esto, debe salir aquello». El inspector escribe una prueba, de un comportamiento, antes de que exista el código que la cumple. Por definición, esa prueba falla (está «en rojo»). Todavía no hay pared.

Su regla más importante es fácil de decir y difícil de cumplir: la respuesta correcta se escribe a mano a partir de la regla, nunca se copia de lo que el programa devuelve. Si el inspector corre el programa y anota como «correcto» lo que salió, la prueba aprobará cualquier cosa y no podrá contradecir a nadie jamás.

Un ejemplo real. La tarjeta de trabajo decía: «hay 15 avisos del navegador que hay que reemplazar». Ese 15 salía del contador del propio sistema. Al contar a mano, eran 17: el contador tenía dos agujeros y se dejaba dos fuera. Si hubiéramos confiado en el programa, el trabajo habría terminado «en verde» con dos avisos todavía vivos.

Tiene prohibido: escribir código de la solución, tocar cualquier otra prueba, e inventar reglas de negocio. Si el dato esperado no está en la tarjeta, para y pregunta.

2 · El albañil levanta esa pared, y solo esa

El albañil recibe la prueba en rojo y escribe el código mínimo que la pone en verde. Nada especulativo, nada «ya que estoy». Solo los archivos que se le autorizan.

Tiene prohibido tocar la prueba. Si cree que está mal, lo dice y lo justifica; no la reescribe en silencio ni la marca como «saltada». Tampoco arregla otras cosas de paso, ni añade nada que nadie pidió.

Lo que más me gustó de este rol lo vi cuando me equivoqué yo. En una instrucción le indiqué dónde dejar cierto detalle técnico, y estaba mal. El albañil no obedeció ni cambió la cosa en silencio: paró, explicó por qué mi instrucción era incorrecta y lo reportó. Corregí las instrucciones siguientes. Un agente que discute con razón vale más que uno que obedece.

3 · El jefe de obra no se fía del reporte

Ese soy yo. El jefe de obra no escribe código ni pruebas: reparte los encargos, y verifica cada entrega por su cuenta. No basta con que el inspector diga «la prueba falla»: la corro yo y leo por qué falla. No basta con que el albañil diga «ya pasa»: la corro yo.

Y hay una verificación que considero la más importante de todas: la prueba de la prueba. Cuando todo está en verde, quito solo el arreglo del albañil y confirmo que la prueba vuelve a fallar. Si sigue en verde sin el arreglo, la prueba no servía, y hay que rehacerla. En este caso, al quitar el arreglo la prueba volvió a rojo listando los 17 avisos, ni uno más ni uno menos.

El ciclo inspector → albañil → verificación se repitió ocho veces, de lo pequeño a lo grande. En el último paso, al correr todas las pruebas de la plataforma —no solo la nueva—, nueve pruebas antiguas se rompieron: buscaban los elementos por el atributo que justo estábamos eliminando. El albañil paró y lo reportó en vez de retocarlas para que pasaran. Esa es exactamente la conducta que se busca: una prueba rota es una pregunta, no un estorbo.

Al cerrar, conté los avisos del navegador en la plataforma corriendo: 186 antes, 0 después. Cuarenta y seis capturas de pantalla, en claro y oscuro. Todo verificado.

Y aun así, se me escaparon cosas.

4 · El perito externo: llega sin saber nada

El revisor es un agente en sesión limpia: no tiene acceso a la conversación donde se planificó y construyó todo. Recibe exactamente dos cosas: la tarjeta original (qué se pidió) y el resultado final (qué cambió). Es de solo lectura: no puede arreglar nada, solo reportar.

Sus instrucciones empiezan así:

Llegas sin el contexto de la construcción y miras el cambio
como si fuera de otra persona. Ese desconocimiento es el valor:
no des por bueno nada porque «se entiende».

Revisa siete ángulos, siempre los mismos:

1. ¿Hizo lo que pedía la tarjeta, y solo eso? Todo lo que sobra se señala.
2. ¿Se quedó donde le tocaba? Hay zonas del sistema prohibidas. Tocar una es bloqueante.
3. ¿La prueba sirve de verdad? ¿Fallaría sin este arreglo? Lo dice explícitamente.
4. ¿Inventó reglas de negocio? Umbrales, textos o criterios que la tarjeta no traía.
5. ¿Disfraza algún fallo? Errores que se tragan en silencio, valores que tapan un vacío real.
6. ¿La interfaz sigue las normas? Componentes, accesibilidad, teclado, contraste.
7. ¿Cada pantalla tocada responde a sus siete estados? Vacía, cargando, con error, sin permiso, con un elemento, con muchos, con texto larguísimo.

Reporta de más grave a menos, separando bloqueante de sugerencia. Y si en un ángulo no encuentra nada, lo dice: «no encontré nada aquí» es información; el silencio no.

Lo que encontró

Ocho hallazgos. Dos bloqueantes. Los dos, arreglados.

Ninguno de los hallazgos se resolvió tocando una prueba para que pasara. Ninguno se rechazó sin razón.

Por qué no puedo ser yo el revisor

Fíjate en el primer bloqueante. Yo verifiqué ocho pasos, corrí cada prueba dos veces, quité el arreglo para ver que volvía a fallar, hice 46 capturas. Y nunca abrí esa carpeta. No porque fuera descuidado, sino porque sabía dónde mirar, y por eso no miré donde no sabía.

Ese es el problema del contexto. Quien planificó y dirigió una obra revisa con un mapa en la cabeza: mira los sitios que el mapa marca. El perito no tiene mapa. Mira el resultado completo, con las mismas siete preguntas de siempre, y encuentra lo que el mapa no incluía.

El segundo bloqueante es la misma lección desde otro lado: el plan y el código se contradecían, y yo no lo vi porque yo sabía por qué. La decisión había cambiado a mitad, con razón, y en mi cabeza la contradicción no existía. Para alguien que solo lee el papel y el resultado, existía.

En el artículo anterior escribí: automatiza la propuesta, nunca la aprobación. Esto es la otra mitad: quien aprueba no puede ser quien construyó, ni siquiera cuando quien construyó es la IA y quien dirigió eres tú. Un revisor sin contexto no es un lujo. Es la única forma de que alguien mire con ojos limpios.

Herramientas: Claude Code con agentes definidos por archivo (uno por rol, con herramientas restringidas: el revisor solo puede leer). El método viene de una práctica de décadas —primero la prueba que falla— aplicado a agentes en vez de a personas.