Opus 5 no es tan malo como dice internet

Opus 5 no es tan malo como dice internet. Tras más de cinco semanas usándolo a diario, sigo viendo la prosa difícil, la ampliación del alcance, las suposiciones erróneas y las regresiones que describen sus usuarios. Pero con un plan basado en investigación, una tarea acotada y comprobaciones externas a su mensaje final, es un desarrollador competente.

Por qué cambió mi opinión: dejé de pedirle a Opus que planificara e implementara a la vez

Mi opinión mejoró porque dejé de pedirle a Opus que descubriera la arquitectura e implementara una funcionalidad grande dentro del mismo contexto. En mi evaluación de la semana del lanzamiento lo describí como un buen implementador difícil de supervisar. Cinco semanas de uso repetido han dejado más clara esa separación y han aumentado mi confianza en él como implementador.

Leer cientos de informes negativos influyó en mi valoración más de lo que esperaba. Esos informes me enseñaron qué debía vigilar, pero también hicieron que cada frase torpe o cambio innecesario pareciera confirmar un veredicto ya decidido. La diferencia quedó más clara cuando separé las tareas mal delimitadas de las que tenían un plan. Opus sufría sobre todo cuando pedía a una sola conversación que comprendiera una funcionalidad grande, decidiera la arquitectura, conservara todas las restricciones, implementara todo el cambio y lo explicara con claridad. Ese único prompt escondía varios trabajos distintos.

Cuando le encargué la implementación después de definir la arquitectura y los límites, Opus hizo un trabajo sólido. Rastreó el código pertinente por todo el repositorio, abordó cambios difíciles y detectó efectos que un modelo menos atento podría pasar por alto. En una tarea acotada, esa atención ayudó en lugar de perjudicar porque encontró los archivos, las pruebas y los casos límite relacionados con el comportamiento solicitado.

Este cambio de opinión no borra los fallos de Opus 5. Me indica en qué función resultan más fáciles de contener.

¿Qué problemas de Opus 5 son reales y qué ayuda a reducirlos?

Los cinco grupos de quejas son creíbles, pero no me parecen igual de graves. El problema de la prosa sigue siendo evidente durante el uso normal. Los otros cuatro causan mucho menos daño cuando Opus recibe un plan basado en investigación previa, un alcance de implementación limitado y un paso real de verificación.

Queja	Qué la reduce	Qué persiste
Prosa difícil de leer	Límites de extensión y reglas de lenguaje claro	En mi uso, Opus sigue siendo menos claro que Fable
Ampliación del alcance	Exclusiones explícitas y un alcance limitado a pocos archivos	Las instrucciones aún pueden ignorarse
Premisas falsas	Investigar antes de editar y hacer preguntas explícitas	Un revisor debe verificar la premisa
Regresiones o cierre prematuro	Criterios de aceptación, pruebas y revisión del diff	Las comprobaciones elegidas aún pueden ser insuficientes
Pérdida del plan	Plan guardado, tareas más pequeñas y contexto más limpio	Cada parte aún necesita revisión

Cada cambio puede reducir el problema correspondiente, pero ninguno me permite prescindir de una revisión independiente.

1. Prosa difícil: los límites ayudan, pero Fable sigue siendo más claro

Es la queja que reconozco con mayor rapidez. Opus puede juntar palabras correctas en una frase que exige más de una lectura, sobre todo en explicaciones, resúmenes y archivos Markdown largos. Los usuarios de Reddit describieron esa misma combinación de frases largas, estructura débil y texto que en teoría tiene sentido, pero resulta agotador descifrar. [5] [6]

Qué ayuda: la guía de Anthropic sobre cómo escribir prompts para Opus 5 explica que, de forma predeterminada, las respuestas destinadas al usuario y los informes escritos son más extensos. Por eso recomienda fijar límites explícitos para ambos. [1] Pedir respuestas más cortas y usar una instrucción directa sobre lenguaje claro ayuda, pero ninguna de las dos opciones consigue siempre la claridad conversacional que obtengo con Fable 5. Esa diferencia importa durante una conversación de planificación. Importa mucho menos cuando el resultado que necesito es un cambio de código probado.

2. Ampliación del alcance: dejar claro qué queda fuera acota la tarea

