🧭 El Cambio: modelos que operan con intención

Durante tres años, la receta fue la misma: el modelo se equivoca y tú escribes una regla más. "Siempre ejecuta las pruebas". "Lee la documentación antes de cambiar cualquier cosa". "Pide permiso en cada paso". Cada línea surgió de una falla real de un modelo más débil. En septiembre de 2026, esa receta dio un giro: los dos modelos nuevos siguen las instrucciones tan bien que obedecen las muletas — y las muletas empezaron a costar calidad.

Claude Fable 5.1 (Anthropic, 1/sep/2026). El mismo modelo que Mythos 5.1, con salvaguardas diferentes. Fue creado para trabajo largo y autónomo: sostiene tareas de horas o días, lleva sus propios registros, vuelve a priorizar y retoma desde donde quedó. La guía oficial de prompting de Fable 5 dice textualmente que las skills creadas para modelos anteriores “son demasiado prescriptivas y pueden degradar la calidad del resultado”. La versión 5.1 quedó ~25% más barata en el uso típico y hasta 45% en trabajo agéntico; con un nivel de esfuerzo medio ofrece lo que Fable 5 ofrecía con un nivel alto.

GPT-6 Astra (OpenAI, vista previa el 3/sep, disponible al público el 4/sep/2026). Grandes avances en uso de la computadora, código, ciencia y contexto largo. Un comportamiento nuevo que sorprende a todos: él pregunta más antes de actuar y lo formatee todo en listas. Un prompt que solo describe la tarea suele volver con una pregunta y un resumen en vez del trabajo hecho. Según las orientaciones de la propia OpenAI (citadas por las guías que leímos), el antídoto es decirle al modelo que inferir la intención a partir del contexto y persistir hasta completar el objetivo — y dejar claro que reconocer que podría hacer no es lo mismo que haber hecho.

Observa el patrón. Los dos errores son opuestos (uno hace más de lo pedido y el otro se detiene demasiado pronto), pero la causa es la misma: el modelo está obedeciendo lo que escribiste, no lo que querías. Si tu texto todavía describe pasos, el modelo ejecuta pasos. Si describe límites estrictos, se detiene en el límite. Lo que falta no son más instrucciones: es expresar la intención de una forma que el modelo pueda completar por su cuenta.

El 5/set/2026, el equipo de experiencia para desarrolladores de Codex, en OpenAI, publicó una guía en la que recomendaba a sus propios usuarios "dejar de sobreingenierizar los prompts": las skills, los archivos de instrucciones y las solicitudes de tareas acumularon "grasa: el apoyo que un modelo débil necesitaba y uno fuerte no necesita". Por su parte, Anthropic recomienda lo mismo con otras palabras: revisa las instrucciones antiguas y elimina lo que el comportamiento predeterminado ya hace mejor.

Para este curso, la noticia es buena. Los 5 pilares del día 2 no desaparecen: ellos cambian de forma. El contexto se convierte en fuente de verdad (qué es autoritativo, no todo lo que sabes). Los objetivos se convierten en resultado + definición de listo. Las reglas se convierten en límites de autoridad (qué decide por su cuenta, dónde se detiene). La memoria se convierte en archivo de lecciones que el modelo lee y escribe. La validación se convierte en verificación con evidencia antes de declarar que terminó. Eso es lo que vamos a crear hoy.

Una advertencia honesta: todo esto tiene fecha. Los dos modelos llevan menos de una semana en uso mientras escribimos, y su comportamiento aún se está midiendo. Lo que no cambia es el método: con cada cambio de generación, vuelves a auditar lo que escribiste. Este día enseña el método con los hechos de sep/2026 como caso.

Escribir para la nueva generación es, ante todo, un ejercicio de borrar. No porque las instrucciones hayan dejado de importar, sino porque ahora cada línea se toma en serio. Una línea inútil ya no se ignora: se obedece y ocupa el lugar de una línea que sí importaba.

El criterio para decidir es una sola pregunta, hecha línea por línea: “¿el modelo que uso hoy todavía necesita esto?” Si la línea existe porque un modelo de 2024 se olvidaba de ejecutar pruebas y el de 2026 las ejecuta sin que se lo pidas, se elimina. Si existe porque la acción es realmente peligrosa (borrar datos, publicar en producción, gastar dinero), se mantiene y recibe el nombre correcto: frontera, no paso.

