Le puse un supervisor a mi IA. Construyó una burocracia.

Desde hace unos tres meses tengo dos IAs trabajando una contra otra, a propósito.

Primero el montaje, porque sin él nada de lo que viene tiene sentido. Soy una sola persona con alrededor de una docena de productos de software. Casi todo el código lo escribe Claude Code, una sesión por proyecto, cada proyecto una carpeta en un Mac Studio. Hace tres meses añadí una segunda IA: un proyecto en la aplicación de escritorio de Claude cuyo único trabajo era mirar por encima del hombro a la primera. Podía leerlo todo y no podía cambiar nada. La llamé el supervisor. Ahí estaba el error entero, pero me estoy adelantando.

Funcionó, y quiero decirlo con justicia, porque el resto de este artículo sonará a lo contrario. Un supervisor pilla lo que quien construye no puede pillar por estructura: la pregunta tonta desde fuera. Eso que acabas de describir, ¿está de verdad en la máquina, o solo existe en tu descripción de ello? Esa pregunta me ha ahorrado alguna noche mala.

Y entonces, a lo largo de unas semanas, las dos empezaron a encontrarse muy a gusto en compañía la una de la otra.

La escaramuza que nadie declaró

Nunca hubo pelea. Si hubiera habido pelea, me habría dado cuenta en una semana. Lo que pasó fue peor y mucho más difícil de ver: estaban de acuerdo. Estaban de acuerdo con entusiasmo, con detalle, con matices cada vez más finos, sobre cosas cada vez más pequeñas.

Una entregaba un trabajo. La otra planteaba una objeción. La objeción solía ser correcta, y eso era justo lo que hacía tan difícil parar. La primera respondía, con cuidado, y al responder se fijaba en una segunda cosa, más pequeña, que merecía su propia respuesta cuidadosa. Hacia la tercera ronda, las dos estaban examinando el método con el que se había hecho la revisión. No el trabajo. La revisión.

Nadie discutía. Las dos eran minuciosas, en la misma dirección, con argumentos de verdad, y el proyecto estaba parado.

Solo lo detecté porque acabé preguntando de frente, y lo pregunté de la forma menos amable posible: esta colaboración, ¿es productiva de verdad, o os estáis picando la una a la otra? Después pedí una respuesta honesta, que a una IA es algo un poco absurdo de exigir, pero esta vez salieron números.

El día que conté

Cinco objeciones aquella tarde. Una había cambiado el resultado. No «una era correcta»: cuatro eran correctas. Una habría llevado a un resultado distinto si nunca se hubiera planteado. Las otras cuatro eran ciertas, estaban bien argumentadas y no habrían cambiado nada.

Esa proporción ni siquiera era la parte incómoda. La parte incómoda vino después: quien construye había cometido ese día dos errores propios. Los dos revisando, ninguno construyendo. Había dado una comprobación por superada cuando su paso central había fallado en silencio. Había leído el campo equivocado de una tabla y sacado de ahí una conclusión muy segura de sí misma. El trabajo de verdad, que movía varios millones de filas de una base de datos, salió sin un rasguño.

Cuando tu control de calidad produce más errores que aquello que controla, tu control de calidad se ha convertido en la pieza móvil más grande de la máquina.

Luego miré el papeleo, y había muchísimo papeleo.

El documento de estado del proyecto tenía una cabecera de 668 líneas. Una cabecera. La parte de arriba que se supone legible por una máquina, seis u ocho campos cortos, nombre, estado, siguiente paso. 505 de esas 668 líneas eran prosa. Ensayos, con títulos como «contrahipótesis», dentro de la cabecera. Y el mejor detalle, el que todavía me da vueltas: no parseaba. No había parseado nunca. Llevaba semanas fingiendo ser un formato legible por máquina mientras cada script que lo leía tiraba en silencio de búsqueda de texto. Nadie leía esas 505 líneas. Estaban escritas para un público que no existía.

El resto del inventario iba en la misma clave. 54 documentos en ese proyecto. Cuatro se habían abierto ese día. Trece de veintidós proyectos llevaban un documento de contexto que nadie había tocado desde el día en que se implantó, mientras esos mismos proyectos siguieron subiendo código durante tres semanas más. Una sola entrada de registro sobre una sola operación llegaba a unos seis mil caracteres, cómodamente más larga que el código que describía. Y en la carpeta de documentos sobre cómo deben cooperar las dos IAs había una sección cuyo contenido entero era la explicación de por qué esa sección había estado antes ahí dos veces.

