Copilot a scris codul, dar cui îi aparține? Lacuna de guvernanță pe care echipele de inginerie ar putea să o ignore

Un inginer deschide Copilot pentru a-l ajuta să scrie cod pentru site‑ul unui client. În câteva secunde, primește cod care anterior ar fi necesitat mult mai mult timp pentru a fi scris manual. Pentru mulți dezvoltatori web și companii care își optimizează site‑urile, este firește să se întrebe: este acel cod fiabil? Este sigur? Ar trebui revizuit înainte de implementare? Aceste întrebări se încadrează toate sub o singură interogare: Cine va fi tras la răspundere pentru programarea asistată de IA? Și, cel mai important, cui îi aparține câștigul de productivitate?

Dacă IA permite unei echipe de inginerie să finalizeze mai multă muncă în același interval de timp, toată lumea poate beneficia mai mult de acea valoare economică. Aceasta ar putea însemna dezvoltatorul economisind timp, angajatorul obținând mai multă valoare din orele salvate sau clientul primind ceea ce a plătit, cu ore în plus. Indiferent de modul în care beneficiile timpului economisit se manifestă, ceea ce rămâne în prim‑plan este modul în care munca este guvernată și prețuită.

IA și programarea devin inevitabile

Instrumentele de programare cu IA câștigă rapid tracţiune și pătrund în dezvoltarea mainstream. Conform 2025 Stack Overflow Developer Survey, 84% dintre respondenţi utilizau sau planificau să utilizeze instrumente IA în procesul lor de dezvoltare.

Deși implementarea IA în fluxurile de lucru ale dezvoltatorilor web devine tot mai comună, există încă rețineri privind fiabilitatea acesteia. Același sondaj a constatat că 46% nu aveau încredere deplină în acuratețea rezultatelor generate de IA, iar aproximativ 66% au menționat soluțiile IA „aproape corecte, dar nu complet” ca sursă de frustrare.

Dezbaterea privind programarea cu IA care prinde contur este mai mult despre fiabilitatea ei decât despre dacă acel cod creează mai multă valoare și cine este responsabil să se asigure că se întâmplă acest lucru.

IA rupe relația dintre ore și rezultat

Compensația pentru dezvoltarea software-ului a fost întotdeauna bazată pe presupunerea că rezultatul ingineriei era strâns legat de efortul ingineresc. Cu toate acestea, IA generativă complică acum această ecuație.

Un experiment controlat care a implicat 95 de dezvoltatori a constatat că participanții cu acces la GitHub Copilot au finalizat o sarcină specifică de server HTTP JavaScript cu 55,8% mai repede decât cei fără acces.

Acest lucru evidențiază că IA poate accelera dezvoltarea, posibil fără a sacrifica calitatea. Dar aceste cifre sunt relevante doar pentru că experimentul a urmat o sarcină de programare foarte specifică. Deși sarcina a fost finalizată mai repede, nu înseamnă că Copilot face o întreagă organizație de inginerie cu 55,8% mai productivă.

Un alt studiu de cercetare exemplifică această idee. Un trial care a implicat 96 de ingineri software cu normă întreagă de la Google a constatat că dezvoltatorii care foloseau IA au finalizat o sarcină de nivel enterprise în aproximativ 96 de minute, comparativ cu 114 de minute pentru cei fără IA. Estimarea ajustată a cercetătorilor a sugerat o reducere de aproximativ 21% a timpului de finalizare. Totuși, studiul nu a investigat calitatea codului generat de IA și nu a abordat întrebări de echitate legate de dependența de tehnologie.

Există, de asemenea, dovezi că IA încetinește timpul de programare. Un studiu randomizat realizat de METR a implicat 16 dezvoltatori experimentați în open‑source care au lucrat la 246 de probleme reale în depozite pe care le cunoșteau bine. Folosind instrumente disponibile la începutul lui 2025, inclusiv Claude Sonnet 3.5 și 3.7, precum și Cursor Pro, aceștia au durat aproximativ cu 19% mai mult pentru a‑și finaliza sarcinile, chiar dacă mulți presupuneau că aceste instrumente vor economisi timp.

Împreună, aceste studii contrazic așteptările că IA permite dezvoltatorilor să lucreze mai repede. În schimb, timpul și valoarea dezvoltatorului devin mai puțin predictibile pentru firmele care oferă servicii web și pentru clienții care le primesc.

Problema de prețuri despre care nimeni nu vorbește

Modelul Timp & Material (T&M) este un model comun în dezvoltarea web pentru achiziționarea de software, deoarece răspunde unei probleme recurente din industrie: un proiect în evoluție.

Prin acest model, în loc să se ceară definirea fiecărei funcționalităţi sau sarcini înainte de începerea dezvoltării, clienții pot plăti pentru timpul de inginerie pe măsură ce proiectul avansează și se modifică.

Totuși, IA creează obstacole în acest model dovedit. Având compensarea legată direct de orele de inginerie, un timp de dezvoltare mai eficient poate duce la un număr mai mic de ore facturabile pentru clienți. Dacă IA susține aceleași rezultate în mai puțin timp, tehnologia poate crea valoare pentru clienți, dar reducerea orelor facturabile înseamnă venituri mai mici pentru furnizori.

Soluția nu constă în încurajarea dezvoltatorilor să lucreze mai încet. Modelul T&M se confruntă acum cu o problemă structurală legată de modul în care sunt concepute prețurile și stimulentele. Utilizarea tarifelor pe oră pentru a determina valoarea poate fi limitativă. Un cumpărător poate cunoaște exact costul fiecărei ore de inginerie, dar să rămână incert privind investiția totală necesară pentru a obține rezultatul dorit.

