Opus 4.7 Parece Haber Roto Tus Prompts. No Es Así. Solo Te Perdiste las 2 Reescrituras Que Importan.

Cada vez que sale un nuevo LLM, me leo el changelog. (Soy de los que se lee el manual de una desbrozadora nueva. 🤓) Así fue como me di cuenta de que algo no cuadraba con el pánico por Opus 4.7.

TLDR. Si acabas de actualizar a 4.7, dos patrones en tus prompts actuales van a fallar. Te voy a mostrar lo que arreglé en mi producción y cómo adaptarlo a tu configuración. Todo lo demás que te están contando sobre "auditar todos tus prompts" es ruido sacado de los mismos cuatro puntos.

La documentación de Anthropic dice una línea que nadie está repitiendo: los prompts escritos para 4.6 funcionan muy bien en 4.7 tal como están. El mismo documento también dice, explícitamente, dónde no funcionan. En dos lugares específicos. No dieciséis. No ocho. Voy a nombrarlos, explicar por qué 4.7 los activa, y mostrarte cómo parchear tu CLAUDE.md y prompts de sistema en dos líneas.

Leo Manuales. Por Eso Sabía Que el Tweet Estaba Mal.

16 de abril. Sale Opus 4.7. En dos horas, mi feed se llena de lo de siempre: "Todo cambió", "Necesitas auditar todos tus prompts", "El nuevo modelo es una bestia diferente". A la tercera hora, empiezan a llegar las guías de migración. Una avalancha esa semana. Todas copiando los mismos cuatro puntos de la documentación de Anthropic, reformulados para el tono de cada casa.

Mientras esto pasaba, yo estaba en el sitio de documentación. No en Twitter. (Admítelo, tú también revisaste Twitter primero.)

Tres páginas importan: la guía de migración, la página de "qué hay de nuevo", y la página de mejores prácticas de prompting. Léelas en ese orden. La primera te dice qué cambió en el comportamiento. La segunda te da el changelog real, tokenizer incluido. La tercera esconde la línea que deshace el 90% del pánico. Una oración, enterrada en las mejores prácticas de prompting, que básicamente dice que 4.7 funciona bien tal como está con los prompts existentes de 4.6.

Esto no es "algunos prompts están bien". Esto no es "puede que no necesites reescribir si tienes suerte". Esto es el fabricante del modelo diciéndote que la suposición por defecto es: tus prompts antiguos funcionan. Las guías de migración que estás leyendo están escritas desde la suposición opuesta. Y la brecha entre esas dos posiciones es donde vive todo el mal consejo.

Así que la pregunta se vuelve la correcta. No "¿qué reescribo?". La correcta es: ¿dónde exactamente 4.7 deja de comportarse como 4.6, y por qué? La documentación responde esto. En dos lugares.

El Mecanismo: 4.6 Te Estaba Cubriendo las Espaldas

4.6 no era un generador de texto tonto. Era uno cooperativo. Cuando escribías un prompt que técnicamente estaba incompleto, 4.6 silenciosamente llenaba los huecos por ti. Dos tipos de huecos, específicamente.

Primer tipo: llamadas a herramientas implícitas. Escribías "revisa la estructura del proyecto antes de sugerir cambios" en tu CLAUDE.md. 4.6 metería una llamada Glob o Read antes de responder, aunque tu instrucción técnicamente no lo exigiera. La palabra "revisa" podría significar "realmente invoca una herramienta" o "considera mentalmente". 4.6 elegía la primera interpretación. La mayoría de las veces.

Segundo tipo: alcance y excepciones implícitas. Escribías "advierte al cliente sobre retrasos de restock una vez por conversación". 4.6 entendía "una vez, pero reabre si aparece un pedido genuinamente nuevo en la sesión". Escribías "nunca uses signos de exclamación". 4.6 lo aplicaba a la prosa generada, pero no a bloques de código o contenido de reseñas citadas, porque quitar puntuación de reseñas verbatim sería absurdo. ¿Quién edita una reseña de cinco estrellas? 4.6 infería el límite por su cuenta.

4.7 no hace ninguna de las dos cosas. Lee tu instrucción literalmente. Si no dijiste "DEBES llamar la herramienta", lee "revisa" como "considera". Si escribiste "una vez por conversación" sin lista de excepciones, aplica "una vez" y sigue adelante, pedido nuevo o no.

Anthropic documenta esto en la guía de migración sin endulzar: el modelo no va a extender silenciosamente una regla de un caso a uno similar, y no va a adivinar peticiones que realmente no hiciste. Ese es el cambio. Ese es todo el cambio. El resto (razonamiento más rápido, menos llamadas por defecto a herramientas, tono más directo) todo fluye de este cambio de postura.

