Soluciones para el problema de pensamiento superficial en Claude Opus 5

Resumen

Inmediatamente después de cambiar Claude Code a Opus 5, noté un aumento repentino en respuestas con mucho texto en prosa y una tendencia al "pensamiento superficial" (incapacidad para pensar de manera estructural).

Tras investigar, no era que el modelo fuera malo o que las reglas estuvieran rotas; más bien, el prompt interno del sistema proporcionado a Opus 5 en la generación de Claude 5 ha cambiado significativamente, y las reglas heredadas no fueron escritas teniendo en cuenta esta nueva premisa.

Este artículo documenta el proceso de aislar la causa y revisar las reglas para adaptarlas al nuevo prompt del sistema. Está dirigido a usuarios de Claude Code que sientan que la eficacia de CLAUDE.md o sus reglas ha cambiado desde que actualizaron a la nueva generación de modelos.

El problema

Usando la misma sesión y las mismas reglas, ocurrió lo siguiente inmediatamente después de cambiar el modelo a Opus 5:

• Las explicaciones situacionales se volvieron planas, en prosa larga sin encabezados ni secciones.
• Las explicaciones de las causas se detenían en una sola capa (enumerando síntomas en paralelo sin profundizar en el "por qué").
• No se proporcionaban criterios de evaluación al sugerir múltiples opciones.
• Las categorías o numeraciones establecidas en un turno se reorganizaban en estructuras diferentes en el siguiente.
• El modelo omitía responder a mi entrada y saltaba directamente a ejecutar herramientas (tareas).

Lo frustrante era que incluso cuando se le pedía que "pensara más profundamente", devolvía respuestas esporádicas mientras se mantenía en un estado de pensamiento superficial. Las correcciones repetidas no calaban, dando lugar a discusiones en lugar de un diálogo productivo.

No era solo una cuestión de calidad de respuesta individual; el proceso de deliberación a través del diálogo se había roto.

Claves de la investigación

Esto no ocurría con otros modelos usando las mismas reglas (los detalles sobre esta diferencia están en el apéndice). Si las reglas mismas se hubieran deteriorado, el problema debería haber aparecido en todos los modelos. Como solo cambió el modelo, comencé a investigar bajo la suposición de que el "entorno que asumen las reglas" había cambiado.

Causa: Cambios en el prompt del sistema proporcionado a Opus 5

En la generación Claude 5 de Claude Code, el prompt interno del sistema se ha reducido aproximadamente en un 80% en comparación con generaciones anteriores. Al medir el prompt realmente entregado a Opus 5 (desactivando las inyecciones de estilo de salida y pidiendo al modelo que citara su propio prompt; serie Claude Code v2.1, julio de 2026), la estructura era la siguiente:

