Cancelé Claude: medí el deterioro de calidad con mis propios benchmarks antes de irme

Estaba revisando un PR de mi equipo el martes a la tarde cuando vi el thread de Hacker News. "I cancelled Claude" — 874 puntos, 400+ comentarios, el tipo de conversación que explota porque le pone palabras a algo que mucha gente venía sintiendo pero no había articulado. Lo leí entero. Después cerré la pestaña y abrí mis propios logs.

Tengo registros de Claude Code corriendo contra el mismo conjunto de casos desde marzo. No es un benchmark académico: son los escenarios reales que le tiro en mi flujo de trabajo — refactoring de módulos TypeScript, generación de migraciones SQL, análisis de code paths en mi monorepo en Railway. Si hay deterioro, mis logs lo tienen. Y si no lo tienen, entonces el thread de HN es mayormente ruido emocional.

Spoiler: el deterioro existe. Pero no donde la mayoría se está quejando.

Claude calidad deterioro 2025: qué dicen mis logs vs. qué dice HN

Mi setup de seguimiento es simple. Desde el post sobre Claude Code quality reports vengo corriendo un conjunto fijo de 23 casos de prueba contra Claude Code. Los casos están divididos en tres categorías: razonamiento sobre código existente, generación de código nuevo, y detección de bugs en snippets que yo mismo inyecté con errores conocidos.

Cada corrida queda logueada con timestamp, modelo, tokens usados y un score manual mío del 1 al 5. No es automatizado — lo hago a mano, una vez por semana, lleva 40 minutos. Aburrido pero honesto.

Acá van los números entre marzo y julio 2025:

# Resumen de scoring — Claude Code (Sonnet base)
# Escala: 1-5 por caso, promedio semanal

Semana 2025-03-10:  avg=4.2  casos_fallados=3/23
Semana 2025-04-07:  avg=4.1  casos_fallados=3/23
Semana 2025-05-05:  avg=3.8  casos_fallados=5/23  # Primera caída notable
Semana 2025-06-02:  avg=3.6  casos_fallados=7/23
Semana 2025-06-30:  avg=3.5  casos_fallados=8/23
Semana 2025-07-21:  avg=3.7  casos_fallados=6/23  # Leve rebote

Hay deterioro. Del 4.2 al 3.5 en cuatro meses no es variación estadística — es tendencia. Pero cuando miro qué casos fallaron, la historia se complica.

Dónde empeoró, dónde no, y por qué eso importa más que el promedio

Los 8 casos que fallaron en la semana del 30 de junio: seis son de generación de código nuevo en TypeScript con constraints complejos. Dos son de análisis de code paths con más de tres niveles de indirección. Los 15 que pasaron: razonamiento sobre código existente, detección de bugs conocidos, refactoring de módulos acotados.

Mi tesis antes de abrir los logs era que el deterioro iba a estar en razonamiento complejo. Me equivoqué. Está en generación bajo restricciones múltiples simultáneas. El modelo hace peor cuando le digo "generá un hook que sea compatible con React 18, sin estados locales, que use el contexto X, que no rompa el tipo Y y que sea testeable con vitest". Cinco constraints juntos y la calidad cae notablemente frente a marzo.

Lo que NO empeoró y que nadie en el thread de HN menciona: la detección de bugs. En marzo encontraba 11 de 13 bugs inyectados. En julio encuentra 12. Mejoró levemente, aunque sea un delta pequeño. Tampoco empeoró el razonamiento sobre código que ya existe — que es, irónicamente, el caso de uso más común en mi día a día como Jefe de Desarrollo.

// Ejemplo de caso que EMPEORÓ — generación con múltiples constraints
// Prompt original (resumido):
// "Generá un custom hook TypeScript que:
//  - Sea compatible con React 18 concurrent mode
//  - No use useState ni useReducer (solo useRef para estado mutable)
//  - Consuma el AuthContext sin re-renders innecesarios
//  - Retorne un tipo discriminado (Success | Loading | Error)
//  - Sea testeable sin mock del context"

