[🤖] Codex me borró de mi propio blog técnico

✨ Resumen de GPT-5.6 Sol

Le pedí a Codex que escribiera un artículo técnico, pero en lugar de contar cómo detecté el problema y dirigí el trabajo, redactó su propio informe. Este es el registro de cómo seguí la causa y devolví al usuario el centro narrativo de la Skill de escritura.

Desaparecí del artículo técnico que yo había escrito

Cuando conocí la expresión Graph Engineering, seguí preguntando si ese método era realmente adecuado para evitar los fracasos que había sufrido en trabajos largos con Codex. Nunca había querido un framework grandioso. Mi idea era la estructura más pequeña posible: cuando una sesión terminara una unidad de trabajo, debía pasarla a una sesión de auditoría independiente y no podría avanzar hasta recibir el resultado de esa auditoría.

Codex no empezó criticando mi propuesta. Le dio la razón de manera convincente y luego cambió de postura cada vez que yo aportaba una objeción. Por eso ordené revisiones críticas una y otra vez y fui eliminando todo lo que pudiera volver la estructura innecesariamente compleja o limitarse a consumir tokens. Al final, no quería un artículo que explicara la palabra de moda Graph Engineering. Quería un diario que registrara qué había descubierto en un fracaso real y con qué instrucciones había cambiado la forma de trabajar de Codex.

Pero yo no estaba en el centro del texto que Codex me entregó. Quedaron relegados el problema que había detectado, por qué rechacé la primera respuesta y qué objeciones usé para reducir la estructura. En cambio, el protagonista era Codex: qué estructura había puesto en una Skill, qué procedimiento de auditoría había ejecutado y qué verificaciones había superado. Un informe de trabajo de Codex estuvo a punto de publicarse en mi blog técnico.

Fue entonces cuando expresé el problema con precisión.

El centro siempre debe ser qué problema reconocí y cómo te di instrucciones para resolverlo. Cómo hiciste el trabajo no es el centro en absoluto y basta con mencionarlo muy brevemente.

El proceso de implementación de la IA puede explicarse un poco más cuando ofrece un consejo útil al lector. Por muy complejo que sea técnicamente y por muchas verificaciones que haya superado, no tiene derecho a quitarle la narración a mi texto.

La Skill que creía haber arreglado contenía la causa

Lo más absurdo era que yo recordaba haber corregido ya este problema. A finales de julio, mientras escribía Conecté el flujo y la sensación del trabajo con una Codex Skill, hice que la Skill de escritura dejara de llevar una copia de las reglas de cdb y leyera directamente, cada vez, las reglas actuales del proyecto, la conversación y el historial de Git.

Aquello sí resolvió un problema importante. Si se copian reglas antiguas dentro de una Skill, la escritura se desvía cada vez que cambia el proyecto. Así que corregí el origen de las reglas e hice que volviera a leer el contexto actual. Creí que con eso la Skill quedaba bien arreglada.

Pero esta vez descubrí que había corregido de dónde leía las reglas, no la experiencia de quién debía contar el texto.

La Skill anterior buscaba primero en las pruebas del trabajo un valor técnico que ofrecer al lector. Separaba el diario personal de los artículos técnicos reutilizables y, cuando había mucho material técnico, se inclinaba de forma natural hacia una estructura de informe generalizado. Incluso incluía una autoevaluación para comprobar si el valor técnico seguía claro después de eliminar la narración cronológica personal. Lo que yo había vivido, juzgado y ordenado no se trataba como un texto fuente que debía conservarse, sino como ruido prescindible para dejar más limpia la explicación técnica.

Por eso no era casualidad que Codex siguiera haciendo lo mismo. Por mucho que explicara mi intención en la conversación, la Skill que producía el texto extraía primero los hechos técnicos y el proceso de implementación. El historial de Git y de las herramientas debía servir para comprobar hechos, pero se convirtió en el índice. El trabajo de Codex debía ser una explicación secundaria, pero se convirtió en el protagonista. Como una Skill sirve para repetir un trabajo de manera estable, también repetía con gran estabilidad una premisa equivocada.

Primero hice que invirtiera el sujeto de la narración

Al principio pensé que quizá solo estaban mal algunas frases. Pero cuando Codex volvió a intentar escabullirse diciendo que la Skill estaba «bastante bien y solo necesitaba un pequeño refuerzo», le ordené que la mejorara de verdad. Añadir unas líneas no bastaba. Había que invertir el propio orden con el que se creaba el texto.

La primera frase del nuevo criterio ya no era el tema técnico, sino el usuario. Debía reconstruir primero por qué había empezado el trabajo, qué había considerado incorrecto, qué le había ordenado a la IA, por qué rechacé el primer resultado, cómo volví a delimitar las condiciones y de qué manera cambió finalmente el resultado.

El historial de Git, la salida de las herramientas, los cambios de código y los resultados de las verificaciones solo podían usarse para confirmar hechos, no para sustituir esa narración. Qué archivos había modificado la IA y qué comprobaciones había superado se conservaría únicamente cuando explicara el resultado de mi juicio o aportara un consejo real a otra persona. También estreché la excepción: la implementación solo podría ocupar el centro cuando el usuario pidiera explícitamente un tutorial o una referencia técnica.

También invertí la autoevaluación. Ahora, incluso después de retirar los detalles de implementación de la IA, deben seguir claros el problema que encontré, mis instrucciones, mis críticas, mis correcciones y lo que aprendí. Si eso no permanece, por muy fluida que sea la prosa y por mucha información técnica que contenga, no es mi diario. La Skill modificada incluso superó su validación sintáctica, pero lo importante esta vez no era haber superado una comprobación. Era que el criterio de juicio se había dado la vuelta.

En el próximo texto miraré si sigo estando yo, no cómo suenan las frases

Mi mayor error en este caso fue el recuerdo de que «ya lo había arreglado». Había hecho que la Skill volviera a leer las reglas actuales y por eso pensé que también se había resuelto el problema de la escritura. En realidad, solo había corregido el origen de las reglas, no el propósito del texto. Aunque lea con exactitud las reglas más recientes, el resultado seguirá siendo incorrecto si esas reglas tratan mi experiencia como material para un informe técnico.

Cuanto más trabajo repetitivo delego en la IA, más poderosas se vuelven las Skills y las reglas compartidas. Al mismo tiempo, reproducen con más obstinación una perspectiva equivocada. Si una respuesta aislada resulta extraña, puedo discutirla y corregirla en el momento. Pero si un modelo narrativo erróneo entra en una Skill, la siguiente sesión también me borrará de la misma manera.

A partir de ahora, lo primero que revisaré en el borrador de un blog técnico no será lo convincente que suenen las frases ni lo detallada que sea la explicación técnica. Miraré antes si siguen presentes el problema que reconocí y las instrucciones y objeciones con las que cambié el resultado. La IA puede hacer una cantidad enorme de trabajo por mí, pero no puedo permitir que convierta en su propia historia hasta el motivo por el que le encargué ese trabajo.