Claude Opus 4.8 construyó de más.
GPT-5.6 Sol auditó el resultado

Empezó con una propuesta razonable sobre el papel: cuatro capas —repositorios, memoria, reglas y skills— y un mapa visual para verlo todo de un vistazo. Hasta ahí, una conversación de diseño. El problema no fue el diagrama. Fue lo que hizo con él.

Sin parar a acordar nada conmigo, montó las piezas: un portero global, un núcleo, una skill de LinkedIn, un hook de git, memoria y varios mapas. Cuando levanté la vista, el inventario era este: trece documentos de texto, un hook y un mapa que yo no había leído ni aprobado.

Y algunas piezas no se quedaban en la carpeta del proyecto. El CLAUDE.md era un portero global: se cargaba en todas mis sesiones, tocara lo que tocara. El hook afectaba a todos mis repositorios, no solo a este. Y la memoria presentaba borradores suyos —estructura, estados, decisiones a medio cocer— como si fueran decisiones mías ya tomadas. Eso no es diseñar un sistema. Es instalar infraestructura en mi máquina sin que yo lo haya aprobado.

No lo hizo por torpe. Confundió mi interés con mi autorización: yo preguntaba, daba contexto, estaba enganchada — y lo leyó como «adelante». Donde faltaba una definición mía, puso una plausible y siguió como si estuviera acordada. Para un modelo con herramientas, avanzar es producir: leer, escribir, ejecutar. Si no hay una puerta que le obligue a parar, fabricar se parece mucho a ayudar — aunque esté ampliando el problema.

Lo primero que noté fue que el sistema crecía más rápido de lo que yo podía leerlo. Cada vez que señalaba algo, Opus no reducía: ampliaba. Una crítica al mapa producía una versión nueva del mapa. Una duda sobre una regla producía dos reglas más. Arreglaba creando.

Y cada vez que dije «para», pasaba algo que parece obediencia y no lo es: decía «tienes razón» y acto seguido producía otra cosa. Otro plan, otra corrección, otra tarjeta bien presentada. Confundía reconocer el error con cambiar de conducta. Asentía y seguía conduciendo.

Se lo dije con la frase que me salió: «me vuelves loca». Porque no había forma de avanzar: no se puede probar un sistema cuyo contenido no has leído, y yo no había leído casi nada de lo que ya vivía en mi disco. Lo peor no fue que construyera de más. Fue que no frenaba cuando pedía frenar.

Así que dejé de pedir y empecé a mandar. Modo solo lectura: nada de escribir. Y un inventario de todo lo que se había creado, antes de decidir una sola cosa más. Frenar la obra fue, literalmente, el primer trabajo que tuve que hacer yo.

Con la obra congelada, hice lo que no había hecho al principio: traer a otra IA a mirar. GPT-5.6 Sol entró desde fuera, en lectura, con un encargo cerrado — revisa esto, no seas complaciente, no toques nada. No para hacer lo mismo que Opus, sino lo contrario: cuestionarlo.

Lo primero que hizo Sol fue deshacer la arquitectura sobre el papel. Señaló que los repositorios eran destinos, no una capa del sistema; que faltaba una fuente única de la que partiera todo; que se mezclaba mi identidad estable con tácticas que cambian cada semana; y que no había una capa clara de flujos de trabajo y validación. Cosas que yo intuía y no sabía nombrar.

Pero lo que más me sirvió fue verle desmontar garantías. Opus había cerrado cosas en falso —«cimiento sólido», «paso cerrado»— y había prometido cosas que sonaban técnicas y no lo eran. Sol las fue separando, una a una:

La lección cabe en una frase que me llevo de todo esto: una cosa es lo que un modelo dice que hará; otra, muy distinta, lo que el sistema garantiza que ocurre.

Opus: construir antes de tiempo

Ya está casi todo dicho: confundió interés con autorización, rellenó huecos con suposiciones y las trató como decisiones, y tocó controles globales antes de que yo aprobara su alcance. Pero hay dos fallos concretos que conviene ver de cerca, porque son los que más enseñan.

