De la autor la manager: cum se schimbă munca dezvoltatorului cu agenți

Agenții au redus mult costul scrierii codului. Nu au redus însă efortul de a înțelege ce anume trebuie construit și de a verifica rezultatul. De aceea, partea cea mai interesantă a lucrului cu agenți se petrece înainte și după scrierea codului: cine stabilește sarcina, cine decide dacă rezultatul e bun și cum alegeți câtă muncă să-i încredințați agentului.

Mai jos vedem cum descriu cercetările și rapoartele din ultimii doi ani patru moduri de a lucra cu un agent, cum îl alegeți pe cel potrivit sarcinii și ceea ce se numește "intenție și standard de calitate". În a doua parte discutăm de ce rolul dezvoltatorului devine mai amplu decât scrierea codului. Datele sunt valabile pentru septembrie 2026. Cifrele apar în blocuri separate, cu link către sursă. Când redau poziția autorilor, îi numesc, iar concluziile mele le marchez ca atare.

Patru moduri de a lucra cu un agent

Cea mai clară schemă a fost propusă de Jared Spataro de la Microsoft în mai 2026. El descrie patru moduri în care omul și AI-ul își împart munca. Schema e ușor de înțeles, iar dezvoltatorii își vor recunoaște propriul parcurs cu aceste instrumente.

Cu cât urcați mai sus, cu atât scrieți mai puțin de mână și cu atât mai mult decideți dinainte și verificați după. Autorul păstrează în minte standardul de calitate în timp ce scrie. Directorul nu mai vede cum a fost produs codul, așa că tot ce contează pentru el trebuie spus înainte de începerea lucrului și verificat după. Aici doar numim orchestratorul: e un subiect amplu, cu instrumente proprii, la care merită să ajungeți după ce primele trei moduri funcționează bine.

Alegeți modul după sarcină, nu ca pe o scară

E ușor să citiți schema ca pe o scară: mai întâi sunteți autor, apoi ajungeți orchestrator, iar cu cât urcați mai sus, cu atât e mai bine. Spataro spune explicit contrariul. Scopul nu este să treceți fiecare sarcină la al patrulea mod, ci să-l alegeți pe cel potrivit pentru fiecare flux de lucru.

În practică, alegerea se reduce la patru întrebări:

• cât de clar este obiectivul. Dacă nici dumneavoastră nu știți încă ce rezultat urmăriți, e prea devreme să delegați întreaga sarcină;
• poate fi verificat automat rezultatul. Testele bune vă permit să-i dați agentului mai multă libertate, pentru că verificarea va depista greșeala, nu atenția dumneavoastră;
• cât costă o greșeală. O greșeală de tipar într-un tooltip se repară ușor, un calcul greșit al unei sume costă scump;
• se repetă sarcina. Pentru o sarcină unică nu merită să construiți un proces separat, dar pentru una săptămânală merită.

Iată cum se aplică în cazul unor sarcini concrete:

Mi se pare util să țineți minte aceste cifre. Faptul că majoritatea e prudentă nu înseamnă că rămâne în urmă: oamenii aleg modul în funcție de costul unei greșeli, și e o alegere bună. Dacă lucrați ca editor la o sarcină unde greșelile sunt costisitoare, nu "folosiți prea puțin" agentul.

În Claude Code, puteți configura direct această alegere. Plan mode și regulile de permisiuni funcționează ca un buton de reglaj pe care îl setați dumneavoastră. Pentru o sarcină costisitoare activați planificarea înainte de modificări și confirmarea acțiunilor riscante; pentru una de rutină îi dați agentului mai multă libertate.

Intenția și standardul de calitate

Cu cât delegați mai multă muncă, cu atât contează mai mult ce spuneți înainte de a începe. Studiul Microsoft formulează ideea astfel: cei mai eficienți utilizatori AI nu vor fi cei care fac mai mult și mai repede, ci cei care își construiesc valoarea în jurul lucrurilor pe care doar un om le poate face. Ei stabilesc o intenție clară, adică descriu rezultatul dorit și standardul de calitate, și se gândesc cum să împartă munca între oameni și AI.

În dezvoltare, această idee are de mult denumiri cunoscute. Intenția este specificația: ce trebuie făcut și de ce. Standardul de calitate înseamnă criteriile de acceptare și ceea ce în Scrum se numește Definition of Done: o listă de condiții care arată că munca este gata. De aici înainte îi vom spune simplu standardul de finalizare.

