"Simplemente elimina tus instrucciones" no es un consejo que pueda seguir
Claude Opus 5 es un mejor modelo que produce peor trabajo en mi sistema. La solución de consenso me pide que tire lo que hace que el sistema valga la pena.
Claude Opus 5 se lanzó el 24 de julio. En todos los parámetros de referencia que importan, supera a Opus 4.8. SWE-bench Pro pasó de 69.2% a 79.2%. El propio benchmark de codificación de frontera de Anthropic se duplicó con creces.
Gestiono todo mi negocio a través de Claude Code. Docenas de proyectos en seis áreas, alrededor de treinta habilidades personalizadas, un sistema de memoria, agentes de mantenimiento programados, reglas duras obtenidas tras meses de cosas que salieron mal. Aproximadamente 20,000 tokens de contexto se cargan antes de que escriba una sola palabra.
Cuatro días después, no podía trabajar con él. Dos sesiones completas - un sitio de cliente y un producto SaaS - produjeron resultados que no enviaría.
Ahora he leído la mayor parte de lo que se ha escrito sobre esto, y la solución de consenso es notablemente uniforme: elimina tu andamiaje de instrucciones. Anthropic redujo el 80% del prompt del sistema de Claude Code. El CEO de Every eliminó sus habilidades y reportó que las cosas mejoraron "drásticamente."
No creo que ese consejo funcione para mí, y quiero explicar por qué cuidadosamente, porque creo que mucha gente está a punto de eliminar algo que extrañarán.
Tres cosas que se rompieron
Comete errores con confianza. De la propia ficha técnica de Anthropic:
"El modelo alucina afirmaciones fácticas ligeramente más que Opus 4.8, a pesar de ser más preciso en general."
Lee eso dos veces. Más preciso en general, alucinando más. No son contradictorios - juntos describen exactamente lo que se siente en el uso diario. El mismo documento señala que el modelo "afirmó con confianza una respuesta sobre la cual en realidad no estaba seguro." Un modelo que está obviamente equivocado es barato. Un modelo que está equivocado mientras suena seguro es costoso, porque dejas de verificar.
Se detiene antes de que el trabajo esté terminado. Kieran Klaassen, ejecutando un flujo autónomo:
"seguía devolviendo el control al usuario. A pesar de ser un flujo autónomo. Esto es extremadamente molesto."
Eso coincide con lo que vi. Las tareas se reformulaban en lugar de ejecutarse, el trabajo parcial se reportaba como terminado, resistencia donde el modelo anterior simplemente hacía lo que debía.
Habla demasiado. El mejor documentado de los tres, admitido repetidamente en la propia guía de migración de Anthropic:
"Las respuestas visibles predeterminadas y los entregables escritos son más extensos en Claude Opus 5 que en modelos Opus anteriores, y reducir el esfuerzo disminuye el volumen de pensamiento sin acortar de manera confiable la respuesta visible."
Nota la segunda mitad. El parámetro de esfuerzo no lo soluciona.
El mecanismo en el que todos coinciden
Aquí está la parte que me lo reformuló. Del artículo de ingeniería de Anthropic, publicado el día del lanzamiento de Opus 5:
"estábamos sobre-restriciendo a Claude Code, tanto a través de nuestro prompt del sistema como en nuestros archivos CLAUDE.md y habilidades"
Redujeron aproximadamente el 80% de su prompt del sistema. Dan Shipper reportó que Opus 5 "no funcionaba bien con nuestras habilidades y plugins existentes," y que eliminar esas habilidades lo hizo "drásticamente mejor." João Queirós: "Los prompts simples produjeron resultados más prometedores que los flujos de trabajo maduros y cargados de instrucciones."
Cuatro fuentes independientes más el proveedor, todas apuntando a la misma variable: cuanto más andamiaje de instrucciones hayas acumulado, peor funciona este modelo.
Eso también explica por qué el discurso parece dividido en lugar de unánime. Si tu CLAUDE.md tiene doce líneas, Opus 5 es directamente mejor y los críticos parecen dramáticos. Si has pasado meses construyendo un sistema, estás en una conversación completamente diferente.
Donde el consejo de consenso se desmorona
Entonces elimínalo, dice todo el mundo. Aquí está el problema: mis instrucciones no son una sola cosa. Son dos cosas que se ven idénticas en un archivo de texto y son completamente diferentes en esencia.
Compensaciones. Instrucciones que existen para contrarrestar una debilidad del modelo. "Verifica tu trabajo." "Delega por defecto" - que escribí cuando el modelo anterior delegaba de menos. "Resume antes de continuar." Esto es andamiaje en el sentido literal: estructura temporal alrededor de un vacío en el edificio.
Las compensaciones son seguras de eliminar, y Opus 5 genuinamente vuelve obsoletas muchas de ellas. Se auto-verifica sin que se lo pidas. Delega fácilmente. Bien. Elimínalas.
Constitución. Hechos y estándares que no existen en ningún otro lugar. Que una compilación verde me ha mentido antes, así que la prueba significa WebKit real y una cadena marcadora en el HTML, no un HTTP 200. Qué host está detrás de qué proyecto. Qué cliente está restringido y cuál no. Qué puede hacer la tipografía de esta marca. Qué clase de fallo me ha costado más y qué la protege específicamente.
Esto no es ser insistente. Es información. Y no es inferible a ninguna calidad de modelo, porque no es un problema de razonamiento - es conocimiento que existe solo en mi negocio. Un modelo más inteligente no lo adivina mejor. Lo adivina con más confianza.
El consejo de consenso no distingue entre estas. Dice "elimina tus instrucciones," y la gente eliminará ambas, porque en un archivo markdown se ven igual.
Lo sé porque lo hice. Siguiendo la guía de migración, eliminé las instrucciones de verificación de mi puerta de finalización. La guía tiene razón en que "verifica tu trabajo" ahora es redundante. Pero también eliminé las definiciones de lo que cuenta como prueba en mi stack - y las ilusiones de verificación son, por mucho, mi fallo recurrente más costoso. Eliminé la barrera construida específicamente contra mi propio peor modo de fallo porque una recomendación general me dijo que recortara.
Dos sesiones más tarde, revertí todo.
La afirmación que realmente quiero hacer
En todas partes se dice que Opus 5 necesita menos instrucciones. Creo que esa es la descripción incorrecta de lo que está sucediendo.
Opus 5 es peor operando bajo instrucciones. Y para toda una clase de usuario, operar bajo instrucciones no es un gasto general - es todo el trabajo.
No estoy pagando por un modelo que escribe buen código genérico. Puedo conseguir eso en cualquier lado ahora. Estoy pagando por uno que escribe código que encaja en un sistema con convenciones, requisitos de cumplimiento, reglas de marca, restricciones específicas del cliente y un historial documentado de cómo han salido mal las cosas aquí antes. Elimina las restricciones y no has mejorado mi resultado. Has hecho que el modelo esté más cómodo y mi resultado más genérico.
Así que cuando leo "elimina tus habilidades y funciona drásticamente mejor" - ¿mejor en qué? En fluidez de codificación sin restricciones, probablemente. No en producir trabajo que encaje en mi sistema, porque lo que hace que el trabajo encaje en mi sistema es precisamente lo que se eliminó.
Estoy aproximadamente 90% seguro de que Opus 5 sin mi andamiaje de instrucciones nunca alcanzará la calidad que obtengo con él. No porque el modelo sea débil, sino porque el ingrediente faltante no es inteligencia. Es conocimiento de mi negocio, y no hay cantidad de capacidad bruta que lo sustituya.
Lo que estoy haciendo, y lo que sugeriría
Volví a Opus 4.8 con mi configuración anterior restaurada byte por byte. No como protesta - porque funciona, y tengo fechas límite.
No estoy afirmando que Opus 5 sea un peor modelo. Los benchmarks son reales, personas que respeto reportan ganancias genuinas, y cambié dos variables a la vez - modelo y configuración, el mismo día - así que no puedo atribuir limpiamente mis propios resultados. Esa es una limitación real de mi evidencia, no un rodeo retórico.
Lo que afirmo es más acotado: un mejor modelo puede producir peor trabajo en un sistema maduro, y el fallo es silencioso. Nada da error. Nada te advierte. Tus instrucciones simplemente dejan de significar lo que solían significar.
Si te está pasando esto, la secuencia que usaría ahora:
- Clasifica antes de recortar. Revisa tus instrucciones y marca cada una: ¿esto compensa una debilidad del modelo, o es algo que solo yo sé? Esa sola pasada vale más que cualquier heurística de recorte.
- Elimina las compensaciones libremente. Especialmente cualquier cosa que le diga al modelo que verifique, delegue o resuma. Ese consejo es sólido.
- Defiende tu constitución. Datos del dominio, definiciones de prueba, estándares de marca, restricciones del cliente. Si eliminar una línea haría que un nuevo empleado competente produjera trabajo incorrecto, se queda.
- Cambia una variable a la vez. Modelo o configuración, nunca ambos. Rompí esto y perdí mi capacidad de atribuir cualquier cosa.
- Hazlo reversible. Un solo commit, para que la reversión sea exacta en lugar de aproximada.
- Tu propio patrón de fallo documentado supera cualquier consejo general del proveedor. Este es el que me tatuaría en algún lado.
La parte incómoda es que las compensaciones y la constitución se sienten idénticas cuando las escribiste. Cada regla en mi sistema existe porque algo salió mal una vez. Distinguirlas después es el trabajo real - y "simplemente elimínalo" asume silenciosamente que nadie tiene nada que valga la pena conservar.
Fuentes: Ficha técnica y guía de migración de Claude Opus 5 (Anthropic, julio 2026); Blog de ingeniería de Anthropic, 24 de julio de 2026; Dan Shipper y Kieran Klaassen vía X, julio 2026; João Queirós, julio 2026.