// Respuesta de marzo: hook funcional, tipos correctos, ref bien usado
// Respuesta de julio: hook funcional PERO tipo de retorno mal discriminado,
// re-render innecesario en el caso de Error, comentario en el código
// sugiere useReducer como alternativa (ignorando el constraint explícito)

// Diferencia concreta: no colapsó, pero ignoró uno de los cinco constraints

Ese patrón de "ignorar uno de los constraints cuando hay cinco o más" lo veo consistente en los casos fallados. No es que el modelo regresó a ser peor en general — es que el manejo de restricciones simultáneas parece haberse degradado.

El gotcha que nadie está midiendo: la regresión de contexto largo

Acá viene la parte que me resultó más incómoda de documentar, y que conecta con lo que ya había visto en el post sobre agentes async y observabilidad.

En mis casos con ventana de contexto larga — conversaciones de más de 15.000 tokens donde el modelo tiene que mantener coherencia con decisiones tomadas al principio — el deterioro es más pronunciado que en el promedio general. En marzo, esos casos tenían un avg de 4.0. En julio, 3.1. Eso es una caída de casi un punto entero en el mismo conjunto de pruebas.

El síntoma específico: el modelo contradice en el turno 12 una decisión que el mismo modelo tomó en el turno 3. No es un error de razonamiento en el momento — es pérdida de coherencia a lo largo de la conversación. Para mi flujo de trabajo con agentes, eso es peor que un error puntual porque es silencioso. El debugging de agentes async ya me había enseñado que los errores silenciosos son los que más duelen. Esto califica.

Lo relaciono también con lo que observé cuando armé el setup de CC-Canary: el proxy LLM-as-a-judge que puse delante del agente empezó a detectar inconsistencias de coherencia con más frecuencia desde mayo. No lo había conectado explícitamente con degradación del modelo hasta ahora.

# Log de CC-Canary — inconsistencias de coherencia detectadas por mes
# (extraído del sistema de alertas, formato simplificado)

grep "coherence_fail" /var/log/canary/2025-*.log | \
  awk '{print substr($1,1,7)}' | sort | uniq -c

# Resultado:
#   12 2025-03
#   14 2025-04
#   19 2025-05
#   31 2025-06
#   28 2025-07  # Leve baja pero sigue alto

Del 12 al 31 en tres meses. Ese número me importa más que cualquier benchmark sintético.

Errores comunes al medir deterioro de LLMs (los que cometí yo también)

Error 1: Comparar contra memoria. "Antes contestaba mejor" es una trampa. La memoria humana optimiza hacia los casos que te impresionaron o frustraron. Sin logs, estás comparando contra una versión idealizada del pasado. Yo caí en esto antes de empezar a registrar sistemáticamente.

Error 2: No controlar el prompt. Si cambiás el prompt entre corridas, no estás midiendo el modelo — estás midiendo tu prompt. Mis 23 casos tienen prompts fijos, en texto plano, guardados en un archivo de texto que no toco entre semanas. Si quiero probar una variante, la agrego como caso nuevo.

Error 3: Confundir fricción de UX con deterioro de calidad. El thread de HN mezcla ambas. Algunos de los reclamos más votados son sobre la UI de Claude.ai — respuestas más cortas, interfaz cambiada, comportamiento del botón de "nueva conversación". Eso no es deterioro del modelo, es cambio de producto. Y es legítimo quejarse, pero son categorías diferentes.

Error 4: Medir solo los casos que te importan a vos. Mis casos de generación TypeScript empeoraron. Mis casos de análisis de seguridad mejoraron levemente (relevante después de lo que vi con el supply chain attack de Bitwarden CLI — empecé a incluir casos de análisis de superficie de confianza). Si solo midiera TypeScript, concluiría deterioro total. Si solo midiera security analysis, concluiría mejora. El promedio heterogéneo es más honesto.

Error 5: No distinguir modelo de temperatura/sampling. Un cambio en los parámetros de sampling puede parecer deterioro de capacidad. No tengo visibilidad sobre eso desde afuera, pero es un confounder real que hay que tener en mente antes de atribuir todo al modelo.

