Oamenii se agață cu greu pe viață pe măsură ce IA accelerează livrarea de software

Pentru cea mai mare parte a istoriei dezvoltării de software, oamenii au fost controlul. Un dezvoltator face o modificare, o altă persoană o revizuiește, cineva o aprobă și, în cele din urmă, este implementată.

IA accelerează întregul sistem în timp ce noi încă încercăm să menținem oamenii în mijlocul său. Dezvoltatorii pot acum să creeze cod și modificări în câteva secunde. Agenții pot lucra în diferite depozite, instrumente, infrastructuri și alte sisteme cu implicare umană redusă.

Instinctul nostru este să readucem oamenii în proces. Revizuim cererea de extragere, aprobăm apelul instrumentului, verificăm modificarea și confirmăm implementarea pentru că vrem să ne asigurăm că IA nu a făcut ceva ce nu trebuia. Ne agățăm cu greu pe viață.

Acest instinct are sens. Revizuirea umană ne oferă o modalitate de a menține controlul pe măsură ce software‑ul avansează spre producție. Dar IA începe să opereze cu o viteză și un volum la care oamenii nu mai pot rămâne unitatea de scară pentru guvernanță.

IA deja se mișcă mai repede decât revizuirea umană

Primul val de IA generativă în dezvoltarea de software s‑a concentrat în principal pe ajutarea dezvoltatorilor să scrie cod mai repede. Acest lucru singur schimbă livrarea de software. Mai mult cod înseamnă mai multe modificări ale aplicațiilor, ale infrastructurii și ale bazelor de date care trec prin testare, securitate, revizuire, implementare și producție.

Problema nu este neapărat că IA creează modificări de calitate inferioară. Ea creează mai multe modificări, mai repede. Dacă controlul pentru tot acest output nou constă în altă persoană care revizuiește fiecare schimbare, în cele din urmă matematica nu mai funcționează.

Deja observăm semne ale acestui fenomen. Anthropic a raportat recent că utilizatorii Claude Code aprobă aproximativ 93 % din solicitările de permisiune. Compania a constatat că solicitările repetate pot genera oboseală de aprobare, oamenii acordând tot mai puțină atenție pe măsură ce numărul aprobărilor crește. Anthropic folosește acum un clasificator automat pentru a evalua acțiunile și a opri pe cele potențial periculoase, în loc să ceară unei persoane să aprobe totul.

Gândește‑te la ce spune asta despre supravegherea umană. Dacă cineva aprobă 93 % din timp, adăugarea unei alte aprobări nu îți oferă neapărat mai mult control. La un moment dat, omul devine un alt pas în fluxul de lucru.

Putem folosi IA pentru a crea mai mult software. Nu putem răspunde prin a crea o operațiune de revizuire umană la fel de mare în spatele ei.

IA trece de la crearea de cod la acțiune

Asistenții de codare au oferit IA un rol în dezvoltare. Agenții oferă IA capacitatea de a participa în mult mai multe etape ale ciclului de viață al dezvoltării software (SDLC). Un agent poate primi un scop, decide cum să îl îndeplinească, folosească instrumente, observe rezultatele și ajusteze ce face în continuare.

În ingineria software, acest lucru poate însemna modificarea fișierelor, rularea comenzilor, interacțiunea cu depozitele, apelarea API‑urilor, testarea codului sau lucrul cu infrastructura. Oamenii devin, de asemenea, tot mai confortabili să lase agenții să lucreze pe cont propriu. Anthropic a constatat că utilizatorii experimentați ai Claude Code au folosit aprobarea automată completă în peste 40% din sesiuni, aproximativ de două ori mai mult decât utilizatorii noi.

Acest lucru nu înseamnă că agenții autonomi rulează medii de producție pretutindeni în prezent. Nu o fac. Dar dezvoltarea de software ne oferă o privire timpurie asupra direcției în care se îndreaptă lucrurile.

Astăzi, IA creează mai multe modificări, iar revizuirea umană începe să se tensioneze. În continuare, IA va participa în mai multe etape ale SDLC‑ului. În cele din urmă, agenții vor crea, valida, implementa, observa și remedia modificări cu multă mai puțină implicare umană.

La fiecare pas, eliminăm un alt loc în care o persoană obișnuia să ofere control. Întrebarea se mută de la dacă IA poate face munca la ce ar trebui să i se permită să facă pe cont propriu.

