Perspective

Clienții care rulează platforme Drupal enterprise au încetat să mai întrebe dacă AI-ul poate scrie cod. Întrebarea pe care o primim acum e mai îngustă și mult mai utilă: scurtează timpul dintre „site-ul se comportă ciudat” și „știm de ce”?

Asta e o întrebare despre economia mentenanței, nu despre înlocuirea dezvoltatorilor. Pe o platformă live de șase ani, cu patruzeci de module contrib și trei generații de cod custom moștenit, diagnosticul consumă orele. Rezolvarea e de obicei scurtă, odată ce știi ce anume repari.

Folosim Claude ca parte din bucla asta de diagnostic în proiecte Drupal de producție de aproape un an. Urmează o relatare onestă: unde își merită locul, unde induce în eroare cu aplomb și ce garduri de protecție fac diferența.

Ce prinde repede

Tiparul e constant: AI-ul e puternic acolo unde răspunsul există deja în textul pe care i-l dai și slab acolo unde răspunsul stă în starea de runtime sau în baza de date.

• Stack trace-uri și ecrane albe. Îi dai un backtrace de WSOD împreună cu intrările dblog din jur și fișierul de modul relevant și primești în câteva secunde o listă ordonată de cauze probabile. E cea mai valoroasă utilizare. Un dezvoltator senior ajunge la aceeași concluzie — doar cu cincisprezece minute mai târziu, după ce parcurge mental lanțul de apeluri.
• Lanțuri de invalidare a cache-ului. Metadatele de cache din Drupal sunt greu de ținut în minte: contexte, tag-uri și max-age se compun peste render array-uri, iar un tag lipsă la trei niveluri în adâncime produce conținut vechi departe de codul vinovat. Dacă îi dai render array-ul și entitatea implicată, urmărește compunerea asta corect.
• Patologii de interogare în Views. Cu un slow query log alături de configurația exportată a View-ului, identifică tiparul N+1, relația lipsă sau filtrul care a forțat un full scan. Citește bine output-ul de EXPLAIN.
• Ordinea hook-urilor și interferențele. Când două module implementează același hook de alterare, iar rezultatul depinde de weight, descrierea simptomului plus cele două implementări scot de obicei coliziunea la iveală imediat.
• API-uri deprecate. Înaintea unui upgrade major, e rapid și corect la semnalarea API-urilor eliminate din modulele custom și la explicarea înlocuitorului — o muncă sincer plictisitoare, făcută bine.

Unde greșește

Astea sunt moduri de eșec pe care le-am lovit efectiv, nu teoretice. Fiecare ne-a costat timp până am învățat să proiectăm în jurul lor.

• Starea de configuration sync. AI-ul nu vede ce e în configurația activă față de YAML-ul exportat și nu o spune. Deduce o stare plauzibilă și raționează încrezător pornind de la ea. La bug-uri de configurație, sugestiile sunt frecvent greșite într-un mod care sună autoritar.
• Module contrib cu patch-uri. Modelul raționează despre versiunea publicată a unui modul. Dacă tu duci trei patch-uri peste el — și orice platformă Drupal veche o face — modelul lui despre acel fișier e greșit, iar nimic din conversație nu dezvăluie nepotrivirea.
• Orice ține de baza de date. Date de câmp orfane, migrări neterminate, revizii de entitate în stări inconsistente: nimic din toate astea nu e vizibil în cod, deci nu e vizibil pentru model.
• Drift între versiuni. Suprafața de API a Drupal s-a mișcat considerabil între versiunile majore recente. Uneori amestecă idiomuri din versiuni diferite în cod care arată corect și nu rulează. Spune întotdeauna versiunea exactă.
• Hook-uri și servicii inventate. Cel mai periculos eșec, fiindcă e cel mai plauzibil. Nume de hook-uri și servicii care ar trebui să existe sunt produse cu încredere totală. Verifică orice API nefamiliar în codul real înainte să acționezi pe baza lui.

Regula care le unifică: e un bun raționator peste textul pe care i-l dai și un ghicitor nesigur despre starea pe care nu i-ai dat-o. Aproape toate rezultatele proaste vin din faptul că cineva a așteptat al doilea lucru.

Fluxul pe care îl folosim efectiv

Trei practici transformă cele de mai sus dintr-o curiozitate în ceva pe care suntem dispuși să-l facturăm.

Un fișier de context al proiectului. Aceeași abordare descrisă pentru Next.js și agenți AI se aplică direct la Drupal și contează mai mult aici, fiindcă convențiile Drupal sunt mai greu de ghicit. Al nostru consemnează versiunea exactă de core, modulele contrib cu patch-uri și ce fac acele patch-uri, namespace-urile modulelor custom, dacă config sync e autoritativ și stack-ul de development local. Elimină o categorie întreagă de răspunsuri greșite înainte să fie produse.

Dovezi înaintea opiniei. Nicio conversație de diagnostic nu începe cu descrierea simptomului în proză. Începe cu artefacte: output-ul drush watchdog:show, drush config:status relevant, fișierul real, interogarea reală. Descrierile în proză sunt locul prin care se strecoară presupunerile umane, iar modelul le adoptă în bloc.

Reproduci, apoi repari. O cauză propusă rămâne ipoteză până e reprodusă local. Sună evident și e pasul cel mai des sărit, fiindcă o explicație sigură pe ea seamănă cu un diagnostic încheiat. Nu este.

Ce nu delegăm niciodată

O parte din muncă rămâne integral umană, iar granița nu ține de capabilitate — ține de ce se întâmplă când rezultatul e greșit.

• Alerte de securitate. Patch-urile sunt citite și aplicate de un om. Raza de explozie a unui răspuns greșit dar sigur pe el e întreaga platformă.
• Upgrade-uri de versiune majoră. AI-ul ajută enorm la inventarul de deprecări; nu conduce upgrade-ul.
• Migrări de date. Orice scrie în datele de producție, unde o transformare subtil greșită e descoperită săptămâni mai târziu și e scumpă sau imposibil de întors.
• Orice atinge date personale. Conținutul de producție cu date cu caracter personal nu intră într-un prompt. Reproduci cu date sintetice.

Ce schimbă de fapt

Rezumatul onest e neglamuros: comprimă diagnosticul, iar diagnosticul e cea mai mare parte din cost. Investigații care consumau o după-amiază se închid frecvent în sub o oră. Rezolvarea durează exact cât a durat mereu, review-ul e neschimbat, iar disciplina de deployment e neschimbată.

Ce nu face este să reducă expertiza necesară. Fiecare mod de eșec de mai sus e prins de cineva care știe Drupal suficient de bine încât să recunoască un răspuns greșit — și e invizibil pentru cineva care nu știe. Folosit de o echipă fără experiență Drupal solidă, instrumentul ăsta produce modificări sigure pe ele, plauzibile și greșite mai repede decât înainte. E o poziție mai proastă decât să nu-l folosești deloc.

De asta îl tratăm ca pe un multiplicator peste o capabilitate de mentenanță existentă, nu ca pe un înlocuitor al ei. Dacă evaluezi cum să menții sănătoasă o platformă Drupal după lansare, abordarea noastră pentru a rula Drupal la scară mare și echipa de servicii gestionate acoperă partea operațională. Scrie-ne dacă vrei să discutăm.