Lo que significa que tus prompts no se rompieron. Siempre estuvieron incompletos. 4.6 estaba parcheando los huecos sobre la marcha, y 4.7 deja de parchear.

Otros análisis corroboran el mecanismo desde diferentes ángulos. Un análisis profundo nota que los prompts débiles tapados por 4.6 ahora salen a la superficie como huecos visibles. Misma conclusión, diferente enfoque. La parte útil es que hay exactamente dos lugares donde los huecos importan lo suficiente como para reescribir.

Reescritura #1: Llamadas a Herramientas Que Eran Sugerencias

Ve y abre tu CLAUDE.md ahora mismo. Te espero.

Escanéalo buscando verbos que suenan accionables pero no son vinculantes. "Revisa". "Considera". "Mira". "Examina". Cada uno de esos es una sugerencia desde el punto de vista de 4.7. Si la acción es crítica, es decir, el siguiente paso realmente depende de la salida de la herramienta, acabas de introducir un modo de falla silencioso.

Ejemplo concreto de mi propio CLAUDE.md, limpiado para que se lea genéricamente. Tenía una regla que decía "antes de sugerir cambios de código, revisa la estructura actual del proyecto". En 4.6, esto producía una llamada Glob cada vez. Claude listaría archivos, vería qué había ahí, luego propondría cambios basados en el estado real. En 4.7, misma regla, mismo prompt, sin Glob. Claude propondría cambios desde la memoria. A veces correcto. A veces completamente desincronizado con el repo, porque el contexto de la sesión estaba obsoleto y el verbo "revisa" no forzaba una llamada a herramienta.

No es un bug. Es literalismo. "Revisa" puede significar "invoca una herramienta" o "piénsalo". 4.7 por defecto va a "piénsalo". La solución toma dos líneas.

Reemplaza la instrucción suave con una dura. En lugar de:

Antes de sugerir cambios, revisa la estructura actual del proyecto.

Escribe:

Antes de cualquier sugerencia de código, DEBES llamar Glob para listar la estructura actual del proyecto. 
No te bases en contexto previo de la sesión para la estructura de archivos.

Tres diferencias. "DEBES" en lugar de verbo suave. Herramienta nombrada en lugar de acción genérica. Negación explícita del comportamiento de respaldo, que cierra la laguna.

Esto aplica en todos lados donde una llamada a herramienta es crítica. ¿Tu agente consulta una API externa antes de decidir? Nombra la llamada a la API. ¿Tu bot de soporte lee el feed CSV diario del distribuidor? Nombra la lectura de archivo. ¿Tu asistente de WooCommerce consulta registros de usuario antes de responder? Nombra la herramienta de base de datos. Cada vez que los datos tienen que venir de una llamada en vivo, la llamada debe ser no-opcional en el texto del prompt, no en la cabeza de la persona que lo escribió.

Advertencia que vale la pena distribuir aquí, no al final: esta solución solo importa cuando la llamada a herramienta es crítica. Si realmente no te importa si Claude invoca la herramienta o adivina desde el contexto, déjalo así. Algunas revisiones son genuinamente opcionales. Haz que sea una elección consciente, no ciega.

Principio más amplio: herramienta llamada vence a razonamiento inferido. Si quieres profundizar en esto, escribí por qué los CLIs vencen a MCP para llamadas críticas a herramientas hace unos meses. El argumento se sostiene más fuerte bajo 4.7.

Dos líneas. Primera solución hecha.

Reescritura #2: La Que Todos Entienden Exactamente al Revés

Aquí tienes una falla concreta de mi producción, la semana pasada.

Ejecuto un generador de descripciones de productos. Regla antigua, funcionando limpiamente por meses: "nunca uses signos de exclamación". En 4.6, esto aplicaba a la prosa generada, y obviamente no a las reseñas de clientes citadas debajo de cada producto. Porque ¿quién edita una reseña de cinco estrellas? El modelo lo sabía. El límite era implícito pero real.

Actualizo a 4.7. Misma regla. Siguiente lote de páginas de productos, mis bloques de reseñas citadas empiezan a perder signos de exclamación. Citas de clientes que originalmente decían "¡¡¡La mejor oferta de este verano!!!" ahora leen "La mejor oferta de este verano". Aplanadas. Lo cual es un pequeño problema de calidad para páginas de productos, y un problema real si estás ejecutando reseñas verbatim por razones legales o de confianza. La fuente ya no coincide con la cita.

No es que el modelo sea "peor". El modelo siendo exactamente lo que pedí. Escribí "nunca uses signos de exclamación". 4.7 leyó eso como "nunca, en ningún lado, punto". Bien en intención, roto en salida.

