El vibe coding funciona bien al principio. Los problemas llegan cuando el proyecto ya está en producción y algo falla. Entonces te encuentras con esto:
- Código que nadie recuerda haber escrito y que nadie sabe qué hace.
- Ningún test que cubra ese código.
- Miedo a tocar cualquier cosa, porque no sabes qué se va a romper.
La ingeniería agéntica es la alternativa. Es un conjunto de herramientas y prácticas para usar la IA (inteligencia artificial) de forma integrada y controlada durante todo el proyecto. En el ecosistema Laravel destacan 3: Laravel Boost, Pest 5 y Rector.
Dos formas muy distintas de usar la misma IA
El vibe coding es conversacional. Describes lo que quieres, aceptas lo que sale e iteras hasta que funciona. Es muy rápido para prototipar, pero consume muchos recursos: el modelo tiene que deducir las relaciones y la lógica del código, y casi nunca conoce el proyecto entero. No estamos en contra: en Volcanic lo hemos usado, y por eso conocemos sus límites.
La ingeniería agéntica es otra cosa. No sirve solo para escribir código más rápido: sirve para mantener la coherencia del proyecto. El agente escribe código dentro de límites claros, valida de forma automática lo que produce y deja el control en manos de una persona en cada paso. Aun así, cada equipo decide cuánta IA quiere usar y en qué momento.
Laravel Boost: contexto real para el agente
Cuando un agente no conoce tu proyecto, se inventa nombres de clases. A veces también se inventa columnas o tablas de la base de datos. A esto se le llama alucinación.
Para evitarlo usamos Laravel Boost (documentación en inglés), un paquete oficial que da a un agente generalista contexto sobre tu aplicación.
Boost expone un servidor MCP (Model Context Protocol: el estándar que conecta agentes de IA con herramientas externas) con más de 15 herramientas: introspección de modelos Eloquent, esquema de la base de datos, rutas, Tinker y logs. También incluye una API (interfaz para que dos programas se comuniquen) de documentación con más de 17.000 fragmentos del ecosistema Laravel. La búsqueda es semántica y se ajusta a las versiones que tienes instaladas. Con Boost, el agente deja de adivinar.
Boost también guarda las convenciones de tu equipo. Con la herramienta record-rule las escribe en
.ai/rules, dentro del control de versiones. Así, una regla como «los importes se guardan como enteros
en céntimos, nunca como float» deja de ser un comentario en una revisión de código y pasa a ser una restricción del
sistema. Ese fichero es, en la práctica, la memoria del equipo.
Pest 5: tests que validan al agente
Para los tests usamos Pest 5 (documentación en inglés). Pest 5 trae 3 piezas que cambian el flujo de trabajo.
El plugin Agent da al agente un comando para comprobar si su cambio funciona de verdad. El comando
se ejecuta dentro del entorno de test real, con factories, RefreshDatabase y los fakes de Laravel.
El motor TIA (Test Impact Analysis: detecta a qué tests afecta cada cambio) reejecuta solo los tests afectados y reutiliza el resto desde la caché. La cobertura no pierde fidelidad. La suite de Laravel Cloud, con más de 19.000 tests, pasó de 3 minutos a 5 segundos.
El plugin Evals puntúa las salidas de un LLM (large language model: modelo
grande de lenguaje) con la misma API expect() de siempre. Combina comprobaciones deterministas con
scorers del tipo LLM-as-judge, donde otro modelo evalúa la respuesta:
toBeRelevant(), toBeFactual(), toBeSafe(), toHaveToolCalls() y
toFollowTrajectory(). Los evals solo se ejecutan cuando pasas --evals, así que no
encarecen la CI (integración continua) del día a día.
Rector + agente: lo mecánico y lo que no
En proyectos legacy combinamos 2 herramientas. Rector (documentación en inglés) se encarga de las transformaciones mecánicas y deterministas: subir de versión, añadir tipados y normalizar la sintaxis. El agente entra solo donde Rector no puede razonar. Por ejemplo: extraer un servicio de un controlador de 900 líneas, romper una dependencia circular o escribir los tests que faltan antes de tocar nada. Pest 5 ya incluye plugins de primera parte para Rector y PHPStan, así que las 3 piezas viven en el mismo comando.
Qué revisa siempre una persona
Ninguna de estas herramientas sustituye la revisión humana. Nuestra regla es simple: el agente puede proponer cualquier cambio, pero 3 tipos de cambio necesitan la firma de una persona concreta.
- Migraciones que tocan datos existentes.
- Cambios en autenticación, permisos o pagos.
- Cualquier acceso a datos personales.
Hay una regla más, menos vistosa pero igual de importante: el agente no tiene credenciales de producción. Trabaja siempre contra entornos de desarrollo con datos anonimizados. En un proyecto de cliente esto no es una preferencia técnica: es cumplimiento normativo.
¿Deberías usar agentes en tu proyecto Laravel? 5 preguntas
Responde estas 5 preguntas antes de invertir un euro.
- ¿Tienes tests? Si no los tienes, empieza por ahí. Un agente sin una suite de tests genera deuda técnica muy rápido.
- ¿Sabes cuánto tarda hoy un cambio en llegar a producción? Mide ese tiempo antes de empezar. Sin línea base no puedes calcular el ROI (retorno de la inversión): solo tienes sensaciones.
- ¿Quién firma cada cambio? Define quién aprueba qué antes de dar acceso al agente.
- ¿Qué datos toca el agente? Si toca datos personales, sanitarios o financieros, el entorno de trabajo del agente cambia por completo.
- ¿Tienes un problema de velocidad o de claridad? Los agentes aceleran la ejecución. Si el alcance está mal definido, lo ejecutan más rápido y peor. Define primero el alcance.
¿Te has reconocido en alguna de estas preguntas, sobre todo en la del alcance? Hablemos. En Volcanic ayudamos a equipos con Laravel en producción a decidir dónde usar agentes y dónde no. Si te encaja, escríbenos y lo vemos.