Permisiunea nu este autoritate

Agenții au nevoie de acces pentru a efectua lucrări utile. Un agent care ajută la implementarea software‑ului poate avea nevoie de acces la un depozit, la un sistem CI/CD, la un mediu cloud sau la o bază de date. Dacă îi retragi acel acces, îi iei și o mare parte din ceea ce îl face util.

Dar accesul și autoritatea nu sunt același lucru. A oferi unui agent permisiunea de a accesa un sistem nu înseamnă că ar trebui să aibă autoritatea de a efectua fiecare acțiune disponibilă în acel sistem.

Controlul tradițional al accesului ne poate spune dacă un agent are permisiunea de a ajunge la ceva. Avem, de asemenea, nevoie de o modalitate de a determina dacă acțiunea specifică pe care vrea să o întreprindă ar trebui să aibă loc. Acest aspect devine mai important când sistemul care ia decizia poate interpreta o sarcină diferit de persoana care a atribuit-o, întâlnește un obstacol și alege o altă cale sau folosește un instrument legitim într-un mod neanticipat.

OWASP descrie o variantă a acestei probleme ca Excesul de agenție. Ea indică funcționalitatea, permisiunile și autonomia excesive ca fiind cauze ale acțiunilor dăunătoare și recomandă aprobarea independentă pentru acțiuni cu impact ridicat.

NVIDIA abordează aceeași problemă la nivel de arhitectură. Platforma sa Open Agent Safety Platform plasează aplicarea politicilor în afara agentului și transmite un punct simplu: nu se poate aștepta ca un agent să guverneze complet propriul comportament.

Acest lucru ar trebui să modeleze modul în care construim SDLC-ul AI. Un agent poate avea nevoie de permisiune pentru a accesa o bază de date, un mediu de infrastructură sau un sistem de implementare. Asta nu înseamnă că agentul ar trebui să decidă de unul singur că fiecare modificare pe care dorește să o facă este sigură.

AI ia decizii bazate pe probabilități. Nu ar trebui să permitem ca fiecare dintre acele decizii să devină automat o acțiune împotriva unui sistem critic.

Omul în buclă nu poate fi răspunsul complet

Răspunsul evident este să menținem o persoană în fața acțiunilor AI cu consecințe. Pentru anumite decizii, asta este exact ce ar trebui să facem. Greșeala este să transformăm „omul în buclă” în soluția pentru fiecare decizie.

Dacă fiecare acțiune pe care o efectuează un agent necesită ca cineva să o revizuiască și să apese „aprobare”, am recreat blocajul pe care AI trebuia să îl elimine. Mai rău, un număr suficient de aprobări poate transforma supravegherea într-un obicei. O persoană care apasă „aprobare” toată ziua nu exercită neapărat judecata.

Trebuie să fim mai deliberativi în privința locului în care au loc deciziile. AI poate lua decizii în cadrul sarcinii pe care i-am atribuit-o. Politica poate gestiona deciziile în care regulile sunt deja cunoscute. Oamenii pot gestiona excepțiile și deciziile care într-adevăr necesită judecată.

O modificare cu risc scăzut care respectă politica stabilită nu ar trebui să necesite ca cineva să o supravegheze. O modificare care încalcă politica ar trebui să se oprească automat. O excepție cu consecințe semnificative pentru afacere, securitate sau operațiuni poate necesita intervenția unei persoane.

Acesta este un model foarte diferit de simpla introducere a unui om în fiecare buclă. Scopul nu este să eliminăm oamenii. Este să încetăm să facem atenția umană elementul de care depinde fiecare acțiune și să facem calea guvernată cea mai ușoară cale.

Plasați controlul acolo unde are loc acțiunea

Întreprinderile nu vor standardiza pe un singur model AI sau un singur agent. Dezvoltatorii vor folosi diferiți copilot. Echipele vor experimenta cu modele diferite. AI va apărea în instrumentele de dezvoltare, produsele de securitate, platformele de date și aplicațiile interne.

Încercarea de a construi un proces de guvernanță diferit în jurul fiecărui instrument AI nu va scala. Controlul trebuie să fie plasat mai aproape de acțiunea pe care AI dorește să o efectueze.

