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 a "pensar superficialmente" (incapacidad de pensar de forma estructurada).

Al investigar, no era que el modelo fuera malo o que las reglas estuvieran rotas; más bien, el prompt interno del sistema que se le proporciona a Opus 5 en la generación 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 efectividad 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 texto plano y extenso en prosa, sin encabezados ni secciones.
• Las explicaciones de las causas se detenían en una sola capa (enumeraban los 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 la ejecución de herramientas (tareas).

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

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

Pistas clave

Esto no ocurría con otros modelos que usaban las mismas reglas (los detalles sobre esta diferencia están en el apéndice). Si las reglas en sí 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 (deshabilitando las inyecciones de estilo de salida y haciendo que el modelo cite 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 Harness (# 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 corrección (# Corrections) — Mantener las correcciones concisas sin agregar disculpas ni preámbulos.

Surgieron dos características específicas directamente relacionadas con los síntomas:

• 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 desaparecieron por completo.
• Característica 2: Se agregó 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 elección, da una recomendación, no un estudio exhaustivo".

Releer los síntomas a través de estas dos características hace que todo encaje. Como no hay reglas de estilo, la tendencia de salida cruda del modelo —prosa plana— se manifiesta. La política de "recomendación sobre estudio" fomenta la omisión de criterios de evaluación.

Podrías pensar: "Si las reglas están en blanco, ¿no deberían mis reglas personalizadas 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 incorporado 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 llenado 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 "desglosar las situaciones de forma estructurada", "agregar criterios de evaluación a múltiples opciones" y "responder antes de actuar". Estas fueron escritas asumiendo que se leerían junto con un prompt del sistema cargado de estilo. Aunque eran suficientes en ese 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 se redujo 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 Cómo hacer prompts para 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 la prioridad.

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

Cuando se colocan junto a la política del sistema de "da una recomendación, no un estudio exhaustivo", no hay indicio de cuál tiene prioridad. Al nombrar el conflicto, la prioridad se vuelve 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 de esa manera. Cambié los activadores a hechos observables como "recibió una interrupción" o "la expresión del usuario contiene una corrección".

Medida 2: Describir 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: "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 cuerpo del texto 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 activador 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 solo 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 rutas para entregar instrucciones al modelo, y difieren significativamente en efectividad.

Dado que la API no tiene estado, el contenido de todas las rutas 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á tomando".

Sorprendentemente, output style —que según la documentación "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, agregar criterios) y Proceso (responder al usuario antes de comenzar a trabajar). Los resultados fueron mixtos.

Mientras que las instrucciones de Estilo mostraron mejoría, el problema de Proceso (saltarse las 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 acuse de recibo y plan) en el cuerpo del texto 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 tienen mal contenido; simplemente no están a mano en el momento de la acción.

Resultados

Estos son los resultados confirmados hasta ahora:

• Una tendencia de que los encabezados/secciones vuelvan a aparecer en explicaciones situacionales y causales. (Sin embargo, a veces la salida plana permanece al principio de la sesión; se requiere observación continua).
• El hábito de "trabajar sin responder" no se solucionó 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 agregar más reglas.
• Las reglas que compiten con las políticas del sistema deben nombrar el texto original y declarar la prioridad. Las adiciones generales pierden frente a la contradicción.
• Escribe los activadores basados en la observación y describe las acciones deseadas en lugar de prohibiciones. Los activadores de autocategorización y las listas de prohibiciones son propensos a fallar cuando los modelos cambian.
• Elige la capa correcta para las instrucciones. Las inyecciones entregadas de forma breve y frecuente justo antes de una acción fueron mucho más confiables que las reglas grandes 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; 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 cortos enumerables" /
6"No hagas que el lector tenga que hacer referencias cruzadas de etiquetas o numeraciones que inventaste anteriormente" /
7"Si estás sopesando una elecció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 oración en prosa.
15
16- Resume primero los pensamientos, luego estructura al final. No coloques una plantilla primero y la rellenes después.
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 primero la recomendación y su razonamiento, 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 se necesita investigar para completar los criterios. Las comparaciones de criterios pueden escribirse en tablas.
19- Una vez que se establezcan categorías y números, usa los mismos en turnos posteriores mientras continúes con la misma tarea. Si los cambias, escribe primero qué se cambió.
20
21## Diálogo y proceso
22
23- La afirmación del sistema "el usuario no está mirando en tiempo real" es un valor predeterminado, no un hecho. Si se recibe una expresión intermedia, interrupción o 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 cuerpo del texto, y detente para esperar una respuesta en los turnos donde se hace una pregunta.
24- Solo el cuerpo del texto al final de un turno se muestra en este entorno. Coloca toda la información que se debe 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á por qué 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 y heredado para el que fueron diseñadas las reglas heredadas. Permanece en sintonía 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 headless, output style deshabilitado):

La sección # Communicating with the user de Fable 5 incluye normas como "conclusión primero, priorizar la legibilidad, escribir 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 en sí mismo contiene estas normas de escritura, es menos probable que el formato de salida 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 las tendencias de salida crudas.
2. Políticas como "actuar 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.