Contexto técnico
He revisado detenidamente el post-mortem de Anthropic del 23 de abril, y lo más interesante no es el error en sí, sino cómo una integración de IA aparentemente estable se vino abajo por varias pequeñas decisiones a la vez. Si estás construyendo automatización con IA sobre LLMs, este es un escenario muy familiar: el modelo parece el mismo, pero el producto de repente se vuelve más tonto, olvidadizo y parco.
Anthropic describió tres cambios independientes. El primero se realizó el 4 de marzo: en Claude Code, se redujo el esfuerzo de razonamiento predeterminado de alto a medio para acelerar las respuestas. En las pruebas internas, la caída de calidad parecía moderada, pero en el uso real, los usuarios obtuvieron un asistente de código notablemente más débil. Esto no se revirtió hasta el 7 de abril.
El segundo cambio llegó el 26 de marzo. El equipo quería limpiar la caché de razonamiento tras una hora de inactividad, pero un error provocó que se limpiara en cada turno subsiguiente de la sesión. Esto creó la impresión de que Claude olvidaba el contexto, se repetía y actuaba desorientado. Este error persistió hasta el 10 de abril.
El tercer cambio apareció el 16 de abril, después del lanzamiento de Opus 4.7. Para eliminar la verborrea y reducir el consumo de tokens, Anthropic añadió restricciones al system prompt. Aquí fue donde todo se complicó: la nueva instrucción, junto con otras ediciones del prompt, degradó la calidad de la codificación en varias versiones, incluidas Sonnet 4.6, Opus 4.6 y Opus 4.7. La reversión se hizo el 20 de abril.
El punto clave: según Anthropic, el modelo base y la API principal no estaban rotos. Lo que se rompió fue la capa de producto. Sinceramente, este es mi tipo de incidente favorito y el más frustrante, porque el culpable no es un gran lanzamiento, sino la suma de cambios "seguros" en parámetros, la capa de prompts y la gestión de sesiones.
Qué significa esto para el negocio y la automatización
Para los equipos, esta es una señal muy aleccionadora: la degradación de un sistema LLM a menudo no proviene del modelo, sino de la infraestructura que lo rodea. Si el desarrollo de tu solución de IA depende de system prompts, caché, enrutamiento y ajuste de latencia, necesitas probar toda la orquesta, no solo el modelo.
¿Quién gana? Aquellos con despliegues por etapas, métricas de cohorte adecuadas y reversiones rápidas. ¿Quién pierde? Los equipos que tratan los prompts como "si no fueran código" y aplican dichos cambios con poca disciplina de ingeniería.
Desde hace tiempo, trato la capa de prompts como parte de la arquitectura, no como un simple archivo de texto. En Nahornyi AI Lab, resolvemos exactamente estos problemas para los clientes: desglosamos la arquitectura de IA en capas, establecemos observabilidad y eliminamos puntos frágiles que pueden hundir la calidad de repente.
Si ya notas que tu asistente es brillante en un momento y torpe al siguiente sin razón aparente, no suele ser magia ni "fatiga del modelo". Podemos analizar sistemáticamente tu sistema y construir una automatización de IA que se base en garantías de ingeniería, no en la suerte. Si lo deseas, en Nahornyi AI Lab puedo ayudarte a encontrar rápidamente dónde está la fuga en tu producción.