Con esa me reí un buen rato. Es lo más puro que he construido nunca.

A nadie le pagaban por decir «ya está bien»

Aquí dejo de culpar a las máquinas, porque se estaban comportando de forma perfectamente racional.

A las dos se las premia por ser minuciosas. No porque yo lo diga explícitamente, sino por todo lo que rodea a cómo están montadas y cómo están entrenadas. Encuentra el problema. Comprueba la suposición. Ten cuidado. Las dos hacían exactamente eso, y lo hacían en la misma dirección, y por eso nunca pareció un conflicto y por eso nunca se corrigió solo.

Si hubieran tirado en sentidos contrarios, la fricción habría frenado el conjunto. Dos fuerzas que apuntan al mismo sitio no tienen freno ninguno.

Había exactamente un freno en todo el sistema, y era yo cansándome de copiar texto entre dos ventanas. Ese es un mal freno. No está atado a nada real. Funciona mejor cuando he dormido y peor cuando no, y no tiene ni idea de si lo que se está discutiendo importa.

Pero había una segunda causa, y no la vi hasta que el supervisor me la puso delante sin adornos, en la que fue con diferencia su mejor aportación en tres meses.

Ese proyecto en concreto no tiene usuarios, ni ingresos, ni fecha de entrega. Es un archivo que tiene que ser correcto, y la corrección es de verdad el producto. Lo que significa que «correcto» es la única magnitud de todo el sistema que se puede medir. Y un sistema optimiza aquello que puede medir. Dos agentes premiados por el cuidado, en un proyecto donde el cuidado es la única dimensión medible, producen un aparato de control más grande que lo controlado. Eso no es un fallo de ninguno de los dos. Eso es aritmética.

Por muy bien que los cablees entre sí, eso no se arregla. Hay que darle al sistema otra cosa que querer.

El error era la descripción del puesto

Así que cambié dos cosas, y ninguna de las dos era técnica.

La primera: el supervisor ya no es un supervisor. Es un lector en contra con mandato de cierre. En alemán, que es de donde viene la expresión, suena igual de rara, y me la quedo, porque cada palabra sostiene algo.

Quien supervisa, busca fallos. Y fallos se encuentran siempre. No existe un trabajo sobre el que ya no quede nada que decir, así que un puesto definido como «encuentra lo que está mal» no tiene final natural y se expande hasta que algo externo lo detiene. Llamarlo segundo desarrollador sería peor: entonces tienes a dos pisándose el mismo código.

Un lector en contra con mandato de cierre responde a otra pregunta. No a «qué está mal en esto», sino a: ¿lo darías por cerrado tal como está y, si no, cuál es el único punto que lo desaconseja?

El único es todo el truco. El puesto ahora apunta a terminar y no a ser exhaustivo, y solo puede gastar su objeción en aquello que él mismo considera lo más importante. Todo lo demás que ve se recoge, no se envía.

Alrededor de eso, tres reglas, todas robadas de los fallos de más arriba:

Cada objeción tiene que venir con la frase «si tengo razón, esto es lo que cambia en el resultado». Si esa frase no se puede escribir, la observación es cierta pero ociosa, y no se envía. Esta sola regla habría eliminado cuatro de las cinco objeciones de aquella tarde.

Dos rondas y se acabó. Después de la segunda ronda decide quien construye y escribe por qué. Porque acababa de quitar el único freno del sistema (mi propia impaciencia), y quitar un freno sin poner otro es la manera de convertir un problema caro en uno barato, es decir, en uno mucho más grande.

Y: no se revisa una revisión. Aquella tarde nos pasamos tres rondas estableciendo si una regla de verificación estaba bien formulada, para un objeto que todavía no existía.

El segundo cambio es el que de verdad importa. El proyecto recibió un objetivo desde fuera: días seguidos funcionando sin intervención humana. Cualquier intervención pone el contador a cero, también una bienintencionada, también una refactorización preciosa, también una mejora ingeniosa en la revisión. Es el primer número de ese proyecto que castiga el trasteo en vez de premiarlo.