Opus presta una atención poco habitual a problemas cercanos, posibles abstracciones, validaciones que faltan y formas de hacer más completo un cambio pequeño. Puede resultar útil en una auditoría. En una corrección acotada, puede convertir una petición en una refactorización o montar un flujo de trabajo alrededor de una comprobación que debería haberse resuelto con un comando. Anthropic advierte expresamente que Opus 5 puede ampliar el alcance de una tarea, verificar su trabajo en exceso y delegar con demasiada facilidad. [1]

Qué ayuda: defino lo que queda fuera con la misma claridad que el objetivo. Los hallazgos ajenos a la tarea se notifican, no se corrigen, y la arquitectura existente se mantiene salvo que los criterios de aceptación exijan un cambio. Un autor de Reddit comunicó una mejora parecida después de sustituir unas instrucciones antiguas, que exigían corregir de inmediato cualquier problema, por una regla que pedía señalar los problemas no relacionados y dejar que el usuario decidiera el alcance. [7] El testimonio muestra que la configuración puede cambiar el comportamiento. No convierte al usuario en responsable de todos los fallos.

3. Premisas falsas: investigar permite detectar antes las suposiciones

El testimonio de Reddit más claro de la colección describía cómo Opus inventó una incidencia de Linear y después hizo referencia a ella en comentarios de código, pruebas y mensajes de commit. [8] No he visto ese fallo exacto, pero reconozco el riesgo de fondo: cuando Opus se compromete con una interpretación, puede completar mucho trabajo técnicamente competente antes de detenerse a cuestionar la premisa.

Qué ayuda: una fase de investigación independiente permite ver las suposiciones antes de que el código dependa de ellas. El modelo aún necesita una instrucción clara para preguntar cuando falta un dato que cambia el diseño, y un revisor debe comprobar que la implementación responde a la petición original y no a otra parecida.

4. Regresiones: verifica el trabajo fuera de Opus

Varios testimonios describen una corrección que introduce una regresión, seguida de otra corrección que vuelve a abrir el fallo original. Un hilo de Reddit resumió el patrón así: arreglar el error A, romper esa solución al corregir el error B y después resolver A otra vez. [9] Son anécdotas sin repositorios que yo pueda inspeccionar, pero describen un fallo conocido de los agentes: cada corrección local parece útil mientras el conjunto de criterios de aceptación queda cada vez más lejos.

Qué ayuda: no acepto que una tarea esté terminada solo porque el modelo lo afirme. La finalización la determinan las comprobaciones acordadas: las pruebas pertinentes, la compilación, una revisión específica del diff y cualquier comprobación manual que requiera la funcionalidad. La planificación ayuda a Opus a elegir el trabajo. La verificación determina si ese trabajo está completo.

5. Pérdida del plan: separa la investigación de la implementación

Una funcionalidad grande mezcla investigación, arquitectura, implementación, depuración y revisión en un contexto cada vez mayor. Opus puede consumir gran parte del contexto útil mientras explora y después implementar a partir de un recuerdo comprimido o parcial de la decisión. Un testimonio ambivalente de Reddit resulta revelador: el autor consideró frustrante trabajar con Opus en un repositorio grande y consolidado, pero explicó que el modelo creó una nueva extensión de Chrome en una sesión, hizo 17 commits y superó una revisión de Codex. [10] El testimonio no permite aislar la causa, pero muestra que el mismo usuario obtuvo resultados mucho mejores en un proyecto nuevo con menos contexto heredado.

Qué ayuda: la guía de Claude Code de Anthropic explica que el rendimiento puede caer a medida que se llena la ventana de contexto, lo que puede provocar que se pasen por alto instrucciones y aumenten los errores. Recomienda separar la investigación y la planificación de la implementación cuando los cambios son inciertos o afectan a varios archivos. [2] El consejo sirve para todos los modelos de programación que utilizo. Con Opus, el coste de ignorarlo simplemente resulta más visible.

¿Qué demuestran realmente 1.008 fragmentos negativos sobre Opus 5?

La colección muestra que cinco tipos de quejas aparecieron repetidamente, así que resulta útil para decidir qué riesgos conviene prevenir. Es un mapa de fallos, no una encuesta de satisfacción ni una clasificación de modelos.

