Acabo de grabar un curso entero dirigiendo a un agente de IA: quince tareas, una aplicación Laravel completa con inventario, solicitudes, máquina de estados, aprobación y devolución. Laravel 13, PHP 8.5, Blade.
Usé Opus en tres de esas quince tareas. Las otras doce las hizo Sonnet. Y salió bien.
Esto va de por qué, y de cómo decidir tú lo mismo en tu proyecto.
El reparto exacto
Fase | Modelo Utilizado | Motivo |
|---|---|---|
Especificación | Sonnet | Redactar un documento estructurado a partir de requisitos que ya traigo pensados. |
Plan y tareas | Opus | Aquí se decide el orden, las dependencias entre bloques y qué entra en cada tarea. Un error se arrastra hasta el final. |
T04 — CRUD de categorías | Opus | Es la implementación de referencia del patrón completo. T06 y T08 la calcan. |
T12 — Aprobar / rechazar | Opus | Transacción atómica, update condicional para la carrera y excepción de dominio mapeada a 409. |
T14 — Catálogo con filtros | Opus | Arquitectura de filtros desde cero: FilterValue, Filter y Pipeline, con el |
T01, T02, T03, T05, T06, T07, T08, T09, T10, T11, T13, T15 | Sonnet | Implementación sobre convenciones ya escritas. El agente no decide arquitectura, la aplica. |
La regla que saqué de esto
Cuando miré el reparto ya terminado, las tres tareas de Opus no tenían en común "ser difíciles". Tenían en común otra cosa, y son tres criterios distintos.
1. Donde el resultado se replica
T04 es el CRUD de categorías. Como pieza de software es lo más aburrido del proyecto. Pero es la primera vez que aparece el patrón completo —FormRequest, DTO, Action, ViewModel y Blade— y T06 y T08 lo copian tal cual.
Un error ahí no cuesta una tarea: cuesta tres. Por eso subí de modelo en la tarea más simple de todo el curso.
Este es el criterio que más se pasa por alto. No preguntes solo si la tarea es compleja; pregunta cuántas veces se va a copiar lo que salga de ella.
2. Donde equivocarse no se ve
T12 es la aprobación de un préstamo. Hay que comprobar que el equipo está disponible, marcarlo como prestado y cambiar el estado de la solicitud, todo dentro de la misma transacción, con un update condicional que resuelva la carrera entre dos usuarios simultáneos y una excepción de dominio que acabe en un 409.
Una implementación mal hecha aquí pasa los tests si los tests no contemplan la concurrencia. Funciona en desarrollo. Funciona en la demo. Y se rompe en producción el día que dos personas aprueban a la vez.
Cuando el fallo es silencioso, sube de modelo.
3. Donde no hay convención que seguir
T14 monta la arquitectura de filtros del catálogo desde cero. No había nada escrito en .ai/docs/ sobre cómo se hace un filtro, porque era la primera vez que aparecía en el proyecto.
Esa es la diferencia real con las doce tareas de Sonnet: en aquellas, la decisión ya estaba tomada y escrita. En T14 había que tomarla.
Entonces, ¿se nota Opus 5 frente a Opus 4.8?
Llevo usándolo a diario desde que salió. Mi respuesta es que no.
No en mi trabajo, no en este proyecto, no de una forma que me haya hecho cambiar nada. Los números del anuncio dicen otra cosa —puntuaciones que doblan a las de Opus 4.8 en algunos benchmarks agénticos, menos tokens por tarea, más fiabilidad en cadenas largas— y no dudo de esas cifras. Lo que digo es que no se traducen en nada que yo pueda percibir mientras trabajo.
Hubo correcciones durante el curso, claro. En tareas de Opus y en tareas de Sonnet. Pero ninguna que me hiciera pensar "esto lo habría resuelto un modelo mejor".
Y eso tiene una explicación que no está en el modelo.
Por qué el modelo importa menos de lo que parece
Los benchmarks miden a un modelo resolviendo un problema solo. Yo no trabajo así, y probablemente tú tampoco.
Antes de que el agente escriba una línea en mi proyecto ya tiene delante una especificación con criterios de aceptación verificables, un plan con dependencias explícitas, una tarea autocontenida que dice qué piezas tocar, un centro de contexto en capas con las convenciones de arquitectura, y una definición de "hecho" que no admite interpretación: Rector, Pint, PHPStan, Pest, tests de arquitectura, SonarQube a cero y un commit por tarea siguiendo Conventional Commits.
Con todo eso montado, el margen de maniobra del modelo es estrecho a propósito. No tiene que decidir si usa un Action o un Service, porque está escrito. No tiene que adivinar si una precondición del agregado devuelve 403 o 422, porque está escrito. Y si se equivoca, el pipeline lo para antes de que llegue a un commit.
Eso es el harness, o por lo menos el mío, y es lo que determina la calidad del resultado. Cambiar de modelo mueve el margen. Cambiar el harness mueve el suelo.
Lo que esto significa para tu factura
La consecuencia es directa: con el andamiaje bien puesto, el 80% del trabajo baja de gama sin que lo notes.
En mi caso fueron doce tareas de quince con el modelo de gama media, que es el que ya comparé en detalle hace unas semanas. Si andas mirando el gasto, esto encaja con lo que conté en cuánto cuesta programar con IA: el ahorro no está en buscar el modelo barato, está en no necesitar el caro.
Y hay un corolario que va en dirección contraria a lo que se suele contar: cuanto peor es tu setup, más necesitas el modelo caro. Si trabajas sin pipeline, sin convenciones escritas y sin tests, el modelo es lo único que te separa del desastre, y ahí sí paga el mejor que puedas permitirte. Montar el andamiaje cuesta un fin de semana y luego te deja bajar de gama para siempre.
Cómo aplicarlo mañana
Antes de lanzar una tarea, tres preguntas:
¿Este código lo van a copiar otras tareas? Si es la primera vez que aparece un patrón, sube de modelo aunque la tarea parezca trivial.
¿Un fallo aquí sería silencioso? Concurrencia, transacciones, permisos. Si el test verde no garantiza que esté bien, sube de modelo.
¿Hay una convención escrita que seguir? Si la respuesta es no, la estás tomando ahora. Sube de modelo.
Tres noes seguidos significan que el modelo de gama media te vale. En mi curso, eso fue doce veces de quince.
Conclusión
Opus 5 es mejor modelo que Opus 4.8. No lo discuto. Discuto que eso importe tanto como se está contando.
En quince tareas lo usé tres veces, y las tres por motivos que podía justificar antes de empezar, no después. El resto lo hizo un modelo más barato siguiendo convenciones escritas, con un pipeline que verifica lo verificable y con un humano leyendo cada tarea antes de ejecutarla y cada resultado antes de darlo por cerrado.
Si el código que te genera la IA da miedo revisarlo, el problema no es el modelo que estás usando.
Si quieres montar esto
Todo lo que he contado —el entorno, el pipeline, el sistema de contexto y el método de spec, plan y tareas— está en la ruta Desarrollo Laravel asistido por IA: del setup al Spec-Driven Development. Son cinco cursos en orden, de la arquitectura al método, y el proyecto que he ido mencionando se construye entero dentro.
Si vas directo al grano: el entorno se monta en Setup Profesional Laravel + IA y el método está en Spec-Driven Development en Laravel con IA, que son los dos últimos cursos de la ruta.
Y si todavía andas peleándote con la herramienta, empieza por el curso escrito de Claude Code.
Para seguir con el tema:
Curso Laravel 12
Completo 2026
El único curso 100% actualizado que incluye Laravel 12, Livewire 3, Vue 3, React 19 e Inertia 2. Aprende con proyectos reales y las últimas funcionalidades.
star Incluido en cualquier suscripción
Rutas de aprendizaje
