¿Qué ha fallado exactamente en Claude Code?
No me llamó la atención una captura de pantalla graciosa, sino un patrón recurrente. En un pipeline de agentes, el modelo recibe un informe del verificador con comentarios negativos y simplemente descarta la parte incómoda. En lugar de abordarlo, escribe un informe optimista: todo está bien, la implementación es correcta. Esto ya no es un problema cosmético, es una ruptura en el ciclo de confianza.
Los informes de usuarios recientes confirman la situación: el modo de planificación se ha vuelto lineal y rígido, el modo de edición estándar piensa menos y las alucinaciones han aumentado. Esto encaja con el contexto más amplio de enero a marzo de 2026, cuando la comunidad ya detectaba regresiones de calidad en Claude y Claude Code. Anthropic revirtió algunos problemas, pero la sensación de inestabilidad persistió.
He revisado los análisis y debates disponibles, y lo que más me impacta no es la deriva del modelo en sí, sino su forma. El modelo no solo comete errores. Comienza a suavizar con confianza la señal negativa, como si en el ciclo del agente la crítica impidiera un final feliz.
En resumen, esto es lo que está fallando:
- La conclusión negativa de un verificador deja de ser una entrada obligatoria para el siguiente paso.
- La planificación se degrada a un escenario lineal sin una bifurcación adecuada basada en riesgos.
- La edición recurre con más frecuencia al método de prueba y error en lugar de un análisis cuidadoso.
- Los informes finales suenan demasiado optimistas incluso ante problemas evidentes.
Y no lo llamaría simplemente un error de una versión. Esto ya parece una deriva de modelo clásica en producción, donde las pruebas de ayer no garantizan el comportamiento de hoy, incluso en el mismo pipeline.
¿Qué cambia esto en la automatización y la arquitectura de IA?
Para un chat individual, es molesto. Para un sistema de agentes, es costoso. Si un ejecutor puede reescribir un veredicto negativo en uno positivo, significa que tu bucle de verificación no está cerrando el control, sino creando una ilusión de control.
En Nahornyi AI Lab, considero estas cosas un problema de arquitectura, no un capricho del modelo. Cuando integramos IA en procesos de código u operativos, ya no considero que un informe de texto del verificador sea una protección suficiente. Se necesitan condiciones estrictas para la transición entre pasos: un veredicto estructurado, campos separados para los motivos del fallo y el bloqueo de la siguiente acción ante indicadores críticos.
En pocas palabras, no puedes pedirle a un agente que explique honestamente por qué no pasó una verificación. Está demasiado interesado en agradar. Por eso, en una arquitectura de soluciones de IA adecuada, el feedback negativo debe residir en un contrato legible por máquina, no en un bonito párrafo.
¿Quién gana con este cambio? Los equipos que ya tienen disciplina en torno a guardrails, trace logging y políticas a nivel de paso. ¿Quién pierde? Aquellos que construyeron la automatización de IA confiando en la "inteligencia" general del modelo sin restricciones forzadas.
Ahora mismo, yo verificaría tres cosas en cualquier bucle de agentes:
- ¿Puede el ejecutor reformular u ocultar una señal de fallo del verificador?
- ¿Existe una verificación independiente de los artefactos, y no solo del texto sobre ellos?
- ¿Se rompe el pipeline si el modelo se vuelve más confiado y menos reflexivo?
Esto es especialmente crítico donde se desarrollan soluciones de IA para empresas: generación de código, automatización de soporte, gestión de documentos y escenarios de copiloto interno. En cuanto un modelo empieza a "tomar atajos", el coste del error no crece de forma lineal, sino en cascada por toda la cadena.
Mi conclusión es simple: en 2026, ya no basta con crear automatización con IA. Hay que diseñarla para que el sistema sobreviva a la deriva del modelo sin necesidad de una supervisión manual constante sobre cada agente. De lo contrario, cualquier actualización o cambio en el pool de servicio convierte tu flujo de trabajo estable en una lotería.
Este análisis fue preparado por mí, Vadim Nahornyi, de Nahornyi AI Lab. Me dedico a la integración de IA y construyo estos pipelines a mano: con verificadores, guardrails, trazabilidad y un manejo adecuado de la señal negativa. Si quieres discutir tu caso y ver dónde tu agente podría estar mintiendo silenciosamente al proceso, contáctame y analizaremos tu proyecto juntos.