De ce codul scris de inteligența artificială frustră echipelor — și ce puteți face în acest sens

Cu majoritatea tehnologiilor, cu cât le folosiți mai mult, cu atât mai calm și mai sigur le folosiți. Cu instrumentele de inteligență artificială, s-a dovedit a fi invers: în sondajul anual al Stack Overflow, realizat pe un eșantion de peste 49.000 de dezvoltatori, s-a înregistrat o creștere a utilizării la 84%, în timp ce încrederea în acuratețea acestor instrumente a scăzut de la 40% la 29% în decurs de un an.

Acest efect este familiar pentru mine. Prima noastră experiență cu instrumentele de inteligență artificială în dezvoltare a avut puțin în comun cu efectul “wow” al unei lucrări mai rapide și mai puțin obositoare, despre care presa tehnologică scria în mod constant. Dezvoltatorii noștri au fost dezamăgiți: inteligența artificială a produs un cod mediocru, care a necesitat mult timp pentru revizuire și, în final, a trebuit să fie rescris. Echipa se aștepta ca inteligența artificială să economisească timp și, în schimb, a primit o muncă suplimentară. Așadar, nu mult timp după primele încercări de a integra instrumentele de inteligență artificială în fluxul de lucru zilnic, echipa a revenit la modul de lucru obișnuit.

Astăzi, aceleași instrumente accelerează atât scrierea codului, cât și revizuirea lui pentru dezvoltatorii noștri — nu pentru că am găsit un model mai bun, ci pentru că am schimbat modul în care lucrăm cu el. Iată ce ne-a ajutat să ajungem aici.

De ce codul scris de inteligența artificială frustră dezvoltatorii

Inteligența artificială se bazează pe o masă enormă de cod public de pe internet, și acest cod este rareori exemplar: calitatea lui este medie, și modelul reproduce această medie.

“Mediocrul” nu este limita a ceea ce este posibil — este pur și simplu ceea ce modelul produce până când îl cunoaște pe proiectul dumneavoastră: convențiile lui, structura codului, deciziile arhitecturale. Într-un sondaj realizat pe un eșantion de peste 600 de dezvoltatori, Qodo a constatat că, printre cei nemulțumiți de calitatea codului inteligenței artificiale, 44% o atribuie exact lipsei de context. Acesta este motivul pentru care outputul rămâne la un nivel mediocru.

Vestea bună este că contextul pe care îl primește inteligența artificială este singura variabilă pe care o controlează echipa în întregime. Cât de bine instrumentul înțelege proiectul depinde nu de model, ci de ceea ce îi oferiți.

Al doilea motiv este de natură psihologică — însăși natura muncii se schimbă. Când inteligența artificială scrie majoritatea codului, actul principal al dezvoltatorului nu mai este scrierea, ci verificarea ceea ce a fost generat: citirea soluției cuiva, cântărirea alternativelor, decizia asupra a ceea ce este gata de a fi lansat. Acesta este un skill diferit de scrierea codului în sine, și pentru oricine iubea partea de scriere, nu vine ușor.

În raportul Octoverse 2025, GitHub descrie exact această schimbare: dezvoltatorii care au mers cel mai departe cu inteligența artificială nu se mai numesc “autori de cod” și devin ceva mai apropiat de “regizori creativi”, unde abilitatea cheie este de a conduce și de a verifica. Dar drumul către acest rol trece prin greșeli și frustrare, până când o persoană vede beneficiile în munca sa.

Ce transformă inteligența artificială dintr-o sursă de frustrare într-un instrument de lucru

Când echipa noastră a început să utilizeze inteligența artificială, unii dezvoltatori au lucrat cu Claude Code, alții au încercat OpenAI Codex, GitHub Copilot sau Gemini CLI, și fiecare instrument a oferit un rezultat diferit. Așadar, când am decis să aducem ordine în modul în care echipa noastră lucra cu inteligența artificială, primul lucru pe care l-am făcut a fost să ne stabilim pe un singur instrument.

Acesta nu este doar modul nostru de lucru. Luați povestea echipei de la Linear: până la începutul anului 2026, au funcționat pe principiul “lasă pe fiecare să lucreze cum îi place”, și în ianuarie, conducerea a abandonat această abordare și a mutat toată lumea la o singură modalitate de lucru — reducând alegerea la două instrumente de inteligență artificială și cerând dezvoltatorilor să scrie cod doar cu acestea, și nu de mână. Conform companiei, productivitatea medie a crescut în luna următoare cu 30% în ceea ce privește PR-urile fuzionate și cu 33% în ceea ce privește sarcinile închise pe inginer.

