¿Qué se rompió exactamente en Claude Code?
Me encantan estas historias no por el drama, sino porque finalmente traen cifras reales, no solo capturas de pantalla de X. En un debate recogido por The Register, el equipo de la Directora de IA de AMD, Stella Laurenzo, y un análisis independiente del historial de uso mostraron una degradación de Claude Code después del 8 de marzo de 2026.
La escala no es trivial: 6.852 sesiones, unas 234.000 llamadas a herramientas (tool calls) y casi 18.000 bloques de pensamiento (thinking blocks). Esto ya no es un «me pareció», sino material que se puede analizar en serio.
Eché un vistazo por separado al repositorio lazy-claude-analysis. Lo más útil de esta historia no es la queja en sí, sino que el autor publicó un script y un panel para un análisis reproducible. Este es el camino correcto: menos emociones, más telemetría.
Las métricas pintan un panorama desalentador. Las lecturas antes de editar (Reads before edits) cayeron de 6.6 a 2.0. La proporción Lectura/Edición (Read/Edit ratio) se desplomó de 0.7 a 0.2. En otras palabras, el modelo comenzó a leer el código con mucha menos frecuencia antes de empezar a reescribir algo.
Otra señal de alerta que me llamó la atención fueron las infracciones de 'stop-hook' (stop-hook violations). Antes del 8 de marzo casi no existían, pero después aumentaron a un promedio de 10 por día. Esto suele manifestarse como la pereza clásica de un modelo en producción: no termina de leer el contexto, se detiene antes de tiempo y pide confirmación donde antes completaba la tarea con seguridad.
A nivel de síntomas, todo esto es familiar para cualquiera que haya utilizado agentes de codificación en un entorno real. En lugar de una edición precisa, el modelo realiza cambios amplios y ruidosos, produciendo el famoso 'AI slop'. Por fuera, la respuesta parece segura, pero por dentro tiene un débil soporte en el contexto real del proyecto.
En los debates, esto se relaciona con el despliegue de la redacción del pensamiento (thinking redaction) en la versión 2.1.69. La hipótesis es que la versión pública empeoró a la hora de mostrar, o incluso de realizar, un análisis profundo antes de actuar. Aún no he visto un análisis oficial de la causa raíz, así que mantendría la calma: la correlación es fuerte, pero aún no es la causa definitiva.
Por otra parte, apareció la bandera CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING. Por sí sola no prueba nada, pero el mero hecho de que exista tal interruptor indica claramente dónde buscar el problema: en la mecánica del razonamiento adaptativo, y no solo en la interfaz de usuario o en los límites de velocidad.
¿Qué cambia esto para los negocios y la automatización con IA?
En resumen, yo dejaría de tratar un modelo de codificación como una capa estable de infraestructura. Hoy lee cuidadosamente seis archivos antes de editar, y mañana lee dos y empieza a fantasear. Desde el punto de vista empresarial, esto ya no es una «peculiaridad del modelo», sino un riesgo operativo.
Los que más ganan aquí son los equipos que tienen su propia observabilidad sobre el LLM. Quienes registran las llamadas a herramientas, cuentan las lecturas antes de editar y rastrean las reescrituras de archivos completos, al menos ven la degradación en el mismo día. Quienes simplemente dieron Claude Code a sus desarrolladores y dijeron «úsalo» se enterarán del problema por los PR rotos.
Lo repito constantemente en los proyectos de mis clientes: la implementación de IA no puede basarse en la confianza en un único modelo. Se necesitan salvaguardas (guardrails), ejecuciones de prueba, rutas de respaldo y métricas de calidad a nivel del flujo de trabajo específico. De lo contrario, cualquier cambio silencioso en el comportamiento del modelo afecta a los plazos y la calidad más de lo que parece.
Para la automatización con IA en el desarrollo, la conclusión también es dura. Si un agente puede leer, modificar y confirmar código por sí mismo, necesita no solo acceso al repositorio, sino también un sistema de contrapesos: políticas sobre el volumen de edición, verificación de la lectura del contexto, un sandbox, reversión automática y pruebas obligatorias antes de la fusión.
En Nahornyi AI Lab, así es exactamente como construimos la arquitectura de las soluciones de IA para los procesos de ingeniería: no en torno a la magia de un modelo, sino en torno a un ciclo controlado. El modelo puede ser Claude, GPT o una versión local. Si empieza a volverse perezoso, el sistema debe detectarlo antes de que el cliente vea una regresión en producción.
Me gusta una cosa de esta historia con Claude Code: ahora el mercado tiene un ejemplo reproducible de razonamiento perezoso en producción. No un miedo abstracto, sino métricas concretas, una fecha de inflexión y una herramienta de análisis abierta. Para la industria, es un útil baño de realidad para su exceso de confianza.
Vadim Nahornyi, Nahornyi AI Lab. Construyo manualmente agentes de IA, automatización de código y flujos de trabajo en n8n para equipos reales, por lo que veo estos fallos no como un observador, sino como la persona que luego tiene que solucionarlos en producción.
Si quiere discutir su caso, encargar una automatización con IA, solicitar un agente de IA a medida o construir una automatización en n8n con las salvaguardas adecuadas, póngase en contacto. Analizaremos dónde están sus riesgos reales y diseñaremos un sistema sin fe ciega en un único modelo.