Los objetivos de recorte más comunes, según las guías de ambas empresas: (1) rituales obligatorios ("lee toda la documentación antes de hacer cualquier cambio"); (2) recordatorios de lo obvio ("ejecuta las pruebas", "no inventes"); (3) “pide permiso” genérico, creado después de un susto con un modelo antiguo; (4) reglas de formato en ambos sentidos: Fable 5.1 ya usa menos negrita y listas que las versiones anteriores, así que «nunca uses viñetas» hoy elimina una estructura que haría falta; (5) “muestra tu razonamiento” — en Fable esto incluso puede activar una negativa por extracción del razonamiento; si necesitas ver el progreso, pide actualizaciones del progreso, no la transcripción del pensamiento.

Las Skills y los archivos de instrucciones del proyecto (CLAUDE.md, AGENTS.md) sufren el mismo problema, con un agravante: son globales. Una línea deficiente allí contamina todas las tareas. La recomendación de la guía de Codex es directa: descripciones de skills breves y con un disparador específico ("úsala al revisar un archivo de migración de base de datos, no para consultas generales") en lugar de "úsala siempre que haya algo relacionado con bases de datos". Las skills que se superponen se consolidan; las que vuelcan todo el flujo se convierten en un enrutador con los detalles en un archivo aparte.

Sustraer no significa quedarse sin nada. La regla de la guía de Fable es: una instrucción breve de intención reemplaza la lista de comportamientos. En vez de enumerar "no hagas un PR largo, no comentes línea por línea, no listes opciones que no vas a seguir", se escribe una frase: "Empieza por el resultado; los detalles y la justificación vienen después; para acortar, elimina lo que no cambie la decisión del lector, no lo comprimas en fragmentos." El modelo generaliza.

¿Y qué ocupa el lugar de lo que salió? Permisos explícitos para flujos seguros y repetibles. «Las pruebas locales usan datos descartables y no tocan producción: ejecútalas, corrige lo que haya roto el cambio y vuelve a ejecutarlas sin pedir aprobación en cada paso». Eso es lo contrario de una muleta: en vez de frenar, da libertad dentro de una barrera que tú diseñaste.

Un detalle que cambia la forma de probar: ambas casas dicen que el mismo prompt se comporta de forma diferente en cada nivel de esfuerzo y en cada generación. Entonces, la auditoría no termina con el corte: termina ejecutando el caso real después del corte y comparándolo con el de antes. Restar sin volver a ejecutar es hacer conjeturas.

El día 2, el pilar Reglas respondía «qué no puede hacer la IA». En la nueva generación responde una pregunta más precisa: hasta dónde decide por su cuenta y en qué situación exacta se detiene y te llama. Es el pilar Autoridad. Quedarse corto bloquea el trabajo; excederse genera acciones que nadie pidió.

Los dos modelos nuevos muestran los dos lados del error. Según la guía oficial, Fable «puede realizar ocasionalmente acciones que no se le pidieron»: redactar un correo que nadie pidió, crear una copia de seguridad por precaución, corregir un error cercano que la tarea no mencionaba. Astra hace lo contrario: “respeta tus límites y puedes detenerte aunque preferirías continuar”, en la descripción del equipo de Codex. Una barrera escrita para corregir un modelo desobediente se convierte, en un modelo obediente, en una pausa indeseada.

La solución no es borrar los límites ni multiplicarlos: es redefinir el alcance. La guía de Fable resume en una frase lo que un prompt de 2025 decía en veinte: «Detente para consultar al usuario solo cuando el trabajo realmente lo requiera: una acción destructiva o irreversible, un cambio real de alcance o un dato que solo él tiene. Si te encuentras con uno de esos casos, pregunta y termina el turno, en vez de terminar con una promesa». Son las tres paradas. Todo lo que no sea una de ellas —acciones reversibles que se desprenden del pedido— sigue adelante sin preguntar.

