În majoritatea echipelor care adoptă programarea agentivă, blocajul se mută de la generare la revizuire, iar fără optimizarea acestui ciclu, câștigul net de viteză este aproape zero.
În mediile CI de mari dimensiuni — cu milioane de teste nocturne și sute de ingineri — sarcina cu cea mai mare valoare pentru un agent este direcționarea către echipa responsabilă și triajul, nu generarea de cod.
Rezultatele utile ale unui agent rezistă unei examinări atente și explică relațiile cauzale, nu doar identifică tipare.
Proiectarea stratului de colectare a dovezilor și de construire a contextului contează mai mult decât stratul de generare.
Majoritatea discuțiilor despre codarea agentivă pornesc încă de la o promisiune simplă: mai mult cod, scris mai repede.
Uneori, aceasta se extinde într-o viziune mai ambițioasă, în care agenții planifică activitatea, deschid PR-uri și livrează modificări cu o intervenție umană minimă. Dar, pentru majoritatea echipelor de inginerie, cea mai evidentă valoare pe termen scurt are un domeniu mai restrâns. Este vorba despre reducerea costului iterațiilor.
Livrarea de software nu înseamnă doar generarea de cod. Scrierea codului este doar o etapă dintr-o buclă mai amplă, care include revizuirea, testarea, implementarea și investigarea situațiilor în care apar probleme. Majoritatea echipelor care adoptă codarea agentivă fără a regândi bucla de revizuire nu fac decât să mute blocajul într-o etapă ulterioară.
Simpla accelerare a generării nu face automat o echipă mai rapidă. Poate doar să transfere mai mult efort către revizuire, verificare și consolidarea încrederii.
În multe medii de inginerie, partea costisitoare nu este realizarea unei prime versiuni, ci dobândirea încrederii în aceasta.
Modificarea a remediat într-adevăr problema sau a îmbunătățit sistemul? A introdus o regresie în altă parte? Defecțiunea se află în cod, în mediu, în teste sau într-o dependență? Soluția propusă abordează cauza sau doar simptomul vizibil?
Agenții pot ajuta aici nu pentru că înlocuiesc inginerii, ci pentru că pot face o primă analiză structurată a unor dovezi neuniforme: pot examina jurnale, compara modificări recente, rezuma semnalele relevante, urmări cauzele probabile, executa verificări și furniza un rezultat pe care o persoană îl poate analiza critic.
În multe echipe, utilizarea cu cel mai mare impact a unui agent nu este generarea codului de la zero. Este restrângerea spațiului de căutare din jurul unei probleme înainte ca o persoană să petreacă ore întregi făcând manual acest lucru.
Acest lucru este deosebit de evident în fluxurile de depanare la scară largă. Imaginează-ți că, în fiecare noapte, sistemul CI rulează milioane de teste în baze de cod modificate de sute de ingineri — o situație reală pentru unul dintre clienții noștri. Când apare o eroare, este dificil de stabilit echipa responsabilă. Problema poate fi în codul aplicației, într-o dependență, în infrastructura de testare sau în altă parte a stivei. Jurnalele pot ajunge la dimensiuni de ordinul gigabyților, iar prima echipă care observă problema nu este întotdeauna cea care răspunde de ea.
Un astfel de flux de lucru nu presupune în mod firesc ca un singur agent să scrie soluția. Este conceput pentru un sistem care restrânge rapid spațiul problemei.
Un flux util ar putea prelua jurnalele, selecta dovezile relevante, rezuma aspectele importante, inspecta codul într-un sandbox și genera o analiză structurată a cauzei principale, cu un scor de încredere, trasabilitate și sugestii privind pașii următori. Pentru a genera scorul de încredere, un expert în domeniu evaluează rezultatul inițial al agentului. Această evaluare este apoi furnizată unui LLM folosit ca evaluator, pentru a automatiza pe viitor procesul de notare, păstrând în același timp alinierea cu judecata umană.
Ideea nu este eliminarea judecății inginerești, ci oferirea unui punct de plecare mai solid pentru cei care fac evaluarea. Triajul regresiilor, revizuirea PR-urilor, remedierea testelor, validarea versiunilor și investigațiile de după implementare au toate aceeași structură. Implică multe dovezi, necesită multă revizuire și sunt pline de ambiguități. Nu îi cer unui agent să înlocuiască procesul de inginerie, ci doar să ajute la continuarea și avansarea acestuia.
Acesta este și motivul pentru care echipele trebuie să evalueze cu atenție aceste sisteme.
Întrebarea greșită este dacă un agent poate produce, în mod izolat, ceva impresionant. Întrebarea mai bună este dacă îmbunătățește un flux de lucru real fără a crea dificultăți în altă parte.
Aceasta înseamnă să verificăm dacă rezultatul este suficient de precis pentru a putea fi validat, dacă explică relațiile cauzale în loc să se limiteze la identificarea tiparelor și dacă simplifică revizuirea în loc să o îngreuneze. Un răspuns plauzibil nu este neapărat și util. În practică, echipele au încredere în rezultatul unui agent atunci când acesta rezistă unei examinări atente și le oferă ceva concret de verificat.
Lecția mai profundă este că sistemele agentive utile depind de mai mult decât de generarea de conținut. Ele depind de modul în care sunt colectate dovezile, construit contextul și verificate rezultatele, precum și de felul în care incertitudinea îi este prezentată evaluatorului.
De aceea, viitorul apropiat al ingineriei agentive nu va consta probabil într-un salt uriaș către autonomia deplină. Este mai probabil să constea într-un ansamblu de bucle proiectate riguros, în care agenții ajută echipele să își examineze, revizuiască, verifice și perfecționeze activitatea, reducând efortul irosit între etape.
Poate părea mai puțin spectaculos decât viziunea mai amplă asupra autonomiei, dar reflectă mult mai bine modul în care sunt adoptate în realitate sistemele utile.