Daniel Epstein de la Microsoft, care construiește agenți folosind Agile, a formulat ideea foarte concis în primul articol din seria Agentic-Agile (19 mai 2026): "Every capability is an issue. Every issue has acceptance criteria." Fiecare capabilitate este o sarcină, iar fiecare sarcină are criterii de acceptare.

E util să scrieți sarcina în două registre deodată. Oamenilor le explicați de ce e necesară și cui îi folosește. Agentului îi spuneți ce să facă, după ce criterii să verifice și ce să nu atingă. Iată un exemplu didactic, cu aceeași solicitare înainte și după. În a doua variantă, primul paragraf e pentru oameni, iar restul pentru agent.

Înainte:

Adaugă exportul cheltuielilor în CSV, ca să funcționeze cum trebuie.

După:

De ce: contabilul transferă manual în fiecare lună cheltuielile echipei
în propriul tabel. Pierde o oră și apar erori în sume.

Sarcină: adaugă butonul "Exportă în CSV" pe pagina cheltuielilor lunare.

Este gata când:
- fișierul se deschide cu dublu clic într-un editor de foi de calcul, iar
  denumirile cu diacritice sunt afișate corect fără setarea manuală a codării;
- fiecare rând reprezintă o cheltuială, iar primul rând conține numele coloanelor;
- sumele pot fi adunate cu o formulă, fără să editați celulele.

Nu modifica: formatul de stocare a cheltuielilor și ecranul existent cu lista.
Arată-mi mai întâi planul și cum vei verifica fiecare punct.

În a doua variantă, agentul are foarte puține lucruri de ghicit. Mai important, aveți cu ce compara rezultatul: cele trei puncte se verifică manual în câteva minute. Expresia "cum trebuie" din prima variantă nu poate fi verificat. Puteți doar să-l acceptați pe încredere.

Agentul nu știe ce înseamnă "bine"

De aici încolo urmează în principal concluziile mele din date, nu datele în sine. Precizez asta de la început, ca să nu prezint o opinie drept rezultat al cercetării.

Un agent poate face foarte multe: poate citi un proiect necunoscut, găsi cauza unei erori, scrie o implementare, rula testele și explica ce a făcut. Dar nu poate decide singur ce înseamnă "să facă bine" pentru acești utilizatori și această afacere. Fără criterii, alege o variantă plauzibilă, de mijloc, și raportează cu încredere că a terminat. Codul poate fi îngrijit, dar soluția tot poate fi greșită.

"Bine" nu se găsește în cod. Depinde de cine va folosi rezultatul, ce contează pentru acea persoană și ce greșeli nu sunt acceptabile. În exemplul cu exportul, agentul ar fi putut crea un CSV corect tehnic, dar pe calculatorul contabilului s-ar fi deschis cu caractere ilizibile. Din perspectiva codului, totul e în regulă. Pentru sarcina propriu-zisă, nu.

Concluzia e simplă. Stabilirea unui criteriu și verificarea rezultatului în funcție de el sunt partea de muncă pe care nu o puteți delega. Agentul vă poate ajuta să formulați criteriile, poate pune întrebări de clarificare și poate propune verificări. Dumneavoastră decideți dacă acele criterii sunt corecte.

Înțelegeți mai întâi procesul

De unde vin criteriile? Aproape niciodată din cod. Ele vin din procesul de business: cine va deschide fișierul, ce va face apoi cu el și ce se întâmplă dacă se pierde un rând sau o sumă este rotunjită greșit.

Cerința "denumirile cu diacritice sunt afișate corect fără setări manuale" nu a apărut fiindcă așa se scrie corect un CSV. A apărut după ce cineva l-a întrebat pe contabil cum deschide fișierele și a văzut că dă dublu clic, fără să folosească asistentul de import. Un dezvoltator care cunoaște procesul scrie criteriul de la început. Cel care nu-l cunoaște află de el peste o lună, dintr-o reclamație.

Companiile observă deja schimbarea și își reorganizează rolurile.

Există și o perspectivă opusă, pe care merită s-o cunoașteți. De exemplu, compania de consultanță Converteo descrie pe blogul său rolurile de manager de produs, designer și AI product builder ca fiind complementare, nu concurente: primul răspunde la "de ce", al doilea se ocupă de utilizator, iar al treilea transformă rapid ideea într-un prototip funcțional. Converteo vinde la rândul ei servicii în acest domeniu. Eu nu aș miza pe una dintre variante. Concluzia practică e aceeași pentru dumneavoastră: un dezvoltator care înțelege procesul clientului valorează mai mult decât unul care așteaptă un ticket scris perfect.

Conversația ca instrument de lucru