Por el lado de Astra, la instrucción reflejada: “infiere la intención a partir de lo que ya tienes, enumera tus suposiciones al principio y continúa basándote en ellas”. Fíjate en que no dice «nunca preguntes»: eso obliga a adivinar cuando falta una decisión real. Se trata de redirigir la pregunta: en vez de detenerse, el modelo declara lo que asumió y continúa. Tú mantienes la visibilidad sin que el trabajo se trabe. Las guías también sugieren dejar explícito que las acciones de lectura, revisión y las reversibles ya tienen autorización implícita.

Por el lado de Fable, también está el límite contra el exceso de la guía oficial: «Si, al trabajar, encuentras un bug preexistente o un comportamiento que la tarea no menciona, no corrijas ni amplíes en este cambio; repórtalo como pendiente en el resumen. Cuando la tarea sea ambigua, implementa la interpretación que mejor respalde el texto, declara la suposición y no construyas para las otras interpretaciones." Y la distinción que vale oro en operaciones: cuando el usuario está describiendo un problema o pensando en voz alta, el entregable es la evaluación: repórtala y detente; no apliques la corrección antes de que te la pidan.

Hay una segunda razón para escribir las fronteras con cuidado, y es la seguridad. Una lectura de terceros que circuló esta semana lo resume bien: “un prompt representa una intención; un permiso representa una imposición”. Cuanto más potente es el modelo, menos sirve «el prompt dijo que no lo hiciera» como control. Los límites de alto riesgo (deploy, borrar, pagar) también deben existir fuera del texto: en los permisos de la herramienta, el acceso y el entorno. El prompt indica dónde parar; el entorno lo garantiza.

La prueba del pilar Autoridad es sencilla: lee tu lista de reglas y clasifica cada una como detención (una de las tres), permiso (flujo seguro habilitado) o muleta (regla que existe por un modelo antiguo). La primera se queda y obtiene una garantía en el entorno. La segunda se queda y da libertad. La tercera se elimina.

Si el modelo se encarga del «cómo», la parte más valiosa de tu texto pasa a ser la línea de meta. Una guía sobre Astra lo resume así: «el mejor prompt define una línea de llegada: dice qué resultado producir, qué evidencia controla la respuesta, qué puede decidir por su cuenta, cómo se estructura el entregable y qué debe revisarse antes de terminar». Las dos últimas partes — listo e verificación — son lo que distingue un prompt que devuelve trabajo de uno que devuelve una pregunta.

Definición de listo es la prueba que tú lo aplicarías antes de aceptar. No es «un buen informe»; es «los totales coinciden con la hoja de cálculo, variación respecto de la semana anterior, tres elementos con una acción». Escrita así, cumple tres funciones al mismo tiempo: le da al modelo el criterio para saber cuándo detenerse, evita que se detenga demasiado pronto (Astra) o que continúe de más (Fable), y se convierte en la lista de verificación para la validación del día 3 sin trabajo adicional.

Verificación con evidencia aborda un problema que se hizo más visible precisamente porque ahora los modelos funcionan durante horas: el informe de progreso inventado. La guía de Fable incluye la instrucción que, en las pruebas de Anthropic, «prácticamente eliminó» esto: «Antes de informar sobre el progreso, audita cada afirmación comparándola con el resultado de una herramienta de esta sesión. Informa solo del trabajo para el que puedas señalar evidencia; si algo aún no se verificó, dilo explícitamente. Si las pruebas fallaron, dilo junto con el resultado; si se omitió un paso, dilo; cuando algo esté hecho y verificado, afírmalo sin reservas».

Hay un par de trampas nuevas. La primera, del lado de Astra: reconocer que podría hacerlo no significa haberlo hecho. Sin esto por escrito, a veces responde con un plan competente y se detiene. La segunda advertencia, de Fable 5.1: en tareas largas y asíncronas, puede terminar el turno describiendo el siguiente paso («después voy a…») o pidiendo permiso para algo que el pedido ya incluía («¿lo aplico?»). La guía oficial indica cómo cerrar: «Antes de terminar, vuelve a leer tu último párrafo. Si es un plan, una pregunta o una promesa sobre trabajo pendiente, haz ese trabajo ahora». Esto no aplica al trabajo en pareja en vivo: aplica cuando no estás mirando.