Solución: escribe el alcance.

Nunca uses signos de exclamación en ningún lado de la prosa generada del producto. 
Esta regla no aplica dentro de reseñas de clientes citadas verbatim 
de fuentes externas.

Cuatro líneas en lugar de una. Cero ambigüedad. El NUNCA se volvió más fuerte, no más débil. Lo que hice fue dejar de pedirle al modelo que dibujara el límite por mí.

Mismo pipeline. Regla diferente. Esta fue más costosa antes de que la atrapara.

"Confirma la política de envío una vez por conversación." En 4.6, el modelo entendía "una vez bajo flujo normal, pero reconfirma si se introduce un nuevo pedido, o si el cliente cambia de envío doméstico a internacional a mitad de sesión". La excepción implícita siempre estuvo ahí. Nunca escrita. Siempre inferida.

En 4.7: una vez. Punto. Quince mensajes después, el cliente trae un pedido completamente nuevo a un país diferente. Sin reconfirmación de la política. Porque la instrucción dijo "una vez" y el modelo hizo "una vez".

Solución: nombra las excepciones.

Confirma la política de envío una vez por conversación bajo flujo normal. 
Reconfirma cuando: (a) se introduce un nuevo pedido, (b) el 
destino cambia (doméstico a internacional o viceversa), 
(c) el cliente explícitamente pregunta sobre términos de envío otra vez.

Ahora el alcance es explícito y las excepciones están listadas. No se requiere inferencia.

Y aquí es donde el consejo que te están dando está exactamente al revés. Cada guía de migración en tu feed te está diciendo que "suavices tus reglas NUNCA ahora que 4.7 sigue instrucciones mejor". Eso es lo contrario de lo que quieres hacer.

Tus reglas NUNCA están bien. Solo se volvieron más afiladas. Lo que se rompió son las reglas que dependían de que el modelo infiriera el alcance o las excepciones que no te molestaste en escribir. Tus absolutos están haciendo su trabajo. El problema son tus "una vez", tus "siempre", tus "usualmente". Esas son las reglas que se apoyaban en la cooperación silenciosa de 4.6.

Si quieres el framework completo para escribir prompts que no se apoyen en la cooperación del modelo en primer lugar, puse todo en el enfoque de contratos de prompts que construí después de seis meses de exactamente estos desastres. 4.7 hace ese framework más relevante, no menos.

Tus reglas NUNCA se volvieron más afiladas. Tus reglas "una vez" y "siempre" se volvieron estúpidas. Arregla las últimas, no toques las primeras.

Qué Se Queda, y la Regla a Recordar

Ahora las buenas noticias. La mayoría de tu prompt no se mueve.

Las prohibiciones duras mejoran bajo 4.7. Sin rayas largas, sin tablas, sin aperturas prohibidas, sin fórmulas vacías: todo funciona más ajustado, no más suelto, porque el modelo deja de tratarlas como sugerencias de estilo y empieza a tratarlas como reglas. El tono directo que solías parchear con instrucciones explícitas se alinea con la voz por defecto de 4.7. Tus prompts de sistema largos siguen funcionando a través del contexto. Tu markdown se renderiza exactamente igual. Tus definiciones de herramientas, tus personas, tus especificaciones de formato de salida, tus reglas de contenido: el 90% de un prompt 4.6 bien escrito se queda intacto.

La superficie de reescritura es estrecha. Dos preguntas, en orden.

Primero, ¿dónde depende mi prompt de una llamada a herramienta que no exigí explícitamente? Encuentra esas. Haz la llamada obligatoria. Nombra la herramienta. Cierra el respaldo.

Segundo, ¿dónde depende mi prompt de que el modelo adivine el alcance o las excepciones? Encuentra esas. Escribe el alcance. Lista las excepciones.

Eso es todo. No diecisiete puntos de verificación. Dos preguntas.

A Karen de Contabilidad le encantarían diecisiete puntos de verificación, porque podría hacer una hoja de cálculo. Tú no necesitas una hoja de cálculo. Necesitas hacer grep en tus prompts buscando verbos suaves y reglas con límites implícitos. Diez minutos de grep. Una hora de reescritura. Listo.

¿Recuerdas RTFM? 😬 (Relájate, estoy aquí para ti.)

Fuentes

• Guía de migración de la API de Claude: los cambios de comportamiento, explicados por Anthropic sin adornos.
• Qué hay de nuevo en Claude Opus 4.7: el changelog completo, tokenizer incluido.
• Mejores prácticas de prompting: la línea sobre prompts 4.6 funcionando en 4.7 tal como están está ahí.

(*) La portada es generada por IA. Mis habilidades de ilustración alcanzaron su pico en tercer grado.