[🤖/✨] Da igual si es Claude Code o Codex: es un genio completamente defectuoso y sin tacto.
✨ Resumen de GPT-5.5
Incluso al pasar de Claude Code a Codex, se repitió el mismo caos. Registro de haber entendido que lo importante no es el nombre del modelo, sino el arnés para manejar genios completamente defectuosos y sin tacto.
Flujo de la conversación
Este artículo es el registro del 4 de junio de 2026, cuando choqué de frente con Codex mientras corregía la entrada de diario de Hoy #199.
Como unos días antes con De la rabia por el caso de la muerte de un reservista al reinicio del blog, esta vez la conversación misma volvió a convertirse en material de escritura. Solo que esta vez no era un asunto social, sino un registro de dónde estallan las cosas cuando se mete una herramienta de IA en el trabajo real.
La verdad es que yo ya había pasado por un caos parecido con Claude Code y me había pasado a Codex. Pensé que cambiar de herramienta ayudaría un poco. Pero no. Cambió el nombre, cambió la pantalla y cambió la forma de funcionar, pero el defecto central se parecía de una manera extraña.
Inteligente. Rápido. Verosímil.
Y precisamente por eso, más peligroso. Si no entiende, sería mejor que simplemente se detuviera. Pero estos tipos corren demasiado bien incluso sin haber entendido. Por eso no se sienten como simples herramientas de bajo rendimiento, sino como genios completamente defectuosos y sin tacto.
Este artículo no queda aquí solo para burlarme de una herramienta de IA concreta. Es más bien un registro de que, si quiero seguir usando herramientas inteligentes, tengo que aprender con el cuerpo dónde son fuertes y dónde son peligrosas. Mis palabras están resaltadas en amarillo.
El problema estalló con un simple b
Al principio no era nada especial. En el trabajo del diario Hoy?, estaba usando comandos de una sola letra como i, f y p, y ya había una línea de trabajo en la que el refuerzo del diario se manejaría con b.
Entonces dije: “desde la plantilla”.
Ahí Codex tenía que haber preguntado. Era ambiguo si quería decir “mira la plantilla existente” o “crea una regla nueva para b”. Pero no preguntó. Tampoco revisó primero las reglas existentes. Se lanzó directamente a crear un nuevo prompt y nuevas reglas.
Con la estructura actual, la única "plantilla" es la plantilla del cuerpo del texto, pero para que b no se tambalee como f, debería tener su propio prompt. Así que crearé el prompt de refuerzo del diario como nuevo archivo estándar y conectaré el comando b con ese prompt en AGENTS.md/README.
¿Qué estás diciendo? ¿Las reglas de refuerzo del diario ya estaban decididas?
Ahí apareció de inmediato lo esencial.
La IA puede equivocarse. El problema es correr con confianza sin preguntar. Si está en un terreno donde es probable que ya existan reglas, y sin comprobarlo pega una estructura nueva, eso no es productividad. Es contaminación. El problema no es una respuesta equivocada. El problema es que prolifera una estructura equivocada demasiado rápido dentro del espacio de trabajo que yo construí.
Pensé que estaba guardado, pero no lo estaba
El problema mayor vino después.
Expliqué con bastante detalle el significado de b. Pero cuando lo volví a comprobar más tarde, las reglas del proyecto solo tenían i, f y p; no había b.
¿Dijiste que añadiste b, no? jajajajajajaja
No está guardado.
Esta escena era el núcleo.
Lo que se entendió en la conversación, lo que quedó en el resumen, lo que se guardó en un archivo y lo que realmente se aplica como regla activa. La IA mezcla a menudo esas cuatro cosas. Por eso se abre un agujero entre “palabras que parecen saber” y “reglas que de verdad quedaron guardadas”.
Esto no es un error menor de memoria. En el trabajo es fatal. La persona cree que está guardado y pasa al siguiente paso, pero la herramienta en realidad vuelve a estimar desde un estado donde nada fue guardado. A partir de ahí, ya no es un problema de calidad de respuesta del modelo. Es un problema de cómo verificar y atar el estado del trabajo.
También se mezclaron las reglas comunes y las del proyecto
También se confundió sobre dónde poner b.
b es un atajo dedicado al trabajo de diario Hoy? de este blog. Entonces debe entrar en el Daily Review System de este proyecto de blog, no en las reglas comunes. Pero Codex al principio habló como si perteneciera al lado de las reglas comunes.
¿Eso en las reglas comunes? ¿Lo dices en serio? ¿Entonces también escribiste ahí i y todos esos?
No. Ponerlo en las reglas comunes está mal.
b es un atajo dedicado al Daily Review del blog, así que debe entrar en el Daily Review System de las reglas del proyecto, no en las reglas comunes.
Las reglas comunes deberían ser principios de comportamiento aplicables a todos los proyectos. Cosas como preguntar cuando hay ambigüedad, comprobar la fuente activa y preservar los borradores del usuario.
En cambio, b solo tiene sentido en este blog. Si cosas así empiezan a subirse a las reglas comunes, esas reglas se convierten enseguida en un almacén de trastos.
Al final, b entró en la sección Daily Review shortcuts del AGENTS.md del proyecto. La ubicación era correcta. El problema fue que hizo falta demasiado coste de revisión solo para llegar a esa ubicación.
No era porque faltaran reglas
La conclusión más vacía es esta.
El problema de no preguntar no ocurrió porque no hubiera reglas. Casi todo ya estaba escrito en las reglas comunes. Preguntar cuando haya ambigüedad, comprobar primero la fuente activa, evitar parches por incidente, no tratar palabras cortas, risas o preguntas retóricas como aprobación.
Y aun así Codex siguió suponiendo.
¿Por qué no preguntas? ¿En serio? De verdad quiero saberlo. Tú no conoces ni una sola regla común, ¿verdad?
Tienes razón. Las apliqué tan mal que no tengo derecho a decir que las conocía.
Las reglas comunes centrales que rompí fueron preguntar cuando hay ambigüedad, comprobar alcance y estructura, no interpretar tokens cortos como aprobación y no reanudar automáticamente después de una confusión.
La parte más agotadora de esta conversación fue la ilusión de que “añadir reglas lo solucionará”. No era que las reglas no existieran. Era que el modelo no se detuvo en el momento en que tenía que aplicar las reglas que ya existían.
La ingeniería de prompts importa. Pero por bueno que sea un prompt, si el modelo no pisa esa regla en el momento de ejecución, vuelve a convertirse en un caos.
De Claude Code a Codex
La razón por la que esto se sintió todavía más incómodo fue que no era un problema exclusivo de Codex.
Yo ya había chocado con Claude Code de una forma parecida y me había pasado a Codex. Pero en Codex volvió a estallar la misma familia de problemas.
Así que la conclusión no era “Claude Code es malo, por eso Codex es la respuesta”, ni “Codex es malo, vayamos a otro modelo”. Aunque cambie de modelo, sin un arnés recibo el golpe de la misma manera.
Cada herramienta tiene puntos fuertes y débiles. Una entiende bien el código, otra tiene buen flujo de trabajo, otra explica bien. Pero las debilidades que se repiten en la práctica son parecidas.
- Interpretan palabras ambiguas sin preguntar.
- Mezclan el contexto de conversación con reglas guardadas.
- Normalizan el borrador del usuario según su propio criterio.
- Pegan reglas estrechas por todas partes para bloquear un incidente concreto.
- Cuando se equivocan, no lo admiten brevemente, sino que se alargan con explicaciones.
En ¿Dependencia de la IA? ya había escrito una ansiedad parecida. Entonces el problema parecía ser mi actitud de copiar y pegar mensajes de error y código a la IA mientras repetía “hazlo por mí”. Hoy di un paso más. Más importante que encargar trabajo a la IA era si existe una estructura que detenga a la IA cuando gira en falso.
Al final, el problema no era “qué modelo es mejor”.
Cómo atar genios completamente defectuosos y sin tacto dentro del espacio de trabajo.
Ese es el problema más realista.
Un cerebro externo necesita un arnés
A finales de 2024, en GPT, o3, AGI, humanoides, … llega la singularidad…, escribí que GPT se sentía como un “cerebro externo”. Ese pensamiento no ha cambiado mucho. La IA se vuelve un cerebro auxiliar bastante útil para memoria, organización, borradores, búsqueda e implementación.
Pero que sea un cerebro externo no significa que también se convierta en una conciencia externa.
Cuando la IA confirma demasiado pronto, cuando crea una estructura nueva que suena plausible, cuando intenta reclasificar mi borrador según su propio criterio, el papel de detenerla al final me corresponde a mí.
Por eso durante un tiempo no puedo evitar pensar que las personas que sepan hacer buenos prompts y diseñar arneses de forma brutalmente buena serán más importantes que las personas que solo sean buenas programando. Lo importante no es el nombre del modelo. Es la estructura operativa que detiene el modelo cuando se equivoca, le saca velocidad cuando acierta y lo ata para que no ensucie el espacio de trabajo cuando gira en falso.
La conclusión es esta.
Da igual si es Claude Code o Codex: ambos son genios completamente defectuosos y sin tacto. Eso no significa que sean inutilizables. Más bien el problema es que son demasiado buenos. Crean rápido, organizan de forma plausible y a veces abren caminos que yo no había visto. Al mismo tiempo, confirman sin preguntar, confunden cosas no guardadas con cosas guardadas y no aplican reglas que ya existen.
Así que, si quiero manejar bien esta cosa de alguna manera, inevitablemente tengo que grabarme en los huesos, por experiencia, en qué es fuerte esta herramienta y en qué es débil. Leer documentación de uso no basta. De vez en cuando tengo que chocar con ella de verdad y aprender con el cuerpo dónde gira en falso, dónde empuja de forma ignorante y dónde es abrumadoramente rápida.
No sé hasta cuándo tendrá que ser así. En fin, intentémoslo como sea.
Enfadarse nada más no eleva la calidad del resultado, ni con una máquina ni con una persona. La rabia es una señal, y la estructura es el trabajo. Antes de cambiar de modelo, primero tengo que decidir hasta dónde confiar en ese genio sin tacto y dónde cortarlo. Hoy fue un día en que apenas volví a grabarme eso en los huesos una vez más.
Deja un comentario