El vibe coding funciona bé al principi. Els problemes arriben quan el projecte ja és a producció i alguna cosa falla. Llavors et trobes amb això:
- Codi que ningú recorda haver escrit i que ningú sap què fa.
- Cap test que cobreixi aquest codi.
- Por de tocar res, perquè no saps què es trencarà.
L’enginyeria agèntica és l’alternativa. És un conjunt d’eines i pràctiques per fer servir la IA (intel·ligència artificial) de manera integrada i controlada durant tot el projecte. A l’ecosistema Laravel en destaquen 3: Laravel Boost, Pest 5 i Rector.
Dues maneres molt diferents d’utilitzar la mateixa IA
El vibe coding és conversacional. Descrius el que vols, acceptes el que surt i itères fins que funciona. És molt ràpid per prototipar, però consumeix molts recursos: el model ha de deduir les relacions i la lògica del codi, i gairebé mai coneix el projecte sencer. No hi estem en contra: a Volcanic l’hem fet servir, i per això en coneixem els límits.
L’enginyeria agèntica és una altra cosa. No serveix només per escriure codi més ràpid: serveix per mantenir la coherència del projecte. L’agent escriu codi dins de límits clars, valida automàticament el que produeix i deixa el control en mans d’una persona a cada pas. Tot i així, cada equip decideix quanta IA vol fer servir i en quin moment.
Laravel Boost: context real per a l’agent
Quan un agent no coneix el teu projecte, s’inventa noms de classes. De vegades també s’inventa columnes o taules de la base de dades. Això s’anomena al·lucinació.
Per evitar-ho fem servir Laravel Boost (documentació en Anglès), un paquet oficial que dona a un agent generalista context sobre la teva aplicació.
Boost exposa un servidor MCP (Model Context Protocol: l’estàndard que connecta agents d’IA amb eines externes) amb més de 15 eines: introspecció de models Eloquent, esquema de la base de dades, rutes, Tinker i logs. També inclou una API (interfície perquè dos programes es comuniquin) de documentació amb més de 17.000 fragments de l’ecosistema Laravel. La cerca és semàntica i s’ajusta a les versions que tens instal·lades. Amb Boost, l’agent deixa d’endevinar.
Boost també desa les convencions del teu equip. Amb l’eina record-rule les escriu a
.ai/rules, dins del control de versions. Així, una regla com «els imports es guarden com a enters en
cèntims, mai com a float» deixa de ser un comentari en una revisió de codi i passa a ser una restricció del sistema.
Aquest fitxer és, a la pràctica, la memòria de l’equip.
Pest 5: tests que validen l’agent
Per als tests fem servir Pest 5 (documentació en Anglès). Pest 5 porta 3 peces que canvien el flux de treball.
El plugin Agent dona a l’agent una ordre per comprovar si el seu canvi funciona de veritat.
L’ordre s’executa dins de l’entorn de test real, amb factories, RefreshDatabase i els fakes de Laravel.
El motor TIA (Test Impact Analysis: detecta a quins tests afecta cada canvi) torna a executar només els tests afectats i reaprofita la resta des de la memòria cau. La cobertura no perd fidelitat. La suite de Laravel Cloud, amb més de 19.000 tests, va passar de 3 minuts a 5 segons.
El plugin Evals puntua les sortides d’un LLM (large language model: model
gran de llenguatge) amb la mateixa API expect() de sempre. Combina comprovacions deterministes amb
scorers del tipus LLM-as-judge, on un altre model avalua la resposta:
toBeRelevant(), toBeFactual(), toBeSafe(), toHaveToolCalls() i
toFollowTrajectory(). Els evals només s’executen quan passes --evals, així que no
encareixen la CI (integració contínua) del dia a dia.
Rector + agent: el que és mecànic i el que no
En projectes legacy combinem 2 eines. Rector (documentació en Anglès) s’encarrega de les transformacions mecàniques i deterministes: pujar de versió, afegir tipatges i normalitzar la sintaxi. L’agent entra només on Rector no pot raonar. Per exemple: extreure un servei d’un controlador de 900 línies, trencar una dependència circular o escriure els tests que falten abans de tocar res. Pest 5 ja inclou plugins de primera part per a Rector i PHPStan, així que les 3 peces viuen a la mateixa ordre.
Què revisa sempre una persona
Cap d’aquestes eines substitueix la revisió humana. La nostra regla és simple: l’agent pot proposar qualsevol canvi, però 3 tipus de canvi necessiten la signatura d’una persona concreta.
- Migracions que toquen dades existents.
- Canvis en autenticació, permisos o pagaments.
- Qualsevol accés a dades personals.
Hi ha una regla més, menys vistosa però igual d’important: l’agent no té credencials de producció. Treballa sempre contra entorns de desenvolupament amb dades anonimitzades. En un projecte de client això no és una preferència tècnica: és compliment normatiu.
Has de fer servir agents al teu projecte Laravel? 5 preguntes
Respon aquestes 5 preguntes abans d’invertir-hi un euro.
- Tens tests? Si no en tens, comença per aquí. Un agent sense una suite de tests genera deute tècnic molt de pressa.
- Saps quant triga avui un canvi a arribar a producció? Mesura aquest temps abans de començar. Sense línia base no pots calcular el ROI (retorn de la inversió): només tens sensacions.
- Qui signa cada canvi? Defineix qui aprova què abans de donar accés a l’agent.
- Quines dades toca l’agent? Si toca dades personals, sanitàries o financeres, l’entorn de treball de l’agent canvia completament.
- Tens un problema de velocitat o de claredat? Els agents acceleren l’execució. Si l’abast està mal definit, l’executen més ràpid i pitjor. Defineix primer l’abast.
T’has reconegut en alguna d’aquestes preguntes, sobretot en la de l’abast? Parlem-ne. A Volcanic ajudem equips amb Laravel a producció a decidir on fer servir agents i on no. Si t’encaixa, escriu-nos i ho veiem plegats.