Lideri de opinie
Sistemele tale au deja puncte oarbe. AI le face doar mai grave.

În 2022, înainte ca instrumentele de codare generativă să facă parte din munca noastră zilnică de inginerie, am scris despre filosofia mea privind selecția uneltelor. A rezistat mai bine decât mă așteptam. Atunci, am susținut să începi cu problemele pe care le rezolvi efectiv, să cunoști slăbiciunile și să prioritizezi modul în care folosești uneltele, în loc să te arunci pe orice unealtă pare cea mai bună și să speri că va funcționa. Cunoaște-te pe tine însuți și obiectivele tale, pentru a-ți stabili așteptări corecte față de uneltele tale.
În acel moment, mă gândeam la proliferarea SaaS, nu la codul generat de AI. Dar astăzi filosofia mea este și mai urgentă și mai important de susținut.
Mulți dintre noi am citit raportul DORA 2025, care a constatat că, spre deosebire de anul precedent, adoptarea AI se corelează pozitiv cu productivitatea livrărilor. Constatarea subliniată a fost că instabilitatea livrărilor a continuat să crească și au testat dacă câștigurile de viteză le compensează. Nu o fac. Acest lucru se potrivește cu experiența noastră. Echipa noastră a adoptat dezvoltarea software agentică și a înregistrat o creștere de 48% a productivității în decurs de două trimestre, urmată de o creștere de 16% a problemelor de stabilitate. Zece persoane reprezintă un eșantion mic, dar este și un eșantion din care pot vedea imaginea completă, iar tiparul s-a menținut.
Adoptarea AI nu mai este cu adevărat o întrebare. Ești fie la început, fie în plin proces. Ce este diferit acum este că liderii de inginerie sunt așteptați să adopte AI și să demonstreze că aduce beneficii. CEO-ul, consiliul și finanțele doresc să știe cum să-și optimizeze investiția în AI. Ei întreabă dacă uneltele pe care le-ai ales rezolvă probleme reale eficient.
Diferența a fost mereu acolo. AI doar a făcut-o mai largă.
În calitate de CTO, îmi petrec o parte semnificativă din timp discutând cu alți lideri de inginerie, inclusiv clienți, potențiali clienți și colegi, pentru a compara realizările și nemulțumirile legate de ceea ce trăim cu AI. După suficiente astfel de conversații, am început să observ tipare în adoptarea AI și în rezultatele obținute.
Observația principală nu este a mea. DORA a subliniat acest aspect de doi ani: AI amplifică tot ceea ce se întâmplă deja în organizație, atât punctele forte, cât și slăbiciunile. O echipă cu o arhitectură curată și obiceiuri sănătoase de revizuire devine mai rapidă. O echipă care a gestionat o minge încâlcită de datorii tehnice suficient de mult pentru a livra codul constată acum că datoriile tehnice devin un obstacol major. Ceea ce această prezentare omite, totuși, este de ce surprinde atât de multe echipe. AI nu a ascuns aceste slăbiciuni; sistemele pe care ne-am bazat nu le-au adus niciodată în prim-plan.
Stiva de tichete și rapoarte pe care majoritatea organizațiilor de inginerie o folosesc a fost construită pentru a răspunde întrebărilor pe care oamenii le au, la viteza umană, de către persoane care înțelegeau aproximativ ce înseamnă „finalizat” pentru o anumită sarcină. Nu a fost niciodată un registru perfect. A fost întotdeauna o aproximație, completată de cineva care rezuma ceva mai complicat în spate. Acum, AI adaugă volum și noi intrări care generează activitate nouă. Niciunul dintre sistemele (sau uneltele) folosite pentru metodele tradiționale, non-AI de dezvoltare nu a fost conceput pentru asta.
Indiferent, rămânem responsabili pentru aceleași obiective. Tu încă controlezi viteza, calitatea, cheltuielile și modul în care echipa ta performează efectiv. Nu mai poți lua încredere pe bune tablourile de bord de anul trecut.
Există o obiecție justificată aici. raportul ROI DORA 2026 descrie o curbă J: o scădere a productivității imediat după adoptare, determinată de curba de învățare, costul verificării codului generat de AI și de procesele ulterioare care nu au ajuns la nivel. Ei o numesc „costul de taxă” al transformării și avertizează liderii să nu o confunde cu eșecul. Este corect. Dar costul de taxă și o problemă reală arată identic pe un tablou de bord construit din tichete. Dacă nu poți distinge în care dintre ele te afli, nu ești răbdător. Ghicești.
Trebuie să revenim la elementele de bază. Cunoaște-te pe tine însuți. Cunoaște-ți echipa. Cunoaște problemele pe care le rezolvi.
Cum îți poți „cunoaște pe tine însuți” cu AI?
Din discuțiile mele, am identificat cinci domenii principale în care sistemele convenționale, construite pentru munca generată și raportată de oameni, sunt oarbe. Ignorându-le, riști să amplifici slăbiciunile pe măsură ce continui să adopți AI.
Punct oarbă 1: Teatrul vitezei
Mai multe commit-uri și mai multe PR-uri pot părea progres și, adesea, sunt. AI crește ambele numere automat. A studiul de caz Stanford a arătat că adoptarea AI a crescut numărul de PR-uri cu 14%. Dar ceea ce ratezi este cât din acea activitate reprezintă lucru de funcționalitate livrată, comparativ cu mentenanță, refacere sau fluctuație cauzată de o refactorizare care nu a rezistat.
Pentru a aborda acest lucru, monitorizează proporția dintre lucrul de funcționalitate și mentenanță și urmărește frecvența de implementare și timpul de livrare în raport cu baza ta istorică, nu cu media industriei. Fără această separare, raportezi progres pe care nu îl poți susține efectiv.
Punct oarbă 2: Datorie de revizuire
Capacitatea de revizuire nu se scalează automat odată cu producția. Taxa de verificare nu este o fază pe care o depășești; este parte a costului permanent pentru dezvoltarea agentică. A sondaj recent al liderilor din inginerie a constatat că 80% dintre echipe cheltuiesc cel puțin 10% din timpul lor pe revizuire, și aproximativ una din zece cheltuie peste 40%. Sub această sarcină, echipele oscilează între un backlog în creștere și aprobări automate, și niciuna nu este o soluție reală.
Constrângerea privind livrarea nu mai este cât de repede este scris codul. Este cât de repede un om poate fi cu adevărat încrezător că o schimbare este corectă, cât de repede și precis defectele pot fi detectate și remediate. Urmărește cum sarcina de revizuire este distribuită în realitate în echipa ta; în caz contrar riști să supraîncarci inginerii seniori, să întârzie lansările sau să cauzezi probleme majore în producție.
Punctul nevăzut 3: Muncă ascunsă
Refactorizările și schimbările de arhitectură au tendința de a se ascunde în alte tichete, dacă apar în sistemul de tichete. AI produce mai mult din acest tip de muncă, nu mai puțin. Un agent nu ezită să atingă doisprezece fișiere pentru a rezolva un bug, în timp ce un om ar putea să se oprească și să regândească. Munca care sare peste sistemul de înregistrare sare și peste planificare, ceea ce înseamnă că modelul tău de capacitate este greșit, iar orice prognoză construită pe baza lui este, de asemenea, greșită.
Pentru a înțelege câtă muncă este într-adevăr realizată, trebuie să urmărești cât se schimbă efectiv în baza de cod și în istoricul pull request‑urilor. Fără asta, planul tău de capacitate se bazează pe ce oamenii și-au amintit să înregistreze, nu pe ceea ce au făcut cu adevărat.
Punctul nevăzut 4: Derapaj de calitate
Același sondaj a constatat că aproape jumătate dintre liderii din inginerie se luptă să detecteze probleme de securitate săptămână de săptămână. Complexitatea, duplicarea și dependențele care nu se potrivesc se acumulează în numeroase schimbări mici, individual rezonabile. Niciuna dintre ele nu pare alarmantă luată separat. În același studiu de caz Stanford, calitatea codului a scăzut cu 9% și variabilitatea sa s-a triplat. În timp ce media s‑a mișcat puțin, dispersia (partea pe care o observi) s‑a modificat mult. La volumul AI, acestea se compun mai repede decât majoritatea proceselor de revizuire le pot prinde. Derapajul tinde să apară ca o alertă on‑call legată de o dependență pe care nimeni nu și‑o amintește că a revizuit. Până când se întâmplă asta, există șanse mari ca un client să fi observat prima.
Urmărește tendințele privind descoperirile de securitate, dependențele și eșecurile și recuperările — nu commit‑ul individual. Complexitatea și duplicarea care se acumulează pe parcursul mai multor săptămâni contează mai mult decât orice schimbare singulară semnalată în revizuire. Fără asta, prinzi derapajul în același mod în care majoritatea echipelor încă o fac: după ce a provocat deja un incident.
Punctul nevăzut 5: Cheltuieli nevalidate
După ce adoptarea AI nu mai este subiect de dezbatere, cheltuielile AI și ROI devin întrebarea pe care toată lumea se concentrează. Finanțele vor să știe ce este capitalizabil versus operațional. Conducerea vrea să știe ce a rezultat din investiție. Majoritatea echipelor iau în continuare decizii privind instrumentele, licențele și numărul de angajați pe baza intuiției, nu pe baza dovezii legăturii dintre bani și munca livrată.
Urmărește unde curge efectiv efortul de inginerie în baza de cod, trimestru după trimestru — nu unde spune foaia de parcurs că ar trebui să curgă. Fără acea legătură, îți aperi bugetul pentru anul viitor cu anecdote, iar anecdotele nu rezistă unei discuții serioase cu CFO‑ul.
Începe cu ceea ce nu poți vedea
Întrebarea finanțelor privind cheltuielile capitalizate și o pagină on‑call la ora 2 dimineața par nelegate, dar nu sunt. Ambele pot fi „estimate aproximativ” din activitate. Dar ambele pot fi de fapt răspunse, cu dovezi, din codul în sine.
Răspunsul DORA la toate acestea este sistemul de inginerie în sine: calitatea platformei, claritatea fluxului de lucru, alinierea echipei. Exact, și totuși nu este primul pas. Nu poți repara un sistem pe care nu îl poți vedea. Fiecare dintre cele cinci domenii este ceva ce trebuie să poți observa înainte să poți pleda pentru investiții în el.
Primul pas util nu este un instrument nou sau un proces nou. Este să te cunoști pe tine însuți, sincer, și să determini care dintre aceste cinci domenii sunt puncte nevăzute în care îți lipsește dovada reală. Majoritatea liderilor pot identifica imediat (și sunt atenți la) problemele dintr-unul dintre aceste domenii. Totuși, zonele în care ai cele mai puține informații sunt cele mai susceptibile să apară și să te surprindă pe măsură ce continui să adopți AI.












