De la scriere manuală de cod la orchestrare de agenți: cum se redefinește rolul programatorului

Joelle Danciu
Software Developer @ BMW TechWorks Romania

Edward Vlad
Software Engineer @ BMW TechWorks Romania

PROGRAMARE

Dezvoltarea software a parcurs mai multe transformări fundamentale de-a lungul anilor. Ceea ce a început ca scriere manuală de cod evoluează, se pare, către orchestrare de sisteme inteligente. Rolul programatorului s-a redefinit constant, generând implicații pentru industrie și economie. Ne aflăm din nou într-un astfel de moment, așa că am decis să experimentăm orchestrarea de agenți. Dar înainte să împărtășim observații despre unde și când orchestrarea poate să aducă valoare, să detaliem puțin contextul istoric.

De la editoare simple la IDE-uri inteligente

Programarea a evoluat prin straturi succesive de abstractizare. IDE-urile au transferat sarcina cognitivă prin validare în timp real și refactoring automatizat. Frameworkurile au schimbat paradigma către composition-as-product, construirea rapidă prin configurare, nu implementare de la zero. Package managers au transformat dezvoltarea într-un model supply chain unde codul devine modular și reutilizabil.

Fiecare strat a democratizat accesul: ceea ce necesita programatori seniori a devenit accesibil practicienilor intermediari. Totuși, toate aceste tooluri rămân asistenți pasivi. Programatorul reținea proprietatea cognitivă completă, IDE-ul sugera, dar programatorul decidea și scria.

Primul val AI: Conversația cu cunoștințele

ChatGPT a democratizat accesul la limbajul natural ca mecanism de interogare pentru cunoștințele tehnice. În loc de Stack Overflow și keyword search, programatorii descriu probleme și primesc explicații personalizate. Studiile au arătat o reducere de 30-50% a timpului pentru probleme de rutină. Juniorii obțineau acces la explicații de nivel senior, aplatizând curba de învățare.

Totuși, workflow-ul rămânea manual, programatorii copiau, adaptau, testau și integrau. IA juca rolul de motor de căutare mai avansat, nu era un partener de dezvoltare.

Co-Crearea: Colaborare în timp real

GitHub Copilot a marcat saltul de la Q&A la co-autorat în timp real. Spre deosebire de ChatGPT unde utilizatorul primea răspunsuri pe care le copia manual, Copilot generează cod direct în editor, inline, în timp ce lucrezi. Inițial, modelul genera implementări complete din comentarii: programatorul revizuia propuneri, le accepta sau modifica. Dezvoltarea devine conversație. Bottleneckul se mută de la viteză de tastare la claritatea intenției și calitatea review-ului.

Evoluția a continuat rapid. Funcționalitatea de chat a permis întrebări și explicații contextuale. Apoi au apărut capabilități mai complexe:

Adăugare de context prin selectare de cod și includere de fișiere multiple;
Instrucțiuni Markdown personalizate care ghidează comportamentul pentru proiecte specifice;
Agent mode și plan mode pentru execuție autonomă de taskuri;
Integrări cu MCP pentru acces la tooluri externe.

Toate astea au încurajat o nouă direcție pentru rolul programatorului: orchestrarea de workflow-uri de agenți.

Workflow-urile de orchestrare de agenți

Cu ajutorul orchestrării, putem coordona mai mulți agenți care să lucreze pe aceeași problemă complexă. Pentru acest proces avem nevoie de o granularizare precisă, care necesită expertiză tehnică reală, pragmatism și o analiză complexă în prealabil.

De ce este importantă granularizarea în mai mulți sub-agenți?

Problemele complexe deseori depășesc capacitățile unui singur model LLM, ducând la halucinație înainte de finalizarea cu succes a rezolvării problemei. Performanța modelelor LLM nu este uniformă pe tot contextul disponibil. Cercetarea "Lost in the Middle" a documentat un anume pattern: modelele performează cel mai bine când informația relevantă se află la începutul sau sfârșitul contextului și se degradează semnificativ când trebuie să acceseze informație din mijlocul unui context lung.

Această degradare poartă denumirea de long-context performance degradation sau "context rot" în limbaj colocvial.

Concret, în sesiuni lungi de lucru, agentul poate ignora o decizie luată mai devreme, poate repeta o abordare care a eșuat sau poate pierde din vedere constrângeri stabilite inițial. Nu neapărat pentru că a uitat informația, ci pentru că mecanismul de atenție nu tratează uniform toată informația din context. Problema apare chiar și când informația este tehnic prezentă.