Acest lucru spus, un instrument partajat singur nu îmbunătățește codul — trebuie configurat: stabilirea unor reguli, așa cum ar fi un fișier rules.md, care să specifice cum să scrieți cod — care abordări să urmați, ce să evitați. Apoi, vin abilitățile personalizate pentru sarcinile tipice proiectului dumneavoastră, astfel încât să nu explicați același lucru de mai multe ori. Și, în final, merită să îndreptați agentul către baza de cod existentă: el analizează modul în care este scris proiectul și produce cod nou în același stil, și nu într-unul generic. Cu cât instrumentul primește mai mult context, cu atât mai puțin veți avea nevoie să rescrieți de mână ulterior.

Dar partea cea mai grea nu este de natură tehnică. Trecerea de la autor de cod la evaluator nu se întâmplă de la sine — această tranziție are nevoie de ajutor. Calea cea mai directă este pregătirea și certificarea. În cazul nostru, de exemplu, zece dezvoltatori urmează un program de parteneriat cu furnizorul instrumentului, în timp ce alături de ei lucrează o persoană responsabilă cu adoptarea, care explică de ce instrumentul a produs un anumit rezultat și cum să îl remediați.

Odată ce echipa lucrează într-un mod coordonat, rămâne o singură blocaj — revizuirea — și merită să o întăriți cu inteligență artificială. Agentul trece prin fiecare solicitare de extragere și preia aspectele evidente: greșeli de rutină, stil, repetiții, lacune de securitate. Revizorul uman nu mai examinează totul în mod indiscriminat, ci doar arhitectura și deciziile critice. Efectul este vizibil chiar și în cadrul companiilor care construiesc aceste instrumente: la Anthropic, după introducerea unui astfel de agent, ponderea solicitărilor de extragere care primesc o revizuire substanțială a crescut de la 16% la 54%, și inginerii nu au fost de acord cu mai puțin de 1% din comentariile sale.

Pentru noi, acest lucru a scurtat un ciclu de revizuire care se întindea pe două sau trei zile, și a ridicat rutina de pe inginerii noștri seniori, lăsându-le doar punctele cu adevărat grele. Odată ce instrumentul a început să producă rezultate care nu necesitau rescriere, încrederea în el a apărut și ea.

Unde încrederea în instrumentele de inteligență artificială se dovedește a fi avantajoasă

Mai întâi și mai presus de toate — în scrierea codului: atunci când instrumentul cunoaște proiectul și agentul gestionează prima revizuire, echipa scrie mai mult și mai bine, în același timp. În cazul nostru, instrumentele de inteligență artificială au accelerat munca cu aproximativ 30-40%.

Dincolo de aceasta, inteligența artificială a făcut ca integrarea noilor angajați să fie mai ușoară. Când o persoană nouă se alătură unui proiect, de obicei, cineva experimentat trebuie să răspundă la zeci de întrebări despre modul în care este structurat codul proiectului. Acum, agentul preia acest rol: dacă proiectul este bine documentat, noul venit direcționează până la 95% din aceste întrebări către el, și nu către colegi.

Este o poveste similară și cu documentația: o schiță arhitecturală brută care odinioară consuma ore întregi este acum, în mare parte, scrisă de agentul însuși — aproximativ 80% din schiță, dacă îi oferiți suficient context. Ce rămâne omului este ceea ce nu se află în depozit — deciziile, compromisurile, expertiza.

La fel de important este să fiți onești cu privire la limitele a ceea ce poate face inteligența artificială, deoarece sunt așteptările inflamate care generează dezamăgirea din primul rând. Inteligența artificială nu preia conformitatea — un om semnează pentru date medicale sau financiare, și compania, și nu modelul, poartă răspunderea pentru o scurgere de informații. Nu accelerează integrările cu partenerii, unde zeci de ore se duc în apeluri și coordonare.

Inteligența artificială “out-of-the-box” este, într-adevăr, iritantă — dar doar atunci când este utilizată ca o soluție finită. Toată diferența dintre frustrare și beneficiu constă în ceea ce construiți în jurul ei: un standard partajat, contextul proiectului dumneavoastră și noul rol al dezvoltatorului.