Agentic Development: ce este de fapt, ce nu este și ce schimbă

„Agentic development” e la modă, și ca orice termen la modă, e întins să acopere totul, de la completarea cu Tab până la fantezii despre concedierea echipei de inginerie. Noi am petrecut ultimele luni livrând software real în felul acesta — nftably, un UI pentru firewall, a fost construit aproape în întregime de agenți de AI coding sub coordonare umană — așa că aceasta este încercarea noastră de a da o definiție de lucru, din practică, nu dintr-un keynote.

Scara: autocomplete, chat, agenți

Ajută să vezi agentic development ca a treia treaptă a unei scări, pentru că fiecare treaptă schimbă ce face omul, nu doar cât de repede merge tastatul.

Autocomplete — Copilot în forma lui inițială. Modelul prezice următoarele câteva linii în timp ce tastezi. Tu ești în continuare cel care scrie programul; modelul e o tastatură foarte bună. Unitatea de lucru este linia.

Programare asistată de chat — descrii o problemă, modelul propune cod, tu îl lipești și îl adaptezi. Util, dar modelul e orb: nu-ți poate vedea repo-ul, nu-ți poate rula testele și nu poate afla dacă sugestia lui măcar compilează. Tu ești mâinile modelului și singura lui buclă de feedback.

Agentic development — modelul primește unelte: poate citi și edita fișiere, rula comenzi în shell, executa suita de teste și inspecta rezultatele. Dat fiind un obiectiv, lucrează într-o buclă — planifică, acționează, verifică, ajustează — până când testele trec sau se blochează. Claude Code, modul agent din GitHub Copilot, agentul din Cursor și agenții de tip Codex funcționează toți așa; diferențele dintre ei contează mai puțin decât ce au în comun, adică bucla.

Bucla aceasta e tot rostul. Un agent care îți rulează testele își prinde singur codul stricat înainte să-l vezi tu. Feedback-ul care înainte trecea prin ochii și degetele tale trece acum prin toolchain, iar omul urcă un nivel.

Ce se schimbă concret

Unitatea de lucru devine diff-ul revizuit, nu linia tastată. În workflow-ul nostru, nu mai „scriem cod” în sensul vechi. Scriem specificații — un design doc, descrierea unui milestone, un bug report cu reproducere — și revizuim diff-uri. Întrebarea interesantă nu mai este „cât de repede putem tasta asta”, ci „cât de precis putem spune ce vrem și cât de sigur putem stabili dacă am obținut-o”.

Specificația devine un artefact de primă clasă. Fiecare proiect al nostru începe cu un PLAN.md scris de un om: arhitectura, modelul de date, milestone-urile, non-obiectivele explicite. Un design doc bine scris se dovedește a fi un prompt mult mai bun decât orice conversație. Am scris despre mecanica acestui lucru în workflow-ul nostru de dezvoltare cu AI.

Verificarea devine gâtul de sticlă — și avantajul competitiv. Când generarea de cod devine ieftină, tot ce validează codul devine resursa rară: teste, CI, lintere, atenția la review. O bază de cod cu o suită de teste solidă și un CI strict poate absorbi în siguranță cod scris de agenți, pentru că bucla are în ce să se sprijine. O bază de cod fără niciuna dintre ele nu-i dă agentului nimic față de care să verifice, iar el va produce cu drag greșeli plauzibile la scară. Dacă vrei o predicție într-o singură propoziție: echipele cu infrastructură bună de verificare vor obține randamente compuse de la agenți; echipele fără ea vor acumula datorie compusă.

Ce nu este

Nu este inginerie software autonomă. Nimeni dintre cei pe care îi cunoaștem nu livrează output-ul unui agent necitit, și nici noi nu o facem. Pe proiectele noastre, agenții au făcut cea mai mare parte din tastat; modelul de obiecte, semantica de siguranță și fiecare decizie de merge au rămas umane. Agentul este un inginer de nivel mediu neobosit, rapid și ocazional prea încrezător. Nu este o organizație de inginerie.

Nu înlocuiește judecata de design. Un agent va implementa designul pe care i-l dai, inclusiv părțile proaste, cu mare entuziasm. Decizia că un UI pentru firewall trebuie să aplice schimbările atomic, cu auto-revert — ca o regulă greșită să nu te poată încuia afară — este o judecată de design. Niciun agent n-a propus asta; a propus-o un om care a rămas încuiat afară dintr-o mașină remote. Agentul a implementat-o apoi bine.

Nu este magie pe o bază de cod netestată. Îndreaptă un agent către un sistem legacy mare, fără teste și cu convenții ambigue, și vei genera în principal regresii încrezătoare. Bucla agentului are nevoie de un semnal „a mers?”. Fără semnal, fără buclă — doar generare.

Unde strălucește, unde eșuează

Din experiența noastră — trei unelte livrate, documentate într-un studiu de caz — tiparul este consecvent.

Strălucește când:

• Problema este bine specificată și criteriile de acceptare sunt verificabile (straturi CRUD, handlere de API, renderere, migrări, schelet de teste, packaging)
• Stack-ul este convențional — Go, TypeScript, SQL, unități systemd — acolo unde distribuția de antrenare a modelului este densă
• Baza de cod are teste și CI pe care agentul trebuie să le țină verzi
• Munca este voluminoasă, dar nu profundă: cincizeci de endpoint-uri asemănătoare, nu un singur algoritm subtil

Eșuează când:

• Cerințele sunt ambigue — agentul rezolvă ambiguitatea alegând ceva, în tăcere
• Problema este cu adevărat nouă și nu există nimic comparabil în datele de antrenare
• Corectitudinea este critică pentru siguranță și subtilă: concurență, criptografie, rotunjiri financiare, orice unde plauzibil-dar-greșit este modul de eșec dominant (am scris un ghid practic pentru review-ul codului generat de AI exact pentru asta)
• Semnalul de verificare lipsește sau este lent

Rezumatul onest

Agentic development este real și a schimbat felul în care construim software: ultimele noastre trei unelte au fost în mare parte tastate de agenți și în întregime proiectate și revizuite de oameni. Este însă și mai îngust decât sugerează hype-ul. Tehnologia mută omul de la tastat la specificat și verificat — ceea ce înseamnă că oamenii buni la specificat și verificat devin mai valoroși, nu mai puțin.

Concluzii

1. Agentic = unelte + buclă — un agent editează fișiere, rulează comenzi și verifică rezultatele față de un obiectiv; bucla aceasta e ceea ce îl separă de autocomplete și chat
2. Rolul tău se mută spre specificații și review — diff-ul revizuit este noua unitate de lucru
3. Verificarea este avantajul competitiv — testele, CI-ul și disciplina de review decid dacă agenții compun valoare sau datorie
4. Judecata de design rămâne umană — agenții implementează decizii; nu iau decizii bune
5. Potrivește unealta cu terenul — mai întâi munca convențională, bine testată, bine specificată; la urmă munca nouă și critică pentru siguranță

Dacă vrei ajutor să aduci agentic development în echipa ta — cu balustradele care îl fac sigur — vorbește cu noi.