1. Identidad, declaración de rol y política de seguridad — El preámbulo inicial.
2. Especificaciones del arnés (# Harness) — Explicaciones del entorno de ejecución, como que la salida se muestra como markdown.
3. Información del entorno y descripciones de funciones (# Session-specific guidance / # Memory / # Environment / # Context management) — CWD, estado de git, ID del modelo, memoria y mecanismos de compresión de contexto.
4. Disciplina de alcance (# Delivering work) — No reducir ni ampliar el alcance solicitado sin permiso.
5. Etiqueta de correcciones (# Corrections) — Mantener las correcciones concisas sin añadir disculpas ni preámbulos.

Dos características específicas directamente vinculadas a los síntomas emergieron:

• Característica 1: Cero instrucciones sobre el estilo de respuesta. No había reglas sobre prosa vs. estructura, uso de encabezados o tablas, o concisión — las reglas de formato que eran extensas en generaciones anteriores habían desaparecido por completo.
• Característica 2: Se añadió una política autónoma de "Actuar primero". Para citar el original: "Cuando tengas suficiente información para actuar, actúa" y "Si estás sopesando una opción, da una recomendación, no un estudio exhaustivo."

Releer los síntomas a través de estas dos características lo aclara todo. Como no hay reglas de estilo, la tendencia natural de salida del modelo —prosa plana— sale a la luz. La política de "recomendación sobre estudio" fomenta la omisión de criterios de evaluación.

Quizás pienses: "Si las reglas están en blanco, mis reglas personalizadas deberían convertirse en la única autoridad y funcionar mejor." En realidad, ocurrió lo contrario. Este espacio en blanco no es un margen dejado para el usuario; está delegado al comportamiento predeterminado grabado en el modelo durante el entrenamiento. El "prompt ligero" asume que los modelos de nueva generación siguen comportamientos internalizados sin instrucciones detalladas. En lugar de ser llenado por tus reglas, el vacío es ocupado por los valores predeterminados preentrenados del modelo. Y el valor predeterminado de Opus 5 es una prosa concisa que actúa antes de confirmar.

Mis reglas antiguas usaban instrucciones generales como "desglosa las situaciones de forma estructural", "añade criterios de evaluación a las opciones múltiples" y "responde antes de actuar". Estas fueron escritas asumiendo que se leerían junto con un prompt del sistema cargado de estilo. Aunque eran suficientes entonces, eran demasiado débiles tanto en especificidad (nombrar el texto original) como en entrega (llegar al modelo justo antes de la acción) para anular los valores predeterminados entrenados. Esta es la verdadera naturaleza de los síntomas.

La propia Anthropic se refiere a esta reducción como un "prompt del sistema ligero" en el registro de cambios (v2.1.154), reflejando un cambio en la filosofía de diseño: "Los modelos de nueva generación han internalizado comportamientos a través del entrenamiento, por lo que las instrucciones detalladas pueden causar fricción o contradicción." Para explicaciones detalladas, consulta El prompt del sistema de Claude Code reducido en un 80% — Filosofía de diseño de prompts para la generación Fable 5. Para fuentes primarias, consulta el registro de cambios de Claude Code y Prompting Claude Fable 5 (Guía oficial).

En resumen, los síntomas están determinados por la combinación de "reglas × el prompt realmente entregado a ese modelo". No puedes encontrar la causa mirando solo las reglas. La primera lección fue que una actualización del modelo también es una actualización del prompt del sistema.

Medida 1: Identificar contradicciones y anular nombrando el texto original

Primero, cotejé todas las reglas con el nuevo prompt del sistema para identificar dónde decían lo contrario. Para las reglas destinadas a anular la política del sistema, las reescribí para citar explícitamente el texto original y declarar prioridad.

Para empezar con lo que no funcionó: añadir generalidades como "escribe múltiples opciones con criterios de evaluación" es ineficaz.

Cuando se coloca junto a la política del sistema de "da una recomendación, no un estudio exhaustivo", no hay ninguna pista sobre cuál tiene prioridad. Al nombrar el conflicto, la prioridad queda clara.

Para cosas completamente ausentes del prompt, como las reglas de estilo, la instrucción funciona para "llenar el vacío" en lugar de anular.

También revisé cómo se escriben las condiciones de activación. Condiciones como "para cambios importantes" o "si se considera un entorno de producción" fallan en el momento en que el modelo no categoriza la situación así. Cambié los desencadenantes a hechos observables como "recibió una interrupción" o "la expresión del usuario contiene una corrección."

Medida 2: Describir las acciones deseadas en lugar de prohibiciones

Las reglas antiguas eran una acumulación de "no hacer". Las prohibiciones ayudan a detectar infracciones, pero no transmiten qué hacer en su lugar. Cuando una prohibición entra en conflicto con una nueva política del sistema, el modelo encuentra un vacío legal: "seguir la política del sistema mientras se evita la prohibición". Convertí las restricciones negativas en descripciones del comportamiento deseado.

• Antes: "No sugieras un commit si las pruebas están incompletas."
• Después: "Al sugerir un commit, incluye en el texto del cuerpo los resultados de ejecutar el producto desde la perspectiva del usuario final."

Verifiqué las reglas reescritas con los siguientes criterios, especialmente para expresiones que chocan con el Prompt del Sistema:

1. ¿La regla es autónoma? (Alcance, ejemplos y criterios en un solo lugar)
2. ¿El desencadenante es un hecho observable?
3. ¿Contradice el prompt interno del sistema?
4. ¿Describe el comportamiento deseado? (No solo una lista de prohibiciones)
5. ¿Hay un único criterio para juzgar? (No una lista de escenarios)
6. ¿El énfasis (IMPORTANTE) se reserva solo para lo que realmente no se puede omitir?
7. ¿Está escrito como el estado final deseado? (No forzando plantillas o pasos primero)
8. ¿Se puede determinar el cumplimiento después del hecho?

Reduje los marcadores de énfasis (IMPORTANTE) solo a las puertas de seguridad y aprobación. Un documento donde todo está enfatizado es lo mismo que un documento donde nada lo está.

Medida 3: Elegir la "capa" para entregar las instrucciones

No se trataba solo del texto. Claude Code tiene al menos cuatro vías para entregar instrucciones al modelo, y difieren significativamente en efectividad.

Dado que la API no tiene estado, el contenido de todas las vías se envía al modelo con cada solicitud (cada turno). La diferencia radica en "cuándo se finaliza el contenido" y "dónde se coloca en el prompt = qué tan cerca está de la acción que se está realizando."

Sorprendentemente, output style —que la documentación dice que "reemplaza el prompt del sistema"— se entregó como un adjunto en cada turno según los registros de sesión.

Escribí dos tipos de instrucciones en este output style: Estilo (Medida 1: escribir de forma estructurada, añadir criterios) y Proceso (responder al usuario antes de comenzar el trabajo). Los resultados fueron mixtos.

Mientras que las instrucciones de Estilo mostraron mejoría, el problema de Proceso —omitir respuestas para comenzar a trabajar— no se detuvo mediante output style. Finalmente detuve este hábito usando un hook UserPromptSubmit para inyectar una sola línea inmediatamente después de cada expresión del usuario: "Escribe una respuesta a esta expresión (respuesta, o reconocimiento y plan) en el texto del cuerpo antes de ejecutar herramientas."

El costo es de aproximadamente 50 tokens por expresión. Incluso 100 expresiones solo cuestan 5.000 tokens, lo cual es insignificante frente a un contexto de 200K. La regla general que aprendí es simple: Las instrucciones entregadas "brevemente, cada vez, justo antes de la acción" son las más efectivas. Muchas instrucciones ineficaces no son malas en contenido; simplemente no están a mano en el momento de la acción.

Resultados

Estos son los resultados confirmados hasta ahora:

• Una tendencia a que los encabezados/secciones vuelvan a aparecer en explicaciones situacionales y causales. (Sin embargo, la salida plana a veces permanece al principio de la sesión; se requiere observación continua).
• El hábito de "trabajar sin responder" no se corrigió solo con output style, pero se detuvo después de introducir la inyección por expresión (actualmente observando efectos a largo plazo).

Resumen

• Una actualización del modelo también es una actualización del prompt del sistema. Si las tendencias de respuesta cambian repentinamente, lee los cambios en el lado del sistema antes de añadir más reglas.
• Las reglas que compiten con las políticas del sistema deben nombrar el texto original y declarar prioridad. Las adiciones generales pierden ante la contradicción.
• Escribe los desencadenantes basándote en la observación y describe las acciones deseadas en lugar de prohibiciones. Los desencadenantes de autocategorización y las listas de prohibiciones son propensos a fallar cuando los modelos cambian.
• Elige la capa adecuada para las instrucciones. Las inyecciones entregadas breve y frecuentemente justo antes de una acción fueron mucho más fiables que las grandes reglas colocadas al inicio del contexto.

Referencia 1: Reglas realmente utilizadas en la Medida 1

Aquí hay un extracto de las reglas que uso para anular el prompt del sistema (ajústalas a tu entorno; yo las coloco en output style). Algunas frases originales (como la política de prosa) no existen en el prompt de ciertos modelos (ver apéndice). En esos modelos, funcionan como definiciones para llenar el vacío.

1# Formato de informes y descomposición
2
3Esta instrucción tiene prioridad sobre las siguientes descripciones en el prompt del sistema de Claude Code:
4"una pregunta simple recibe una respuesta directa en prosa, no encabezados y secciones" /
5"Usa tablas solo para hechos enumerables breves" /
6"No hagas que el lector tenga que referirse a etiquetas o numeraciones que inventaste antes" /
7"Si estás sopesando una opción, da una recomendación, no un estudio exhaustivo." /
8"Estás operando de forma autónoma... procede sin preguntar." /
9"El texto que escribas entre llamadas a herramientas puede no mostrarse al usuario."
10
11## Estilo de escritura
12
13Al explicar situaciones, causas o presentar múltiples opciones, escribe de manera que transmitas la estructura del contenido al lector.
14Usa encabezados, viñetas o tablas según corresponda al contenido. Responde preguntas de una frase en prosa.
15
16- Resume los pensamientos primero, luego estructura al final. No coloques una plantilla primero y luego la rellenes.
17- Al explicar causas, rastrea el "por qué" al menos dos niveles de profundidad desde el evento observado y describe a qué se refiere cada nivel. No te detengas en enumerar síntomas en paralelo.
18- Al presentar múltiples opciones, escribe la recomendación y su razonamiento primero, seguido de los criterios que influyen en la decisión y la evaluación de cada opción. Si no se pueden identificar los criterios, no proporciones opciones; en su lugar, escribe lo que necesita investigarse para completar los criterios. Las comparaciones de criterios pueden escribirse en tablas.
19- Una vez establecidas las categorías y los números, usa los mismos en turnos posteriores mientras continúes con la misma tarea. Si los cambias, escribe primero qué se ha cambiado.
20
21## Diálogo y proceso
22
23- El "el usuario no está mirando en tiempo real" del sistema es un valor predeterminado, no un hecho. Si se recibe una expresión intermedia, una interrupción o una corrección aunque sea una vez en esta sesión, trata al usuario como si estuviera mirando a partir de entonces: divide el trabajo en segmentos pequeños, termina siempre cada turno con un informe en el texto del cuerpo, y detente para esperar una respuesta en los turnos donde se plantee una pregunta.
24- Solo el texto del cuerpo al final de un turno se muestra en este entorno. Coloca toda la información a transmitir al final del turno.
25- Las preguntas son un medio legítimo cuando hay ambigüedad, operaciones que requieren aprobación u objetivos poco claros.

Referencia 2: ¿Por qué no ocurrió esto con Fable 5 / Opus 4.7?

Mientras que el texto principal se centró en Opus 5, aquí está la razón por la que no ocurrió con otros modelos:

• Opus 4.7 es simple: está excluido de la aplicación del "prompt ligero" (según el registro de cambios), por lo que todavía se ejecuta con el prompt largo heredado para el que fueron diseñadas las reglas heredadas. Permanece sincronizado con las reglas antiguas.
• Fable 5 fue una sorpresa. Asumí que tenía el mismo prompt ya que es de la misma generación, pero las mediciones mostraron que a Fable 5 se le proporciona un prompt diferente al de Opus 5.

Aquí hay una comparación de cada modelo citando su propio prompt en condiciones idénticas (modo sin cabeza, estilo de salida desactivado):

La sección # Communicating with the user de Fable 5 incluye normas como "conclusión primero, prioriza la legibilidad, escribe para la audiencia". Además de "da una recomendación, no un estudio exhaustivo", incluye la política de prosa "una pregunta simple recibe una respuesta directa en prosa, no encabezados y secciones". Debido a que el prompt mismo contiene estas normas de escritura, es menos probable que el formato de salida se colapse, y en mis observaciones, mantuvo la adherencia a las reglas del usuario.

En resumen, el problema apareció intensamente en Opus 5 porque se alinearon tres factores:

1. Se le dio un prompt con cero reglas de estilo de escritura, exponiendo tendencias de salida brutas.
2. Políticas como "actúa cuando la información sea suficiente" y "recomendación sobre estudio" fomentaban la acción inmediata y la omisión de criterios.
3. Las reglas heredadas todavía se basaban en el prompt antiguo y detallado y no estaban moldeadas para llenar este nuevo vacío.