De Ion Anghel · Aprilie 2026
Un CTO m-a sunat trimestrul trecut. Pitch-ul lui, în mare: „Suntem în urmă pe AI. Vreau toți inginerii pe Copilot până la sfârșitul lunii și vreau să văd velocitatea crescând." I-am pus trei întrebări. Aveți teste? „Unele." Aveți CI care blochează merge-uri proaste? „Cumva." Când a făcut ultima dată un senior un code review serios la PR-ul unui junior? Pauză lungă.
Nu avea o problemă de AI. Avea o problemă de codebase, o problemă de proces și o problemă de hiring stivuite una peste alta. Cumpărarea de licențe Copilot urma să le facă pe toate trei mai grave, mai repede.
Vreau să fiu clar de la început, pentru că restul articolului va suna ca scepticism și nu este: cred că ingineria asistată de AI este una dintre cele mai importante schimbări din meseria noastră din ultimii douăzeci de ani. O folosesc zilnic. Livrez mai mult datorită ei. Articolul ăsta nu spune că AI este supravândut — spune că AI este vândut ca soluție pentru probleme pe care nu le rezolvă, iar confuzia asta costă echipele bani reali.
AI este un amplificator, nu un instrument de reparat
Modelele mari de limbaj, și agenții construiți peste ele, fac un lucru foarte bine: continuă pattern-urile pe care le văd. Dă-i un modul curat, cu denumiri consistente, tipuri bune și teste alături, și îl va extinde în același spirit. Dă-i un controller de 200 de linii cu trei stiluri diferite de error handling, un singleton global mutabil și concatenare de string-uri SQL, și îți va produce fidel mai mult din exact asta. Modelul nu o să se opună și să zică „de fapt, clasa asta are prea multe responsabilități, dă-mi voie să refactorizez întâi." O să se conformeze camerei.
Asta e partea peste care nimeni nu insistă în pitch-ul comercial. AI nu are gust despre codebase-ul tău. Are statistici despre codebase-ul tău. Dacă statisticile sunt proaste, output-ul e prost — doar că acum e mai mult, și ajunge în producție mai repede.
Se simte chestia asta în orice monorepo cu ceva vechime. Pune un agent pe un modul legacy și uită-te la ce iese: cod scris cu siguranță, care pare plauzibil, folosește helperele existente, urmează anti-pattern-urile existente și trece testele slabe existente. CI-ul e verde. PR-ul e mic. Se merge. Șase săptămâni mai târziu, păgești pe cineva la 2 dimineața din cauza unei race condition pe care agentul nu avea de unde s-o știe, într-un sistem pe care agentul nu avea cum să-l modeleze.
Soluția aici nu e să interzici agentul. Soluția e să recunoști că, de fapt, codebase-ul nu putea duce velocitatea aceea din capul locului.
Securitatea e locul unde doare prima dată
De-a lungul anilor, am făcut audituri pe destul de multe platforme web mici-spre-medii și aceleași câteva probleme apar aproape de fiecare dată. Chei de API commitate în git, deseori descoperibile în istoricul public. Fișiere .env servite din web root pentru că cineva a configurat greșit o regulă de director. Webhook-uri care acceptă orice POST pentru că verificarea de semnătură era „TODO." Input de utilizator care curge neatins în SQL, sau în comenzi shell, sau în template string-uri pe care framework-ul le randează vesel ca HTML. Flag-uri de consimțământ GDPR care există în UI, dar nu sunt citite niciodată pe backend.
Niciuna dintre aceste probleme nu a fost creată de AI. Ele preced AI-ul cu decenii. Dar iată ce schimbă AI: scade dramatic costul de a adăuga cod nou, iar majoritatea echipelor nu au o investiție corespunzătoare în a crește costul de a adăuga cod nesigur. Așa că aceleași pattern-uri sunt reproduse, mai rapid. Agentul vede că controllerele existente nu validează input, și scrie un controller nou care nu validează input. Agentul vede că secretele sunt încărcate dintr-un .env ținut în git, și folosește încrezător pattern-ul ăla într-un serviciu nou. Agentul nu e nesăbuit. Este consistent. Cu un codebase care era deja nesăbuit.
Am scris despre o versiune specifică a acestui mod de eșec în From Vibe Coding to Insecure Keys — un proiect dus de la prompt la producție într-un weekend, cu credențiale stând în bundle-ul de browser. Nu e un bug de AI. E un gol de proces pe care AI-ul l-a făcut suficient de ieftin încât să fie expus la scară.
Fără teste și fără CI, velocitatea e doar risc
E o conversație pe care o tot am cu lideri de inginerie. Vor să măsoare adopția de AI prin numărul de PR-uri, sau prin linii de cod, sau prin ticket-uri Jira închise. Toate astea măsoară un singur lucru: cât de repede bagi cod în sistem. Niciuna nu măsoară dacă acel cod ar fi trebuit să intre.
Dacă nu ai teste, nu ai feedback. Dacă nu ai CI care rulează acele teste la fiecare schimbare și blochează merge-ul la eșec, nu ai plasă de siguranță. Dacă nu ai code review în care un al doilea om citește efectiv diff-ul și pune presiune, nu ai filtru de calitate. Pune un agent AI peste asta, și ce ai construit este un traseu mai rapid de la idee la incident.
Echipele care obțin pârghie reală din AI nu sunt cele care l-au adoptat cel mai agresiv. Sunt cele care aveau deja partea plictisitoare la locul ei — o suită de teste care rulează în mai puțin de zece minute, un pipeline de deploy din care poți face rollback dintr-un click, alerting care pagește un om înainte ca utilizatorii să apuce să dea tweet. AI comprimă munca dintre garduri. Nu înlocuiește gardurile.
„Vibe coding" nu scalează dincolo de demo
Există un mod de lucru — rapid, conversațional, în mare parte cu încredere în model — care e cu adevărat minunat pentru prototipuri, unelte interne, proiecte de weekend, învățat stack-uri noi. O fac constant. Așa pornesc multe software-uri utile.
Este, însă, catastrofal de nepotrivit pentru orice sistem care manevrează date reale de utilizatori, bani, sau credențiale ale unor terți, deployat de cineva care nu o să citească personal fiecare linie înainte să ajungă în producție. Motivul nu este că modelul e prost. Motivul este că „vibe coding" oprește deliberat verificările — nu citești diff-ul atent, nu gândești adversarial despre input, nu te întrebi „ce se întâmplă dacă pică". Verificările astea sunt exact ce-i trebuie codului de producție mai mult, nu mai puțin.
Greșeala pe care unele companii o fac în 2026 este să ia un workflow grozav pentru un hackathon și să încerce să conducă o afacere cu el. Nu se poate.
Problema reală aproape niciodată nu este tehnologică
Iată observația incomodă la care tot ajung. Când o echipă de leadership cumpără o flotă de unelte AI ca să-și „transforme" organizația de inginerie, AI-ul deseori nu este achiziția reală. Achiziția reală este evitarea a trei conversații mult mai grele.
Prima e despre datoria tehnică — genul ăla care cere să spui cu voce tare, în fața board-ului, că platforma pe care o sărbătoriți de cinci ani are putregai dedesubt și că cineva trebuie să petreacă un trimestru curățând-o. A doua e despre angajări — că ștacheta a coborât, că sunt oameni în echipă care nu ar fi trebuit angajați sau promovați, și că nicio cantitate de tooling nu repară o echipă care nu știe cum arată „bine". A treia e despre standarde — că organizația nu a căzut niciodată de acord ce înseamnă „gata", ce testare e obligatorie, ce trebuie să prindă efectiv un review, și că toți au funcționat pe gust personal ani de zile.
AI este vândut ca o cale de a evita aceste conversații. Nu este. Este doar o cale de a face consecințele lor să ajungă mai repede.
Când AI își merită locul
Vreau să termin cu ce funcționează, pentru că funcționează multe.
Pe un codebase sănătos — cu module bine delimitate, tipuri decente, o suită de teste reală, observabilitate pe care chiar o poți citi — asistența AI este cu adevărat transformatoare. Un refactor pe zeci de fișiere devine o treabă de jumătate de oră în loc de un sprint. Scrierea de teste pentru cod deja bine structurat devine plăcută, nu plictisitoare. Documentația pe care nimeni nu avea timp s-o scrie e generată și apoi tăiată la esențial. Code review-ul capătă o pereche de ochi în plus care nu obosește și prinde clasa aceea de greșeli plictisitoare pe care oamenii le ratează la ora 5 după-amiaza. Analiza exploratorie pe un set de date pe care nu l-ai mai atins devine o conversație, nu o după-amiază de Stack Overflow.
În fiecare dintre aceste cazuri, pârghia vine din aceeași sursă: fundația era suficient de solidă încât modelul să amplifice în direcția corectă. AI nu a reparat nimic. A accelerat o muncă deja corectă.
Ce să faci luni dimineață
Dacă urmează să rulezi tooling AI peste toată organizația ta de inginerie, iată singurul lucru pe care ți-aș cere să-l faci înainte. Deschide ultimele trei incidente din producție și citește postmortem-urile onest. Au fost cauzate de ceva ce un LLM ar fi putut preveni — o tastare greșită, un null check uitat, un import lipsă? Sau au fost cauzate de ceva mai structural — niciun test pe acel path, niciun alerting pe acel semnal, niciun review pe acel PR, un serviciu pe care nimeni de pe oncall nu-l înțelegea?
Dacă e a doua categorie — și aproape întotdeauna este — atunci cel mai mare câștig pe care îl poți face în trimestrul ăsta nu este un rollout de Copilot. Este o suită de teste care rulează pe fiecare PR. Este o pagină scrisă care definește ce înseamnă „gata" pentru echipa ta. Sunt douăzeci de minute de pereche între un senior și un junior pe code review, în fiecare săptămână, până când ștacheta devine comună.
Fă asta, și apoi adu AI-ul. Va plăti înzecit, pentru că va avea, în sfârșit, ceva ce merită amplificat.
Disclaimer: sunt bullish pe AI. Cred că majoritatea muchiilor aspre pe care le descriu vor fi netezite în următorii ani și cred că inginerii care învață să lucreze alături de aceste unelte vor livra cu mult mai mult decât cei care nu o fac. Dar drumul spre acel viitor trece prin disciplină inginerească, nu pe lângă ea. Echipele care vor câștiga cu AI vor fi cele care câștigau deja fără el — iar echipele care sunt sparte astăzi vor fi sparte mai repede, mai scump, și în fața mai multor clienți.