Un lloc Drupal no s’acaba el dia que es publica: comença. Durant anys caldrà aplicar actualitzacions de seguretat, adaptar el codi propi a cada versió major, revisar rendiment i permisos, i continuar desenvolupant sobre una base que no deixa de moure’s. Aquí és on una web es degrada en silenci, o on continua rendint anys després.
Quan vam decidir integrar la intel·ligència artificial en el nostre treball, la pregunta de partida va ser quina part del nostre mètode guanyaria en profunditat i cobertura si l’executés un sistema que no es cansa de comprovar. El resultat recorre el cicle de vida complet: coneixement de base, auditoria, desenvolupament, dependències i migració de versió.
La IA executa, la metodologia és nostra
Obrir un xat amb un model de llenguatge i demanar-li codi serveix per a una demostració. Mantenir durant anys una plataforma de la qual depèn un negoci demana una altra cosa: un model genèric desconeix les convencions del projecte, cita APIs que ja no existeixen i no respon davant de ningú de les seves decisions.
Per això cada procés (auditar, desenvolupar, actualitzar, migrar) l’escriu el nostre equip com una metodologia explícita: quins passos es fan, què es comprova abans d’avançar, què s’entrega i qui aprova. Els agents l’executen sense reinterpretar-la ni saltar-se-la, perquè en cada punt crític hi ha una comprovació automàtica o una persona que dona el vistiplau. La metodologia, el coneixement i els criteris de qualitat no viuen al motor d’IA ni en depenen: viuen al nostre sistema, versionats i sota el nostre control.
Una base de coneixement Drupal verificada, no recordada
El punt feble de qualsevol IA aplicada a Drupal és el coneixement de versió. Drupal publica dues versions menors l’any, depreca APIs a cadascuna i retira el que s’ha deprecat a la versió major següent. Un model entrenat amb documentació de fa dos anys barreja Drupal 9, 10 i 11 sense saber-ho.
Hem construït una base de coneixement pròpia per versió major, de Drupal 8 a 11 i amb Drupal 12 en preparació: APIs PHP, hooks, plugins, Twig i theming, JavaScript, estàndards de codi, deprecacions per versió menor, el que va retirar cada versió major en arribar i la cadena d’eines que correspon a cada salt. Cada dada està contrastada amb el codi font de Drupal core, datada i amb la seva font. Quan un agent necessita saber com es fa alguna cosa a Drupal 11.2, ho consulta en lloc de recordar-ho, i una correcció a la base arriba a tots els processos alhora.
Auditoria: 12 eixos i un diagnòstic que no corregeix
Un Drupal en producció canvia cada mes, encara que l’hàgim construït nosaltres. Abans de qualsevol intervenció, el primer és saber en quin estat està. La nostra auditoria l’analitza en 12 eixos: plataforma i cicle de suport, actualitzacions pendents i vulnerabilitats conegudes, pedaços i la seva vigència, mòduls instal·lats i mòduls que falten, qualitat del codi propi, contingut i configuració, tema i frontend, rendiment i memòria cau, permisos i rols, salut operativa, recorregut funcional per tipus de contingut i per rol d’usuari, i SEO tècnic.
Creua tres fonts: el codi del projecte, el panell d’administració de preproducció o producció, recorregut amb un navegador real i sessió iniciada, i la línia d’ordres de Drupal sobre una rèplica local en contenidors. Cada troballa es classifica per severitat i esforç i arriba en un doble backlog: un per a tu, en llenguatge de negoci, i un altre d’intern amb el detall tècnic.
La diferència pràctica respecte a una auditoria a mà és la cobertura. Un equip humà fa mostreig: els permisos més sensibles, els mòduls més crítics. El sistema revisa cada permís, cada ruta per rol i cada API deprecada, i una persona del nostre equip valida les troballes i decideix què importa.
I una decisió de disseny important: l’auditoria només diagnostica. Cada troballa es deriva al procés especialitzat que l’ha de resoldre, cosa que evita l’error clàssic d’arreglar de passada alguna cosa que ningú ha validat.
Desenvolupament: cinc fases i un revisor adversarial
Escriure codi propi de Drupal és on més aporta la IA i on més mal fa sense mètode. El nostre procés de desenvolupament assistit segueix cinc fases.
Les cinc fases del desenvolupament assistit
Cap línia s'escriu sense un pla aprovat per una persona ni es dona per bona sense passar les comprovacions automàtiques.
L'agent treballa sempre sobre una rèplica local del projecte, mai sobre producció.
Abans de proposar res, estudia el codi existent, separa el que ha verificat del que només ha inferit i declara els seus supòsits. En projectes grans construeix un graf del codi propi, amb els seus components i dependències, per no perdre's.
Redacta un pla amb criteris d'acceptació verificables i decisions d'arquitectura registrades. Sense l'aprovació literal d'un desenvolupador del nostre equip, no s'executa.
Primer s'escriu la prova que ha de fallar; després el codi, en blocs petits que passen els estàndards de codi de Drupal, l'anàlisi estàtica i les proves unitàries.
Es comprova la definició de «fet» amb dades reals i en un navegador real, i un segon agent actua com a revisor adversarial: el seu únic objectiu és trobar el que el primer ha fet malament.
El mateix mètode funciona en mode revisió sobre codi ja escrit, sigui nostre o heretat d’un altre proveïdor.
Dependències, pedaços i migracions de versió
Un projecte Drupal típic arrossega desenes de mòduls contribuïts i, sovint, pedaços sobre core o contrib que poden deixar d’aplicar-se en el pitjor moment. Mantenim un registre central de versions validades, amb els pedaços que funcionen a cadascuna i les proves que els comproven. Sobre aquest registre, els agents substitueixen o retiren pedaços, els generen a partir de les propostes de correcció de la comunitat, detecten paquets desactualitzats i vulnerabilitats conegudes, i pugen versions només quan passen una verificació prèvia. El que s’aprèn en un projecte (un pedaç que cal substituir, una incompatibilitat, una versió que funciona) s’anota al registre i beneficia el següent. En acabar, reps un resum d’actuacions: què s’ha canviat, per què i amb quin resultat.
Saltar de versió major és el moment de més risc en la vida d’un lloc, i el codi propi és el que més pateix: APIs retirades, serveis que canvien de signatura, plantilles i JavaScript que deixen de funcionar. El nostre procés de migració combina refactorització automàtica amb Rector, anàlisi estàtica amb PHPStan al nivell de la versió objectiu, verificació de compatibilitat de totes les dependències, revisió de qualitat del codi i validació del projecte migrat en un entorn real. La base de coneixement diu quina eina i quina configuració corresponen a cada salt. I si el teu equip continua pujant codi mentre migrem, el procés reconcilia aquests canvis amb el que ja està migrat.
Per què la IA no decideix per nosaltres
Quatre garanties de control
El que fa diferent aquest sistema no és el que la IA pot fer, sinó el que no pot fer sense nosaltres.
Cap pla s'executa, cap canvi arriba al repositori i res s'envia a l'exterior sense que una persona del nostre equip ho autoritzi, cada vegada.
Quan un agent diu «fet», uns scripts deterministes ho comproven: anàlisi estàtica, proves, recomptes, connexions. Si la comprovació falla, no està fet.
L'agent treballa amb la nostra base contrastada amb Drupal core i amb el nostre registre de versions validades, no amb el que recorda.
Cada error detectat es converteix en una regla escrita que s'incorpora al pas del mètode on s'aplica, en termes genèrics i sense dades de cap client.
Les teves dades, credencials i bolcats de base de dades no formen mai part del sistema: les metodologies són genèriques i l’estat de cada projecte viu al propi projecte.
Què canvia per al teu projecte, i què no
Canvia la cobertura: una auditoria o una migració ja no es basen en una mostra, sinó en la revisió completa del que hi ha. Canvia la traçabilitat: cada decisió, verificació i aprovació queden registrades i creuades amb l’historial del codi, de manera que pots demanar-nos el perquè de qualsevol canvi, també mesos després. I canvia la memòria: cada projecte conserva un índex del seu estat, les seves decisions i els seus pendents, de manera que una sessió de treball reprèn on la va deixar l’anterior, i el teu projecte hereta el que s’ha après en els anteriors.
No canvia qui en respon. El pla l’aprova un desenvolupador nostre, el diagnòstic el prioritza una persona i la responsabilitat sobre el que s’entrega continua sent de l’equip. El que contractes és aquest criteri i aquesta responsabilitat, amb un sistema al darrere que els fa més exhaustius.
El que contractes és aquest criteri i aquesta responsabilitat, amb un sistema al darrere que els fa més exhaustius.
Fonts
- Drupal Association, Drupal core release cycle, drupal.org — calendari de versions menors i majors i política de deprecacions.
- Rector, Drupal Rector, drupal.org/project/rector — refactorització automàtica de deprecacions per versió.
- PHPStan, phpstan-drupal, GitHub — anàlisi estàtica amb regles específiques de Drupal.