FAQ: Claude calidad deterioro 2025

¿El deterioro de Claude en 2025 es real o es percepción?
Con mis logs: real en generación bajo restricciones múltiples y en coherencia de contexto largo. No real (o ligeramente positivo) en detección de bugs y razonamiento sobre código existente. El deterioro total percibido por el thread de HN mezcla degradación real del modelo con cambios de UX y con el sesgo de que la gente reporta frustraciones, no satisfacciones.

¿Qué tan confiables son mis benchmarks caseros?
Más confiables que la memoria, menos confiables que un setup con jueces automatizados y múltiples evaluadores. El scoring manual 1-5 tiene varianza. Lo que lo hace útil es la consistencia: mismos prompts, mismo evaluador (yo), misma frecuencia. No es ciencia — es ingeniería de campo.

¿Cancelar Claude tiene base empírica o es efecto manada?
Depende del caso de uso. Si trabajás principalmente con generación de código bajo múltiples constraints simultáneos, la degradación que mido es suficientemente pronunciada para replantear. Si trabajás con razonamiento sobre código existente o debugging, mis números no justifican la cancelación. El thread de HN tiene 874 puntos porque capturó una frustración real — pero la razón técnica para cancelar varía por caso de uso.

¿Qué alternativas probaste?
Corrí el mismo conjunto de casos contra GPT-4o en junio como punto de comparación. En generación TypeScript con constraints múltiples, GPT-4o tuvo avg=3.9 contra 3.5 de Claude — diferencia real pero no dramática. En coherencia de contexto largo, GPT-4o tuvo avg=3.4 contra 3.1 de Claude — básicamente parejo. Ninguno ganó con suficiente margen como para que el cambio valga la fricción de migración más el costo de reentrenar mis flujos de trabajo y mis prompts. Esto puede cambiar. Lo sigo midiendo.

¿Los posts anteriores sobre Claude Code quality cambiaron algo en lo que medís?
Sí. Después del post sobre LLMs generando security reports, agregué casos específicos de análisis de seguridad a mi suite. Después del post sobre Agent Vault, agregué casos de razonamiento sobre credenciales y permisos en contexto de agentes. La suite crece. El denominador cambia. Eso hace que las comparaciones históricas sean ligeramente ruidosas — lo reconozco.

¿Vas a cancelar o no?
No por ahora. Pero tengo un umbral definido: si el avg general baja de 3.3 por dos semanas consecutivas, o si las inconsistencias de coherencia en CC-Canary superan 40 eventos por mes durante dos meses seguidos, reevalúo. No lo decido por un thread viral — lo decido por mis propios números.

Lo que haría diferente: no cancelar por instinto, medir antes de moverse

Mi punto es este: el thread de HN tiene razón en que algo cambió. Se equivoca en el diagnóstico colectivo porque mezcla señales reales con ruido de UX, con sesgo de confirmación y con el efecto de que la frustración se viraliza más que la satisfacción.

El deterioro que mido es específico y acotado. Generación bajo constraints múltiples, coherencia en contexto largo. Si esos son los casos que dominan el trabajo de quien canceló, la decisión tiene fundamento empírico. Si cancelaron porque "siento que antes era mejor" o porque la UI cambió, están pagando un costo de migración por una percepción que no midieron.

Lo incómodo de esta conclusión es que le da más trabajo a quien quiere decidir. "¿Me vale la pena cancelar?" no tiene una respuesta global — tiene una respuesta que depende de qué casos de uso dominen el trabajo propio. Y eso requiere medición, no consenso de Hacker News.

Yo sigo con Claude porque mis números no justifican la fricción de moverme. Pero tengo el umbral claro, los logs corriendo y CC-Canary mirando. Si los números cambian, me muevo. Sin drama.

¿Medís la calidad de las respuestas de Claude en producción? ¿Tenés un setup de regresión propio? Me interesa comparar metodologías — especialmente si encontraste deterioro en casos que yo no estoy cubriendo.

Este artículo fue publicado originalmente en juanchi.dev