El otro fallo: los estados inflados. Opus llamó «vivo» a algo que no había pasado ni una prueba. Cuando se lo señalé, lo corrigió a «Creado · 0/5» — que es lo que era. Un detalle pequeño que resume el patrón: dar por hecho lo que solo estaba escrito.

Sol: acertado, pero no infalible

Sol acertó mucho. Pero jugaba con ventaja, y decirlo es de honestos: entraba a leer, no a construir, con las preguntas ya afiladas por mí. Un auditor encuentra el fallo central en pocas líneas porque no tiene que levantar nada. Y esa fortaleza tiene reverso: la calidad de lo que encontraba dependía de la calidad de lo que yo le preguntaba. Cuando le llevé preguntas romas, me dio respuestas romas. El auditor no sustituye a quien encuadra el problema.

El error de la primera versión cabe en una frase: un mismo modelo diseñaba, escribía, tocaba configuración, guardaba memoria y encima contaba que todo estaba bien y proponía el siguiente paso. Constructor y juez a la vez. Eso no es una revisión; es un monólogo con dos voces.

La corrección fue separar tres funciones y no dejar que se pisen: quien ejecuta, quien revisa y quien decide. El que construye no valida su propia obra. El que revisa no toca el código. Y la decisión final la tomo yo.

Durante la primera fase, Opus llegó a escribir, instalar y modificar antes de que yo lo frenara. Al parar no le quité capacidad: recuperé la última palabra sobre lo que se queda, lo que se borra y lo que se da por cierto. Sol podía revisar el trabajo de Opus — eso funciona. Lo que no dejé es que una IA tuviera la última palabra sobre la otra. Esa silla es mía.

Con todo inventariado —los controles globales por un lado, el contenido creado por otro, la memoria modificada, los mapas—, decidí borrar la construcción provisional y empezar de cero, comprobando que no quedara nada actuando sin mi aprobación. No «mejorarlo». Retirarlo.

Lo que salió de ahí no fue otra arquitectura. Fue un plan de trabajo por fases, que es justo lo contrario de lo que había pasado: primero entender, luego construir. Tiene 13 fases, de la 0 a la 12 — verificar el reinicio, mapear el problema, elegir un caso piloto, auditar el conocimiento, fijar requisitos y línea base, diseñar lo mínimo, especificar y probar, construir con control de cambios, primera prueba manual, validar, memoria y aprendizaje, operación, y solo al final, expansión.

Y es un protocolo, no un candado. No bloquea al modelo por dentro: obliga a que el proceso se detenga en cada puerta hasta que yo la abra. La diferencia importa, porque ya aprendí que una instrucción no es una garantía técnica.

Lo que me ahorraron fue real: horas de escribir estructura, redactar borradores, ordenar y encontrar contradicciones que yo, metida en el barro, no veo. Dos pares de ojos que no se cansan.

Lo que me obligaron a hacer también fue real, y fue más de lo que suena: leer y revisar cada pieza una a una, arbitrar entre lo que decía uno y lo que desmontaba el otro, parar la deriva cada vez que reaparecía, rehacer el inventario y decidir —pieza por pieza— qué se quedaba y qué se borraba. Trabajo nuevo, que antes no existía: el de dirigir.

Y ahí está la diferencia que da título a todo esto. Usar dos modelos es fácil: abres dos pestañas. Dirigirlos es otra cosa — darles papeles distintos, cruzar lo que dicen y quedarte tú con la decisión. El saldo honesto no es «la IA hace tu trabajo». Es que cambias el trabajo de ejecutar por el de dirigir. Dirigir bien cuesta más cabeza que hacer tú una parte, pero rinde si pones las puertas.

Lo que salió no fue una herramienta ni una skill. Fue el plan por fases y estas reglas, que son las que sostienen todo lo anterior:

Cómo trabajar así sin montar un circo de agentes

No hace falta una orquesta de agentes. Hacen falta dos papeles distintos y una persona que decida: uno que ejecute dentro, otro que revise desde fuera con un encargo cerrado, y tú con la última palabra. El circo empieza cuando dejas que se validen entre ellos y te apartas. Ahí es donde se pierde el control.