Granularizarea în sub-agenți cu contexte mai scurte și bine delimitate reduce suprafața acestei probleme: fiecare sub-agent lucrează pe un context mai restrâns, unde informația relevantă este mai accesibilă. Orchestrarea nu elimină problema, însă o redistribuie, introducând riscuri noi pe care le vom discuta în continuare.

Când poate orchestrarea să devină o problemă?

În teorie, este simplu să împărțim un task în N sub-taskuri, iar mai mulți agenți pot executa munca, dar în practică dacă workflow-ul este definit greșit, erorile se propagă cu ușurință de la un agent la altul. Operând într-un mediu lipsit de determinism, prevenția erorilor este mai complicată, nu imposibilă, dar cu costuri mai ridicate.

Dacă intervine un context rot la unul dintre agenții din workflow, este posibil ca întreg taskul să fie compromis sau ca erorile generate de workflow să necesite mai mult timp de rezolvare decât dacă munca ar fi fost făcută fără acel sistem complex.

Harnessul agentului

Pentru a orchestra agenți în mod fiabil, fiecare agent trebuie construit cu un set clar definit de capabilități, limite și context de operare. Acest cadru se numește în practică harness. Harnessul reprezintă echipamentul cu care se dotează agentul: instrucțiuni, tooluri, agent memory, skilluri etc.

Instrucțiunile

Instrucțiunile din harnessul unui agent sunt practic un set de reguli și directive care îi definesc comportamentul într-un context dat. Ele răspund practic la câteva întrebări esențiale: ce rol are agentul (developer, arhitect, tester etc.), ce tooluri are la dispoziție, ce are voie să facă și ce nu, în ce ordine lucrează și cum arată outputul pe care îl produce.

Agent skills

Skillurile sunt capabilitățile modulare pe care agentul le poate folosi ca să rezolve sarcini concrete. Fiecare skill încapsulează logică specializată: de exemplu, "scrie un unit test", "analizează complexitatea codului" sau "generează o diagramă de arhitectură". Ceea ce este util la skilluri este că pot fi combinate între ele pentru fluxuri mai complexe, de exemplu: scrie cod → testează → refactorizează.

Agent tools

Dacă skillurile definesc ceea ce știe să facă agentul, toolurile sunt cele prin care chiar face. Concret, vorbim despre execuție de comenzi bash, citire/scriere de fișiere, apeluri API, căutare web, acces la baze de date, rulare de teste și multe altele. O evoluție relevantă în spațiul acesta sunt MCP-urile (Model Context Protocol), adică niște standarde care permit conectarea agentului la servicii externe (GitHub, Jira, Figma etc.) într-un mod uniform, fără să fie nevoie de integrări custom pentru fiecare serviciu.

Memory

Memory-ul unui agent se referă la modul în care reține și accesează informații în timp. Poate fi in-context (ceea ce s-a discutat în sesiunea curentă), externă (baze de date vectoriale, fișiere sau note care persistă între sesiuni) sau procedurală (patternuri acumulate despre cum să abordeze anumite tipuri de probleme).

În esență, harnessul este cadrul de operare care transformă un model de limbaj generic într-un agent specializat, controlat, gata să fie integrat într-un workflow cu mai mulți agenți. Din acest motiv este esențial să setăm corect acest cadru pentru fiecare agent în parte.

Modelul de IA folosit

Agentul este influențat și de performanța modelului LLM folosit. Modelele mai mici sunt mai rapide și mai ieftine, dar pot realiza taskuri mai puțin complexe. Modelele mai mari sunt mai performante, dar mai scumpe și mai lente. Criteriul de selecție este să alegem potrivit pentru rolul agentului.

Rol nou în piață: arhitect de workflow-uri?

Când agenții sunt corect configurați și workflow-ul este granularizat corespunzător pentru a evita un context rot, orchestrarea devine posibilă. Construirea și integrarea acestor agenți într-un sistem necesită expertiză specializată. Aici intervine o nouă responsabilitate: identificarea contextelor în care un workflow este necesar și posibil și, la fel de important, a celor în care nu este, în care soluții IA mai simple aduc un randament mai bun. Această responsabilitate presupune alinierea între obiectivele și businessul proiectului și costurile de implementare ale unui workflow care să aducă valoare reală. Deci este posibil, din punctul nostru de vedere, ca în viitor să avem un astfel de rol specializat pe piață: arhitect de workflow-uri de agenți.

Concluzii

Expertiza tehnică rămâne esențială, dar nu pentru boilerplate, ci pentru decizii complexe și de design. Programarea se transformă într-o disciplină mai strategică și mai solicitantă la nivel de gândire de sistem.

Toolurile s-au schimbat, dar provocarea fundamentală rămâne: construirea sistemelor software care rezolvă probleme reale, fiabil și la scară. Dar de data aceasta le rezolvăm: