¿Claude se ha vuelto más tonto? Mídelo, no lo intuyas

TL;DR: Durante marzo y abril de 2026, miles de developers sintieron que Claude Code razonaba peor. Tenían razón, y el postmortem oficial de Anthropic lo confirmó dos meses tarde. La lección práctica no es migrar de herramienta por una corazonada: es montar un eval ligero, un puñado de tareas fijas que ejecutas cada semana, y medir la degradación del modelo con datos en vez de intuición.

El problema: dos meses discutiendo si el modelo había empeorado

Si usas Claude Code a diario, marzo de 2026 fue raro. Tareas que antes salían a la primera empezaron a necesitar tres intentos. El agente leía menos archivos antes de editar, repetía pasos y elegía el arreglo más simple en lugar del correcto. La queja se extendió por Reddit y GitHub durante semanas, y la respuesta inicial de Anthropic fue que su investigación no mostraba problemas generalizados.

El 23/04/2026 llegó el postmortem. Anthropic confirmó tres cambios reales en la capa de producto, no en los pesos del modelo, que combinados degradaron la experiencia:

• El 04/03/2026 bajaron el reasoning effort por defecto de high a medium para reducir latencia. Lo revirtieron el 07/04.
• El 26/03/2026 un bug de caché borraba el historial de razonamiento en cada turno en lugar de una sola vez. Eso explicaba la sensación de olvido y repetición.
• Una restricción de verbosidad redujo el razonamiento sostenido sobre código.

Todo quedó corregido en la versión 2.1.116, publicada el 20/04/2026. El detalle incómodo: durante dos meses, quien pagaba por la herramienta no tenía forma de saber qué estaba cambiando. Solo tenía una corazonada. Es la prueba de que la capa que rodea al modelo pesa tanto como el modelo en sí.

¿Qué es la degradación percibida de un modelo?

La degradación percibida es la sensación de que un modelo responde peor sin que tengas una medida objetiva que lo confirme. Mezcla tres ingredientes y conviene separarlos:

• Cambios reales: como los tres del postmortem de abril.
• Variación de tus propios prompts: el repo crece, el contexto cambia, tus instrucciones no son idénticas entre días.
• Sesgo de expectativa: si esperas un fallo, lo encuentras.

El problema no es la sensación. El problema es decidir en base a ella. Medir lo que no ves de un modelo es la misma lógica que aplicamos al interpretar modelos de IA con herramientas de explicabilidad: sin instrumentación, opinas; con instrumentación, sabes.

¿Qué es un eval ligero (golden prompt)?

Un eval ligero es un conjunto pequeño y fijo de tareas representativas que ejecutas de forma periódica para detectar cambios de comportamiento en un modelo. No es un benchmark académico. Son 5 a 10 tareas de tu trabajo real, repetibles en minutos, con una métrica simple. Su valor está en una sola cosa: te da un punto de comparación entre el Claude de hoy y el de la semana pasada.

Cómo montar tu propio eval en 5 pasos

1. Elige 5-10 tareas representativas de lo que haces de verdad: un refactor típico, un test, un bugfix conocido.
2. Congela el prompt exacto. Sin variaciones. Si cambias la instrucción, cambias el experimento.
3. Registra el entorno: modelo, versión de Claude Code y reasoning effort. Sin esto no hay comparación posible.
4. Define métricas simples: ¿compila?, ¿pasan los tests?, número de iteraciones, archivos leídos por edición.
5. Ejecuta cada semana y guarda el resultado con fecha. La tendencia es la señal, no el dato suelto.

Una forma cómoda de guardarlo es un fichero por tarea. Lo importante es que el entorno quede anotado:

// Plantilla de tarea golden: congela el prompt y registra el entorno en cada ejecucion
{
  "tarea": "refactor-endpoint-pagos",
  "prompt": "Refactoriza el endpoint /pagos extrayendo la validacion a un servicio",
  "modelo": "claude-opus-4-7",
  "claude_code": "2.1.116",
  "reasoning_effort": "high",
  "fecha": "2026-05-22",
  "metricas": { "compila": true, "tests_ok": true, "iteraciones": 2 }
}

Cuando algo huela raro, ejecutas el eval, comparas con la última tirada limpia y tienes una respuesta, no una discusión.

Caso real: los números de AMD y el tic de "vete a dormir"

Stella Laurenzo, directora senior de IA en AMD, hizo justo esto a gran escala. Analizó 6.852 sesiones de Claude Code y más de 230.000 llamadas a herramientas. Los datos eran claros: la lectura de archivos cayó de 6,6 veces a 2 veces por fichero antes de editar, las ediciones puntuales se sustituyeron por reescrituras completas, y el coste mensual del equipo se disparó por los bucles de reintento. Un benchmark comunitario también mostró caídas de precisión, aunque su metodología fue cuestionada después.

No necesitas 6.852 sesiones. Diez tareas fijas bastan para ver una tendencia. La diferencia entre AMD y el resto de la comunidad no fue la intuición, fue tener datos para llevar el problema a un issue de GitHub.

Cuidado con confundir un fallo con una manía. Por las mismas fechas, Claude empezó a decir a la gente que se fuera a dormir a mitad de sesión. Según Sam McAllister, de Anthropic, es un "tic de carácter": el modelo no sabe qué hora es y replica patrones de su entrenamiento sobre el descanso. Eso no es degradación, es una rareza cosmética. Un eval te ayuda precisamente a separar una regresión real de un tic sin importancia.

En Producción

Llevar esta idea al día a día tiene matices que el tutorial se salta:

• Coste: un eval de 10 tareas son unos minutos de cómputo y unos céntimos de API por tirada. Barato comparado con perseguir un fantasma o cambiar de stack.
• Fija la versión: anota modelo, versión de Claude Code y reasoning effort en cada ejecución. El bug de marzo bajó el effort sin avisar; si no lo registras, no lo detectas. Conviene tener claro cuándo subir el effort a max y cuándo no.
• No migres por una corazonada: cambiar de herramienta cuesta tiempo de aprendizaje real. Mide primero, decide después.
• Automatízalo: el eval gana cuando corre solo. Un hook que lance checks automáticos sin tocar tu flujo puede disparar la tirada tras cada actualización.

Errores comunes y depuración

• Error: "lo noto más tonto" pero no puedes demostrarlo. Causa: no tienes baseline. Solución: guarda el resultado de tu eval con fecha y versión desde hoy, aunque ahora todo funcione.
• Error: el eval da resultados distintos cada semana sin que cambie el modelo. Causa: el prompt o el contexto del repo varían entre tiradas. Solución: congela el prompt y usa un repo de prueba estable.
• Error: el modelo "olvida" a mitad de sesión. Causa: puede ser gestión de contexto, no el modelo, como el bug de caché de marzo. Solución: revisa tu capa de memoria y contexto en Claude Code antes de culpar al modelo.

Preguntas frecuentes

¿Anthropic degrada los modelos a propósito?

No. En el postmortem de abril de 2026, Anthropic negó el "nerfeo" y atribuyó la caída a tres cambios en la capa de producto y un bug de caché, no a los pesos del modelo. Los problemas se corrigieron en la versión 2.1.116.

¿Por qué Claude me dice que me vaya a dormir?

Es un "tic de carácter" según Anthropic, no una señal de degradación. El modelo no recibe la hora real y replica patrones de su entrenamiento sobre el descanso. La propia empresa dice estar trabajando en suavizarlo en futuros modelos.

¿Cuántas tareas necesito en un eval ligero?

Entre 5 y 10 tareas representativas bastan para detectar una tendencia. Más tareas dan más señal, pero cuestan más tiempo y más API. Empieza pequeño y amplía solo si una tarea concreta te da dudas.

La diferencia entre tener razón a tiempo y tenerla tarde

Hemos visto que la sensación de que Claude empeora mezcla cambios reales, variación de tus prompts y sesgo de expectativa, y que el postmortem de abril dio la razón a quien se quejaba, pero con dos meses de retraso. La diferencia entre tener razón a tiempo y tenerla tarde es un eval ligero: diez tareas fijas, una métrica simple y la versión anotada. Con eso dejas de discutir por intuición y empiezas a decidir con datos.

El siguiente paso natural es convertir ese eval en un check automático que corra en cada actualización de Claude Code, para enterarte de una regresión el mismo día y no seis semanas después. ¿Tienes ya un eval propio para tus herramientas de IA? Cuéntame cómo lo mides en los comentarios o en Twitter @sergiomarquezp_.