Pe măsură ce IA modifică productivitatea ingineriei, întrebarea poate trece de la:

“Cât costă o oră de dezvoltator?” → “Ce se întâmplă cu valoarea când sunt necesare mai puține ore de dezvoltator?”

Descoperirile METR complică această întrebare. Dacă dezvoltatorii cred că pot economisi timp când, în realitate, durează mai mult, nici adoptarea IA, nici productivitatea percepută nu sunt suficiente pentru a demonstra valoarea financiară. De aceea, organizațiile au nevoie de guvernanță care să poată măsura ce s‑a întâmplat cu adevărat.

Lacuna de guvernanță are patru proprietari

Discutarea guvernanței în jurul dezvoltării asistate de IA trebuie să depășească politicile care reglementează ce instrumente pot folosi dezvoltatorii.

Există cel puțin patru tipuri de proprietate pe care organizațiile de inginerie ar trebui să le definească.

1. Cine deține codul?

IA poate genera o implementare, dar nu poate deveni o scuză pentru dezvoltare fără responsabilitate. Totuși, cineva trebuie să fie responsabil pentru revizuirea, testarea și aprobarea codului până când ajunge în producție.

2. Cine deține riscul?

Un cod mai rapid este valoros doar dacă nu provoacă probleme în alte părţi. Un studiu empiric al codului generat de IA a identificat vulnerabilităţi de securitate în 29,5% din fragmentele Python examinate și în 24,2% din fragmentele JavaScript. Cercetarea a identificat, de asemenea, slăbiciuni în 43 de categorii ale Common Weakness Enumeration.

Totuși, studiul a constatat că introducerea avertismentelor de analiză statică în Copilot Chat ar putea rezolva până la 55,5% dintre problemele de securitate identificate. Cercetarea arată cum IA poate crea și rezolva probleme de codare, dar organizațiile au nevoie de procese pentru a determina cum să valideze rezultatele sale.

NIST’s SP 800-218A reflectă acest principiu prin extinderea Secure Software Development Framework cu cele mai bune practici care abordează IA generativă și modelele de bază cu utilizare duală.

3. Cine deține câștigul de productivitate?

Acordurile comerciale de la început sunt esențiale pentru a determina cine ar trebui să primească câștigurile de eficiență. IA poate ajuta clienții să cheltuiască mai puțin, poate permite echipelor să livreze mai mult software sau poate să nu ofere niciun beneficiu financiar la finalul proiectului. 

Ceea ce rămâne constant este necesitatea unor procese transparente și a livrării unui lucru de calitate, convenit.

4. Cine deține prioritizarea?

IA poate face generarea de funcționalităţi mai ieftină și mai rapidă, dar nu poate decide dacă acele funcționalităţi sunt necesare.

De fapt, creșterea capacității de dezvoltare poate face prioritizarea și mai importantă. Când echipele pot construi și experimenta mai repede, tot trebuie să se stabilească care rezultate justifică bugetul disponibil și care idei ar trebui abandonate.

Guvernanța IA devine o problemă financiară

Aceste întrebări fac ca guvernanța IA să devină tot mai relevantă. Imaginați-vă doi parteneri de dezvoltare care percep tarife orare similare.

Unul a integrat IA într-un proces de inginerie solid și obține rezultatul necesar considerabil mai repede, în timp ce celălalt durează mai mult. Compararea doar a tarifelor lor orare nu îi spune cumpărătorului prea multe despre procesele pe care le vor desfășura.

Cumpărătorii vor trebui să evalueze:

• Investiția totală așteptată
• Responsabilitatea pentru depășiri
• Controalele de calitate ale muncii generate de IA
• Cum sunt împărțite câștigurile de eficiență

Modelul T&M poate rămâne util pentru ambele părţi dacă acceptă în mod conștient incertitudinea în servicii. Aranjamentele cu preț fix pot funcționa, de asemenea, când cerințele și livrabilele sunt stabile.

Dar IA face, de asemenea, ca structurile alternative să merite examinare. O abordare este stabilirea unei limite financiare maxime, menținând în același timp flexibilitatea domeniului de aplicare. Astfel, funcționalităţile pot fi prioritizate în funcție de valoarea de afacere în cadrul acelui model.

Dacă ingineria devine mai eficientă, câștigurile pot fi traduse în capacităţi suplimentare ale produsului, în loc de timp facturabil suplimentar. Stimulentele comerciale ar trebui să încurajeze același rezultat ca și stimulentele de inginerie, creând software mai util cât mai eficient posibil.

Aceeași discuție despre IA

Liderii din inginerie trebuie să înțeleagă cum influențează stimulentele comerciale livrarea. Echipele financiare și de achiziții au nevoie de vizibilitate suficientă asupra ingineriei asistate de IA pentru a evalua dacă eficiența revendicată oferă o valoare măsurabilă.

Aceasta înseamnă că o guvernanță IA matură nu se poate opri la listele de modele aprobate, controalele de securitate, politicile de date sau cerințele de revizuire a codului. Trebuie să abordeze responsabilitatea, riscul financiar, prioritizarea și deținerea câștigurilor de productivitate.

Însă există o a doua întrebare privind deținerea care ar putea avea un impact mult mai mare asupra bugetelor tehnologice: Cine deține valoarea creată sau pierdută când IA modifică rapiditatea cu care este construit software‑ul?

Organizațiile care stabilesc dacă ingineria mai rapidă produce cu adevărat produse mai bune, controlează investițiile și obțin rezultate de afaceri măsurabile vor fi cele capabile să rămână în fața concurenței.

Dacă echipa dvs. de dezvoltare ar adopta IA mâine, modelul dvs. actual de guvernanță și comercial ar reuși chiar să vă spună dacă livrarea a devenit mai valoroasă?