Recopilé 1.008 fragmentos fechados entre el 23 de julio y el 29 de agosto de 2026. Procedían de 229 publicaciones y 779 comentarios repartidos entre 294 hilos distintos de Reddit. Un comentario y la publicación a la que responde no son pruebas independientes, y varios hilos con mucha actividad aportaron numerosas entradas. Una marca de tiempo corresponde al día anterior al anuncio público que Anthropic hizo el 24 de julio, así que trato las fechas como metadatos de Reddit y no como prueba de acceso anticipado. [14]

fragmentos negativos

1008

hilos distintos

294

publicaciones

229

comentarios

779

Una comparación justa de popularidad necesitaría muestras equivalentes de Fable, Sol, versiones anteriores de Opus y otros modelos, ajustadas según el número de usuarios y la actividad de cada subreddit. No dispongo de esas muestras. Lo que sí tengo es un registro detallado de los problemas que la gente describió repetidamente después de una mala sesión con Opus 5.

Agrupé los fragmentos según el fallo descrito, en lugar de contar cada etiqueta libre como un problema independiente. Así obtuve los cinco grupos anteriores. Los fallos al seguir instrucciones y el consumo de tokens solían formar parte de esos problemas, no ser resultados separados. Esta clasificación me dio la lista práctica de medidas preventivas que buscaba en la colección.

¿Qué pueden corregir realmente unas instrucciones mejores para Opus 5?

Unas instrucciones mejores pueden reducir las respuestas largas, las verificaciones innecesarias, la delegación y la ampliación del alcance. No garantizan que el modelo siga el plan, termine de verdad, escriba bien o razone correctamente. Lo útil no es un prompt ingenioso, sino un contrato de trabajo más claro respaldado por un proceso y verificaciones.

Cuatro detalles son los que más cambian mis resultados. Indico el resultado solicitado, explico qué no debe cambiar, señalo la arquitectura existente que debe respetarse y defino qué pruebas necesito para considerar terminado el trabajo. En una funcionalidad amplia, esos detalles proceden de la investigación y de un plan de arquitectura, no de alargar mi primera idea.

Las instrucciones persistentes sirven para las reglas que se aplican a todas las tareas. Claude Code carga CLAUDE.md como contexto del proyecto, por lo que es un lugar razonable para indicar que los problemas no relacionados solo deben notificarse, que hay que reutilizar los patrones existentes y que la finalización exige resultados reales de pruebas o de la compilación. Anthropic advierte que este archivo aporta contexto, no una configuración obligatoria, y que las instrucciones breves y específicas funcionan mejor que una colección larga de reglas solapadas. [3]

Esa limitación importa porque incluso los usuarios cuidadosos comunican fallos. En un hilo verificado de Reddit, un usuario cuenta que Opus ignoró un archivo CLAUDE.md conciso. [12] Unas instrucciones mejores aumentan la probabilidad de obtener el resultado esperado, pero no convierten al usuario en responsable de un error del modelo.

Por eso tampoco le diría a un usuario frustrado que aprenda a escribir prompts y dejaría ahí el asunto. Los testimonios positivos más convincentes describían cambios en la forma de trabajar con Opus. Un usuario de Reddit trasladó los requisitos y la revisión a Fable y después entregó a Opus una especificación completa; el comportamiento no deseado casi desapareció. [11] Esa separación de funciones es también la que aplico ahora a los cambios grandes.

Cómo uso Opus 5 para funcionalidades grandes

Mantengo una conversación principal responsable del resultado y de la arquitectura. Esa conversación investiga el repositorio, recurre a agentes con preguntas concretas para obtener la información que falta, decide el diseño y escribe un plan que recoge los sistemas afectados, lo que queda fuera del objetivo, los riesgos y los criterios de aceptación. Solo entonces asigno la implementación a agentes Opus en partes acotadas.

Los agentes no reciben una instrucción imprecisa como “crea la funcionalidad”. Cada uno recibe la parte pertinente del plan, los archivos o sistemas que forman parte del alcance, el comportamiento que debe conservar, las comprobaciones que debe ejecutar y un punto en el que detenerse. La documentación de subagentes de Anthropic explica que cada subagente trabaja en su propio contexto y devuelve un resumen a la conversación principal. Así se protege el contexto principal, pero también significa que el mensaje de delegación debe incluir los datos que el agente no puede deducir. [4]