Dacă o modificare generată de AI intră într-un pipeline de implementare, ar trebui să se supună aceleiași politici ca o modificare generată de om. Dacă un agent dorește să modifice infrastructura, datele sau o bază de date de producție, controalele din jurul acelui sistem nu ar trebui să dispară din cauza schimbării actorului.

Sursa modificării nu determină riscul. Modificarea însăși o face. Un dezvoltator, asistent de codare, proces automatizat sau agent autonom poate urma o cale diferită spre aceeași acțiune, dar acea acțiune poate totuși să fie supusă aceleiași politici înainte să devină consecventă.

Acest lucru permite, de asemenea, tehnologiei să se schimbe fără a forța companiile să reconstruiască guvernanța de fiecare dată. Modelele se vor schimba. Agenții vor deveni mai capabili. Controalele din jurul sistemelor critice pot rămâne consistente.

NIST adoptă o abordare similară bazată pe risc în cadrul AI Risk Management Framework, care tratează guvernanța ca pe ceva ce trebuie să funcționeze pe tot parcursul ciclului de viață AI, mai degrabă decât ca o aprobare unică la final. Pentru livrarea de software, asta înseamnă să introducem controale în calea pe care AI o parcurge deja, în loc să adăugăm un alt proces manual.

Când omul pleacă, dovezile nu pot pleca cu el

Există o altă problemă ascunsă în modelul de revizuire umană. Când elimini persoana din proces, nu pierzi doar revizuirea. Poți, de asemenea, să pierzi persoana care a ajutat la dovedirea că revizuirea a avut loc.

Acest lucru devine o problemă serioasă pentru companiile cu cerințe de securitate, conformitate și audit. Ele trebuie în continuare să știe ce s-a modificat, cine sau ce a inițiat modificarea, ce politică a fost aplicată, dacă a trecut, cine a aprobat o excepție, unde a fost executată modificarea și ce s-a întâmplat ulterior.

Nu poți automatiza modificarea și să lași dovezile manuale. Într-un proces condus de oameni, echipele pot reconstrui dovezile ulterior din tichete, aprobări, jurnale de pipeline, capturi de ecran și conversații. Această abordare devine mai dificilă pe măsură ce volumul de modificări crește și devine nerealistă când mașinile creează și execută modificări în mod continuu.

Dovezile trebuie să devină parte a procesului de livrare. Deciziile de politică, aprobările, excepțiile, implementările și rezultatele ar trebui să genereze înregistrări pe măsură ce munca are loc. Dovezile de audit devin un subprodus al livrării de software, în loc să fie ceva ce echipele adună ulterior.

Acest lucru lasă două sarcini diferite pentru guvernanță într-un SDLC condus de AI. Înainte de o acțiune, se determină dacă ar trebui să aibă loc. După acțiune, se dovedește ce s-a întâmplat.

Oamenii nu dispar. Rolul nostru se schimbă.

Există un instinct firește de a măsura controlul în funcție de câte ori intervine o persoană. Mai multe revizuiri par mai sigure. Mai multe aprobări par mai sigure. Menținerea unui om în fiecare buclă pare mai sigură.

AI va testa această presupunere. Dacă AI continuă să crească cantitatea de software pe care o putem crea, oamenii nu vor putea revizui fiecare modificare, aproba fiecare acțiune, monitoriza fiecare implementare și reconstrui fiecare decizie ulterior. Încercarea de a face asta va încetini AI sau va transforma supravegherea umană într-un timbru de cauciuc.

Ciclul de viață al dezvoltării software cu AI (AI SDLC) are nevoie de o diviziune a muncii diferită. AI poate gestiona o parte mai mare a sarcinilor, în timp ce politica guvernează deciziile repetitive, iar oamenii intervin când ceva necesită cu adevărat un judecat. Dovezile ar trebui generate automat pe parcurs.

Vom oferi AI mai mult acces deoarece așa devine util. Vom oferi agenților mai multă autonomie deoarece așa obținem mai multă valoare de la ei. Provocarea este să ne asigurăm că accesul și autonomia sporită nu devin în tăcere autoritate nelimitată.

Oamenii nu trebuie să se agațe mai strâns. Scopul nu este mai puțin control. Este un model de control care nu depinde de faptul că noi reținem fiecare decizie în mod direct. Trebuie să construim controalele care ne permit să ne relaxăm strânsoarea fără a pierde controlul.