Una verificación aún mejor es la que no la realiza quien la produjo. La guía de Fable es explícita: «los verificadores independientes, con contexto limpio, suelen superar a la autocrítica». En trabajos largos, la instrucción es establecer un ritmo: «Define un método para revisar tu propio trabajo cada [intervalo]; ejecútalo y compáralo con la especificación usando subagentes». Si no usas subagentes, el equivalente es el día 3: otra persona u otra sesión ejecuta la lista de verificación.

Junta las piezas y tendrás la estructura que las guías de Astra llaman prompt de seis partes, y que es, en la práctica, nuestra Ficha del día 2 actualizada: Resultado · Fuente de verdad · Restricciones · Autoridad · Contrato de salida · Verificación. «Resultado» evita el análisis sin rumbo; «fuente de verdad» controla la evidencia; «restricciones» delimitan la solución; «autoridad» reduce las pausas innecesarias; «contrato de salida» hace que el resultado sea usable; «verificación» define cuándo está listo.

Una nota sobre las fuentes que sirve para cualquier cosa que use búsquedas: Fable 5.1, con un nivel de esfuerzo bajo, tiende a responder de memoria en vez de buscar. Cuando el tema cambia rápido (los modelos de IA son el ejemplo que da esta misma guía), indica que reconocer un nombre no significa conocer su estado actual y que debe buscar antes de responder. Es una definición de listo para la investigación: estar listo incluye haber verificado.

Cuando el modelo se ocupa del «cómo», te quedan tres botones que todavía controlas y que la generación anterior no tenía de la misma manera: cuánto piensa (nivel de esfuerzo), lo que recuerda entre rondas (memoria en archivo) y cómo te mantiene informado en trabajos que duran horas. Los tres sustituyen un montón de instrucciones antiguas.

El esfuerzo es el control principal. Las dos casas usan la misma escala de cinco niveles —bajo, medio, alto, extra alto y máximo— y dicen lo mismo: es el botón que intercambia inteligencia por latencia y costo. En Fable 5.1, el nivel predeterminado es alto (en Claude Code) o medio (en el chat), y en nivel medio ofrece lo que Fable 5 ofrecía en alto, a menor costo. En nivel bajo, compite en costo con modelos más pequeños y obtiene mejores puntuaciones. La guía indica volver a probar la escala con cada generación: el mismo nombre de nivel no significa la misma cantidad de razonamiento entre modelos. Regla práctica de las guías de Astra: extracción y formato, en nivel bajo; redacción y cambios de rutina, en medio; varios archivos y análisis prolongado, en alto; refactorización amplia, en extra alto; decisiones de arquitectura que vas a ejecutar, en máximo.

El esfuerzo alto tiene un efecto secundario conocido: en tareas rutinarias, Fable «puede recopilar contexto y deliberar más de lo que la tarea necesita» y sentirse tentada a arreglar lo que nadie pidió. La frase de la guía que controla esto reemplaza diez reglas: “No agregues funcionalidades, refactorices ni introduzcas abstracciones más allá de lo que exige la tarea. Haz lo más simple que funcione bien.” Si la tarea termina, pero tarda demasiado, baja el nivel de esfuerzo antes de modificar el prompt.

Memoria se convierte en un archivo — y el modelo escribe en él. El pilar Memoria del día 2 era lo que guardabas para que la IA lo leyera. Ahora Fable «se desempeña especialmente bien cuando puede registrar lecciones de rondas anteriores y consultarlas». La instrucción oficial cabe en tres líneas: «Guarda una lección por archivo con un resumen de una línea al principio. Registra correcciones y enfoques confirmados, incluido por qué fueron importantes. No guardes lo que ya registran el repositorio o el historial; actualiza la nota existente en vez de duplicarla; elimina las notas que resulten ser incorrectas». Y para empezar: «Reflexiona sobre nuestras sesiones anteriores, identifica temas y lecciones y guárdalos en [carpeta]». Es el plan de mejora continua del día 3, solo que quien escribe el registro es el sistema.