Prefiero Fable 5 para la conversación principal porque se comunica con más claridad y mantiene una mejor visión de la arquitectura en mis proyectos. Opus se ocupa después de buena parte de la implementación. Es mi preferencia, no una clasificación general, y puedo trabajar así en parte porque pago Max 20x. Anthropic ofrece ese plan por 200 dólares al mes, con 20 veces la capacidad de Pro por sesión. [13] Un flujo que utiliza un modelo prémium para planificar y varios agentes Opus para ejecutar no está disponible en las mismas condiciones para todos los suscriptores.

La misma separación sigue siendo útil si Opus es el único modelo al que tienes acceso. En ese caso, separo las fases en conversaciones distintas en lugar de asignarlas a modelos diferentes.

¿Cómo deberías usar Opus 5 por sí solo?

Utiliza Opus para todo el proceso, pero no le pidas que lo ejecute entero en una sola sesión ininterrumpida. Separa la planificación de la edición, guarda el plan acordado, implementa una parte revisable cada vez y empieza con un contexto más limpio cuando cambie el tipo de trabajo.

Ante una funcionalidad incierta, empieza en modo de planificación y pide a Opus que inspeccione el repositorio sin modificarlo. El plan debe indicar los archivos y sistemas afectados, explicar el enfoque elegido, registrar las preguntas sin resolver y definir cómo se comprobará cada parte. Revisa ese documento antes de implementar. Anthropic recomienda separar la investigación y la planificación de la implementación cuando el enfoque no está claro o el cambio afecta a varios archivos, aunque señala que una corrección pequeña y evidente quizá no necesite ese paso adicional de planificación. [2]

Después, entrega a la conversación de implementación solo la primera parte coherente. Una parte útil puede revisarse y probarse sin esperar a que esté terminada toda la funcionalidad. Si una funcionalidad le llevaría semanas a un desarrollador, divídela en partes que puedan probarse de manera independiente. Separa esas partes según sus dependencias y los límites de verificación, no según un número arbitrario de prompts.

Guarda el plan fuera de la conversación para que sobreviva a un reinicio del contexto. Utiliza /clear entre tareas no relacionadas y envía la investigación del repositorio a subagentes solo cuando sea lo bastante grande como para justificar un contexto aislado. Opus 5 ya tiende a delegar, por lo que añadir agentes no siempre mejora el resultado. [1] El objetivo es mantener centrado el contexto principal, no crear tantos agentes como sea posible.

Por último, revisa las pruebas en lugar de confiar en lo convincente que suene el mensaje final. Lee el diff, ejecuta las comprobaciones pertinentes y compara el resultado con los criterios de aceptación guardados. Si una parte está mal, corrígela y compruébala antes de añadir la siguiente. Así evitas que un error local termine en la reescritura de toda la funcionalidad.

Qué sigue haciendo mal Opus 5

Algunos problemas de Opus 5 persisten incluso con un buen flujo de trabajo. En mi experiencia, su prosa sigue siendo más difícil de leer que la de Fable, todavía necesita más supervisión de la que me gustaría y los límites explícitos no garantizan que vaya a respetarlos.

Opus 5 ya forma parte de mi flujo habitual de implementación. No es mi modelo preferido para la conversación principal sobre arquitectura, y tampoco lo elegiría para escribir un artículo sin una edición intensa. Aunque una implementación parezca convincente, todavía puede apoyarse en una premisa equivocada, por lo que mantengo el plan y la revisión final fuera del contexto del agente que ejecuta el trabajo.

Las quejas de Reddit me ayudaron a identificar los tipos de fallo, pero no decidieron si Opus podía encajar en mi trabajo. Durante la semana del lanzamiento cometí el error de tratar la calidad de la supervisión y la calidad de la implementación como si fueran lo mismo. Sigo sin confiar en Opus para supervisar un cambio grande, pero cuando Fable mantiene el plan y se encarga de la revisión, a menudo confío en Opus para escribir el código.