--- title: "Un agent sau o echipă de agenți? Cum coordonăm dezvoltarea fără conflicte" description: "Un agent sau mai mulți? Delegare, spații de lucru separate, predarea rezultatelor și integrarea codului fără suprascrieri." canonical: https://i8.ro/blog/un-agent-sau-o-echipa-de-agenti-cum-coordonam-dezvoltarea-fara-conflicte --- # Un agent sau o echipă de agenți? Cum coordonăm dezvoltarea fără conflicte > Un agent sau mai mulți? Delegare, spații de lucru separate, predarea rezultatelor și integrarea codului fără suprascrieri. Sursă: https://i8.ro/blog/un-agent-sau-o-echipa-de-agenti-cum-coordonam-dezvoltarea-fara-conflicte **Seria II: De la infrastructură la proiecte agentice în producție. Episodul 09 din 20.** În episodul anterior am ales unde lucrează agentul de programare: IDE, terminal sau cloud. Acum trebuie decis câți agenți lucrează la aceeași schimbare și cine integrează rezultatele. Mai multe sesiuni pornite simultan pot părea o scurtătură, dar două modificări corecte separat pot fi incompatibile împreună. Pentru un IMM, decizia practică este să înceapă cu un agent și să adauge paralelism numai când sarcinile au limite clare și un punct comun de integrare. ## Pornim de la o schimbare verificabilă Folosim un scenariu ipotetic din portalul B2B pentru solicitări și documente al acestei serii. După validarea încărcărilor PDF, echipa vrea un flux prin care un angajat aprobă documentul și clientul vede starea. Schimbarea cuprinde contractul API, logica de stare, interfața, testele și mesajele de eroare. Nu reprezintă un proiect sau rezultat real al unui client. Un singur agent poate implementa o primă versiune pe o ramură separată. Primește criterii de acceptare, regulile repository-ului și comenzile de test descrise în [episodul despre pregătirea codului](https://i8.ro/blog/cum-pregatim-codul-pentru-agenti-ai-context-reguli-si-medii-de-test). Echipa evaluează diferența de cod, testele și întrebările rămase. Dacă sarcina încape într-un context ușor de urmărit, nu este nevoie de un coordonator automat ori de sesiuni paralele. ## Când merită împărțită munca Separarea devine utilă când o parte poate fi descrisă și verificată fără a aștepta permanent alta. În exemplu, echipa stabilește mai întâi contractul dintre API și interfață: valorile stării, răspunsurile la erori și regulile de tranziție. Abia apoi agentul A poate implementa logica serverului, iar agentul B poate construi interfața pe baza aceluiași contract. Testele de integrare verifică dacă presupunerile ambilor se întâlnesc. Aceasta este **execuție secvențială urmată de paralelism**. Un pas comun rezolvă dependența, apoi părțile relativ independente avansează simultan. Un coordonator, uman sau software, distribuie sarcini și sintetizează rezultate; această activitate se numește **orchestrare**. Coordonatorul nu trebuie confundat cu aprobatorul final al codului. Dacă o modificare atinge aceleași funcții, scheme de date sau reguli de business ca alta, este mai sigur să fie făcută secvențial ori să fie redelimitată. Cercetarea despre agenți multipli arată că izolarea și integrarea structurată pot ajuta în anumite evaluări de inginerie software, dar rezultatele publicate nu garantează câștiguri pentru portalul nostru. Chiar și un exemplu industrial de cercetare multi-agent avertizează că programarea are adesea mai puține sarcini cu adevărat paralele decât cercetarea. Măsura utilă este rezultatul acceptat, nu numărul de agenți porniți. ## Spații de lucru separate, contract comun În Git, un **branch** este o linie de modificări pornită dintr-o versiune de bază. Un **worktree** este un director de lucru suplimentar legat de același repository, care permite folosirea simultană a mai multor ramuri fără ca agenții să scrie în aceeași copie de fișiere. Un mediu cloud izolat poate oferi o separare asemănătoare, în funcție de platformă. Pentru exemplu, fiecare agent pornește de la același commit cunoscut, primește propriul branch și propriul spațiu de lucru. A deține temporar fișierele logicii de stare, B componentele interfeței. „Deținere” înseamnă responsabilitate de coordonare, nu o restricție garantată de Git: un agent poate modifica și alte fișiere dacă are permisiuni. Instrucțiunile trebuie să îi ceară să se oprească și să raporteze când descoperă necesitatea unei schimbări în aria celuilalt. Izolarea fizică previne suprascrierea accidentală a fișierelor dintr-un director comun, dar nu rezolvă conflictele semantice. Două ramuri pot fi îmbinate fără conflict textual, deși una schimbă semnificația unui câmp folosit de cealaltă. Nu copiați credențiale în worktree-uri doar ca să ruleze testele; folosiți date sintetice și accesul minim necesar, conform regulilor proiectului. ## Predarea: mai mult decât „am terminat” Un **handoff** este predarea unui rezultat între agenți sau către persoana care integrează. Pentru fiecare sarcină, cereți aceeași fișă scurtă: 1. Obiectivul și commitul de bază, branch-ul și fișierele schimbate. 2. Ce comportament a fost implementat și ce criterii de acceptare sunt acoperite. 3. Comenzile rulate și rezultatele lor, inclusiv teste eșuate sau neverificate. 4. Ipotezele despre contractul comun, schimbările în afara ariei și riscurile observate. 5. Întrebările deschise și pașii necesari pentru integrare ori revenire. Fișa nu este dovadă suficientă prin ea însăși. Integratorul citește diferența reală, rulează verificările pe codul combinat și compară comportamentul cu cerința. Dacă agentul B a presupus starea „aprobat”, iar API-ul livrează „acceptat”, această neconcordanță trebuie rezolvată înainte de îmbinare, nu ascunsă printr-un test ajustat superficial. ## Cine integrează și cine aprobă Stabiliți un singur responsabil pentru integrarea tehnică a schimbării, de regulă un dezvoltator sau un agent coordonator supravegheat. El decide ordinea ramurilor, rezolvă conflictele și rerulează testele după fiecare integrare relevantă. O verificare reușită pe ramura A și una pe ramura B nu implică automat că versiunea A+B funcționează. Un pull request, adică o cerere de integrare revizuită, păstrează diferența și discuția într-un loc. Regulile de protecție a ramurii pot cere review și verificări automate înainte de îmbinare. Persoana desemnată de echipă acceptă comportamentul final și riscul rămas. Agenții pot propune cod, teste și observații, dar nu devin prin aceasta proprietarii deciziei de lansare. Păstrați și o cale de oprire: dacă două sarcini încep să editeze același contract sau testele integrate eșuează, suspendați paralelismul, actualizați specificația și reluați dintr-o bază comună. Evitați rezolvarea automată a conflictelor doar pentru a obține un commit care se îmbină. ## O regulă de selecție aplicabilă mâine Pentru fiecare schimbare, notați dependențele și persoana care acceptă rezultatul. Folosiți un agent când problema are un rezultat unic și schimbări strâns legate. Adăugați un al doilea agent pentru o parte cu interfață stabilă, spațiu separat și teste proprii. Introduceți coordonare explicită când există mai multe livrări care trebuie combinate, nu doar pentru că instrumentul permite lansarea lor. Comparați durata până la o schimbare acceptată, intervențiile de integrare, regresiile și consumul de resurse cu varianta unui singur agent pe sarcini similare. Rezultatul acestui episod este contractul de predare și regula de integrare, pe care echipa le poate adăuga în repository. Episodul următor va trata ce informații pot fi păstrate și partajate între sesiuni, cu proveniență și limite de acces. Aici vorbim despre agenții care dezvoltă portalul. Un agent integrat în portal pentru procesarea documentelor clienților are altă identitate, alte date și alte aprobări; nu primește automat acces la repository sau la instrumentele echipei de dezvoltare. ## Surse - [Anthropic, Building effective agents, 19 decembrie 2024](https://www.anthropic.com/engineering/building-effective-agents), pentru tiparele de delegare și criteriul simplității; articolul însuși avertizează că instrumentele descrise s-au schimbat ulterior. - [Anthropic, How we built our multi-agent research system, 13 iunie 2025](https://www.anthropic.com/engineering/multi-agent-research-system), pentru costul coordonării și limita transferului concluziilor din cercetare la programare. - [Git, documentația git-worktree](https://git-scm.com/docs/git-worktree.html) și [GitHub Docs, protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches), pentru spații de lucru și verificări la integrare. - [Geng și Neubig, Effective Strategies for Asynchronous Software Engineering Agents, arXiv, versiunea 8 iulie 2026](https://arxiv.org/abs/2603.21489), pentru evaluarea izolării, delegării și integrării; rezultatele sunt limitate la sarcinile studiate. Vrei să delimitezi sarcinile agenților și să păstrezi controlul asupra integrării codului? [Discută cu echipa i8](https://i8.ro/contact).