Înainte, soft skills erau adesea prezentate ca un bonus plăcut pe lângă competențele tehnice. Cu agenții, lucrurile se schimbă. Criteriile de calitate sunt în mintea oamenilor, nu în repository, iar singura cale de a le afla este conversația.

Iată ce ajunge să facă parte din muncă:

• întrebați. Nu "ce să fac?", ci "ce veți face cu rezultatul?" - la această întrebare oamenii răspund mai precis;
• clarificați. Întrebați despre cazul-limită înainte să devină un bug: ce facem cu o cheltuială fără categorie?
• notați. Agentul nu poate citi o înțelegere rămasă doar în conversație, iar colegul o va uita;
• conveniți asupra limitelor. Ce intră în sarcină și ce nu, și spuneți "asta e o sarcină separată" când vi se cere "să corectați și asta, tot acum";
• explicați compromisul. "Putem face asta într-o zi fără alegerea perioadei sau în trei zile cu această opțiune" - clientul decide, dar dumneavoastră propuneți variantele.

Niciuna dintre aceste abilități nu ține de cod, dar fiecare influențează direct ce va face agentul. Cu alte cuvinte, calitatea conversațiilor cu oamenii se transformă în calitatea sarcinii formulate pentru agent.

Fiecare e puțin CEO

Dacă punem toate piesele laolaltă, imaginea e familiară. Stabilirea obiectivului, definirea criteriilor, împărțirea muncii, verificarea rezultatului și asumarea lui țin de munca unui manager. Când lucrează cu agenți, dezvoltatorul face toate acestea în fiecare zi, chiar dacă la scară mică.

Metafora CEO-ului surprinde bine un singur lucru: unde se află responsabilitatea. Un CEO poate delega aproape totul, mai puțin responsabilitatea pentru rezultat. La fel e și cu agenții. Dacă un agent creează un export care strică tabelul contabilului, nu agentul va răspunde pentru asta.

Merită să spunem și ce nu înseamnă metafora. Nu e o promovare, iar nimeni nu devine manager doar pentru că a lansat trei agenți. Mai degrabă, abilitățile de manager vor fi necesare mai devreme decât se obișnuia, încă de la primul loc de muncă. Există și un risc: dezvoltatorii și-au format mult timp competențele scriind cod cu mâna lor, iar acest parcurs se schimbă. E în continuare obligatoriu să înțelegeți codul pe care îl acceptați de la agent. Fără asta, verificarea se reduce la "pare că funcționează".

Cum să citiți aceste date

Toate cifrele de mai sus au fost publicate de companii care vând AI sau produse asociate. Asta nu le face false, dar merită să țineți cont de acest lucru. Pe scurt:

Toate procentele de aici sunt autoevaluări făcute de oameni la un moment dat. Arată ce cred și ce așteaptă oamenii, nu ce s-a întâmplat în realitate. Autorii Work Trend Index 2026 spun explicit că relațiile din analiza lor sunt asocieri statistice, nu relații de cauză și efect.

Pentru orice cifră despre AI și muncă, merită să vă puneți trei întrebări. Cine a plătit pentru cercetare? Ce anume s-a măsurat: o opinie, o așteptare sau un rezultat real? Pe cine au întrebat și cât de asemănători sunt acei oameni cu dumneavoastră? Dacă răspunsurile vi se par convingătoare, puteți folosi cifra. Dacă nu, poate fi în continuare interesantă, doar că are mai puțină greutate.

La ce folosesc toate acestea

Tot ce sună mai sus a limbaj de raport devine, în lucrul cu Claude Code, un set de obiceiuri concrete:

• planul înainte de modificare este intenția. Cereți-i agentului să arate mai întâi ce va schimba și cum, apoi comparați cu ce vă doreați;
• criteriile de acceptare din solicitare sunt standardul dumneavoastră de finalizare. Două-trei puncte verificabile în loc de "să funcționeze cum trebuie";
• modul de lucru și regulile de permisiuni înseamnă alegerea modului. Cu cât greșeala costă mai mult, cu atât agentul se oprește și întreabă mai des;
• revizuirea diff-ului și verificarea atentă înseamnă evaluarea rezultatului după criteriile dumneavoastră, nu după raportul agentului;
• un rezumat scurt: ce s-a făcut, cum s-a verificat și ce nu s-a verificat înseamnă asumarea rezultatului, pe care nu o puteți delega agentului.

Date valabile pentru septembrie 2026. Cercetările din domeniu apar des, iar cifrele se învechesc mai repede decât concluziile.