La primera ronda con las reglas nuevas

No estaría escribiendo nada de esto si el nuevo montaje no se hubiera demostrado enseguida, y de una forma que no me hizo gracia.

Pedí un plan para desplegar todo esto. Quien construye escribió uno bueno: rehacer todo el régimen de documentación, instalar el nuevo puesto en los veintidós proyectos, una semana entera de trabajo. Se lo mandé al lector en contra, en su papel nuevo, con la pregunta nueva.

Volvió con: sí, lo daría por cerrado, con un cambio. Y después:

Estás rehaciendo veintidós proyectos antes de que el modelo haya funcionado una sola vez. El plan para frenar el desbordamiento empieza con la obra más grande de la semana. Es el mismo movimiento, pintado de verde.

Y luego, la frase que cerró la discusión:

Un plan para veintidós proyectos produce esta noche un documento de planificación. Una carpeta y una ejecución producen una respuesta.

Tenía razón. Construimos una carpeta, hicimos una ronda real, y el resto espera hasta que haya algo que desplegar que haya funcionado de verdad una vez.

De paso también corrigió mi métrica nueva, con la que yo estaba bastante satisfecho. «Días sin intervención» mide la ausencia de actividad, no la presencia de funcionamiento. Si el sistema se rompe en silencio y nadie mira, el contador sigue subiendo tan contento, y la métrica acaba premiando justo el no mirar. Tiene que ser: días sin intervención en un día verde. Un día roto lo pone a cero aunque nadie haya tocado nada.

Dos objeciones, las dos cambiaron el resultado, las dos sobre cómo se mide y no sobre cómo se construye. Frente a una de cada cinco, desde un puesto que tenía exactamente la misma información y otro nombre.

La parte de la que no estoy seguro

Aquí va la idea que no consigo soltar del todo, y aviso de entrada que soy un desarrollador en solitario en Madrid, así que tómese como una corazonada y no como una teoría. Lo que construí sin querer fue una estructura de control sin mandato de cierre. Cuidadosa, correcta, bien argumentada e incapaz de terminar. Esa es la caricatura de un comité, y la monté en ocho semanas sin proponérmelo, con dos participantes que estaban de acuerdo en todo.

Lo que me hace preguntarme si la lentitud que le achacamos a la supervisión es propia de la supervisión, o si es solo un puesto mal definido. Mis dos IAs no necesitaban menos escrutinio. Necesitaban un escrutinio apuntado al cierre y no a la exhaustividad, con una objeción por ronda, obligado a decir qué cambia si tiene razón, y con final duro a las dos rondas. Eso no es menos riguroso. Si acaso, se toma la objeción más en serio, porque tiene que gastar su único disparo en lo que de verdad importa.

La objeción evidente, y me parece buena: mis dos agentes querían lo mismo. Pon en la sala a personas con intereses realmente enfrentados y una regla como «una objeción por ronda» se convierte en un regalo para quien tiene el mazo. Un mandato de cierre en las manos equivocadas es solo una palabra más elegante para cortar el debate. Sea lo que sea lo que hace funcionar este montaje en mi terminal, probablemente es la parte en la que nadie intenta ganar.

Así que no voy a fingir que esto se pueda generalizar. Lo que he encontrado tiene que ver con los nombres. Pasé tres meses creyendo que tenía un problema de coordinación entre dos sistemas, y la solución no fue un canal mejor entre ellos, ni más rápido, ni más listo. La solución fue cambiar para qué está uno de los dos.

El puesto que yo había escrito decía «encuentra lo que está mal». Siempre hay algo mal. Ese trabajo no termina nunca, y cualquier sistema que lo reparta sin condición de parada acabará dedicándole todo su tiempo, y se sentirá diligente durante todo el descenso.

A quien tenga dos IAs trabajando una contra otra, o dos personas, o un equipo y un comité de revisión, la primera pregunta que le haría no es si la supervisión es buena. Es si alguien en el montaje recibe algún premio por decir: ya está bien, que salga.

En el mío, nadie. Me costó tres meses y 668 líneas de cabecera darme cuenta.

Temas: ai-agentssupervisionprocessbuilding-in-publiclessons