El trabajo largo requiere ritmo, no vigilancia. Fable 5.1 escribe menos actualizaciones durante las ejecuciones largas que Fable 5: el usuario ve al agente desaparecer durante minutos. La guía indica primero borrar las líneas antiguas que suprimían la narración («guárdalo todo para la respuesta final») y solo entonces pedir: «Antes de empezar, di en una línea qué vas a hacer; da actualizaciones breves mientras trabajas; termina con un resumen que se sostenga por sí solo». Para los agentes que funcionan sin supervisión, también existe la herramienta de «enviar al usuario», que entrega un mensaje intacto a mitad de la ejecución; pero el modelo rara vez la usa si el prompt no se lo indica.

Delegar se volvió la norma. Fable envía subagentes en paralelo con más facilidad que las versiones anteriores; la guía recomienda usarlos con frecuencia, indicar cuándo conviene delegar y preferir la comunicación asíncrona: el orquestador sigue trabajando mientras ellos se ejecutan e interviene si alguno se desvía. Para ti, que quizá no configures ningún agente, la lección es la misma que el día 3: divide el sistema en etapas que puedan ejecutarse en paralelo y separa quién produce de quién verifica.

Por último, el dinero. La 5.1 redujo el precio de lectura de caché, y eso es lo que hace que el trabajo largo cueste hasta un 45% menos. Consecuencia práctica mencionada en la propia guía: compactar el historial temprano para ahorrar "puede que ya no sea la mejor opción"; prueba compactarlo más tarde. Y el viejo consejo del curso sigue vigente: el esfuerzo adecuado para la tarea es el mínimo que cumple con la definición de terminado. Ejecútala en dos niveles y compara con lo que se considera terminado; eso dice más sobre tu caso que cualquier benchmark.

Terminaste el día 3 con una Ficha del Sistema ejecutada y validada. Hoy no la vas a tirar a la basura: va migrar. Cada pilar de la Ficha v1 tiene un lugar en la Ficha de Intención v2, y la migración es precisamente el ejercicio que muestra qué era una muleta, qué era un límite y qué faltaba. Al final, ejecutas el mismo caso real en ambos formatos y los comparas: esa comparación demuestra que entendiste el cambio.

Paso 1 — Audita por sustracción. Toma la Ficha v1 y el prompt/documento que ejecuta el sistema. Línea por línea, pregúntate: «¿el modelo de hoy todavía necesita esto?». Marca muletilla, límite o permiso. Borra las muletillas. Anota cuántas líneas eliminaste: esa es tu cifra de deuda pagada.

Paso 2 — Reescribe Contexto como fuente de verdad. Del contexto del día 2, separa lo que es autoritativo (el catálogo, la tabla de plazos, la política) en lugar de limitarte a describirlos. Di qué fuente prevalece si hay un conflicto y qué hacer cuando falten datos: señalar la discrepancia, no inventar.

Paso 3 — Convierte las Reglas en autoridad. Escribe qué decide el sistema por sí solo, las tres pausas con ejemplos de tu caso y los límites fijos que quedaron. Para cada pausa de alto riesgo, anota dónde se garantiza fuera del texto (acceso, permiso, entorno).

Paso 4 — Escribe Listo y Verificación. Tu checklist de validación del día 3 se convierte en la definición de listo: la prueba que aplicas antes de aceptar. Añade el requisito de evidencia ("reporta solo lo que puedas señalar; si no lo verificaste, di que no lo verificaste") y separa quién verifica de quién produce.

Paso 5 — Ajusta el esfuerzo e instala la carpeta de lecciones. Elige el nivel de esfuerzo según el tipo de caso (rutina en medio, interrupción en alto, por ejemplo). Crea la carpeta de aprendizajes con la regla de entrada, actualización y descarte, y agrega el primer fallo corregido el día 3.

Paso 6 — Ejecuta el mismo caso con los dos formatos y compáralos. Toma el caso real del día 3. Ejecútalo con la Ficha v1 y con la v2, de preferencia con el mismo modelo y, si puedes, con dos modelos (uno de Anthropic y otro de OpenAI). Anota: ¿preguntó o hizo? ¿Se detuvo donde debía? ¿Pasó la prueba de Listo? ¿Cuántas líneas de instrucciones usó? Esta tabla comparativa, junto con la Ficha v2 completada, es tu entrega del día 4.