Lansarea în echipă

La finalul capitolului poți rula agenți în siguranță într-un repository real și poți porni un rollout așa cum încep cele mai multe rollout-uri reușite: cu un singur inginer.

TL;DR

• Pe un repo real, dă muncii agentului propriul worktree, pune hook-uri și pe agent, și pe git și păstrează un prag minim de review uman pe care nu-l înlocuiește niciun bot de review.
• Cele mai multe adopții încep cu un singur inginer, nu cu trei roluri: folosești agentul tu însuți, scrii ce ai făcut, îl înveți pe un coleg, apoi îi recrutezi pe lead și pe manager. Prima lună nu arată aproape niciun câștig; câștigul se compune după aceea.
• Numește cele două arhetipuri de ingineri și planifică săptămâna proastă a vendorului înainte să te prindă vreuna dintre ele.

Guardrails pentru un repo real

Agentul e încă un autor cu acces de scriere, așa că dă-i granițele pe care le primește orice autor.

Obiceiurile astea la nivel de repo se așază peste cele cinci straturi din Capitolul 2 și contează cel mai mult pe codebase-uri galbene (Capitolul 8). Pragul minim de review uman pe care nu-l înlocuiește niciun bot de review ține de Capitolul 5.

Worktree-uri

Fiecare sesiune de agent primește propriul git worktree.

Un worktree e o copie separată a repository-ului, checked out pe propriul branch. Agentul poate experimenta, eșua și relua acolo fără să atingă copia de lucru a nimănui. Munca bună trece prin review-ul normal de PR; munca proastă înseamnă un director șters. Fără worktree, agentul se încurcă în lucrul tău local neterminat, iar tu pierzi o oră încercând să-ți dai seama ce s-a schimbat.

Două feluri de hook-uri

Pune hook-uri pe agent, pune hook-uri pe repository și rulează aceleași verificări în CI.

• Hook-ul de agent (hookify sau echivalentul agentului tău) citește acțiunea propusă și fie o permite, fie îți cere confirmarea, fie o blochează. Țintește-l spre zonele prea periculoase ca să fie modificate fără review de la un senior: criptografie, plăți, migrări de date, orice ține de reglementări. Regulile trăiesc în repository, versionate în git; cinci până la zece sunt de obicei suficiente pe un proiect galben. AGENTS.md e rugămintea politicoasă; hook-ul e granița fermă.
• Hook-ul de git rulează pentru oricine face commit - tu, un coleg sau agentul - așa că o singură verificare acoperă toți autorii. Verificările rapide (formatare, lint, verificare de tipuri, scanare de secrete) rulează la commit, testele și build-ul la push, iar un manager de hook-uri cu configurație versionată se asigură că hook-urile se instalează pentru oricine clonează repository-ul.
• Portița de scăpare e --no-verify. Închide-o cu o regulă de deny în hook-ul de agent.

Hook-urile locale rămân feedback rapid, nu enforcement: se pot sări, se configurează într-un fișier pe care agentul îl poate edita și nu sunt garantate pe fiecare mașină. Aceleași verificări în CI nu pot fi sărite de pe un laptop; cu configurația de hook-uri și workflow-ul de CI puse în spatele unei reguli de deny, ăsta e gate-ul pe care agentul nu-l poate edita.

Cum ții practica vie

Regulile se învechesc, așa că cineva răspunde de curățarea lor.

Jurnalul de greșeli și championul lui țin de Capitolul 6. Pentru greșelile de proces, ține un watchlist de eșecuri: eșecurile recurente, ce le declanșează și răspunsul standard al echipei. Parcurge-l cam o dată pe lună și retrage ce s-a rezolvat.

Bucla exterioară

Rulează agentul nesupravegheat doar sub un contract scris.

Bucla exterioară (outer loop) reinvocă agentul până când o condiție e îndeplinită. Adaugă încercări, nu judecată, așa că multiplică orice permite bucla ta interioară (inner loop; Capitolul 4). Folosește-o doar pe codebase-uri VERZI (Capitolul 8), pe multe unități similare, verificabile și reversibile, și citește pull request-urile dimineața.

Înainte de prima rulare nesupravegheată, scrie cinci linii: o condiție de oprire pe care o poate evalua o mașină; un buget; un gate pe care agentul nu-l poate edita; context proaspăt la fiecare iterație, cu starea în repository; izolare dimensionată pentru absență (worktree propriu, sandbox pornit, fără credențiale de producție, rețea constrânsă). Anexa B.6 e formularul de completat, cu cele patru semne care cer stop înainte să relansezi.

Cum faci rollout-ul agenților AI de cod într-o echipă?¶

Începe cu un singur inginer care refuză să renunțe, nu cu un program.

Prima dată când am predat grila celor trei roluri, un inginer din ultimul rând a zis: „Managerul meu n-a auzit de AI agentic. Lead-ul meu n-are timp. Sunt singurul om din echipă căruia îi pasă. Eu ce fac?”

Pentru el, arcul cu trei roluri s-ar împotmoli în luna a doua, când conversația de procurement nu se întâmplă niciodată. Arcul grassroots (de jos în sus) nu s-ar împotmoli și e felul în care au început cele mai multe adopții reușite din 2025 și 2026: o singură persoană joacă pe rând rolul de champion, apoi de lead de facto, apoi de avocat al adopției pe lângă manager. L-am văzut reușind de două ori.

• Luna 1: folosește-l pe munca ta. Review-uri de arhitectură, schițe de AGENTS.md și bucla în șase faze pe codul pe care îl deții, în interiorul politicilor existente. Fără anunțuri; strânge dovezi în liniște.
• Luna 2: pune-l pe hârtie. Un memo de o pagină: story-uri livrate, timp economisit, note oneste acolo unde agentul n-a ajutat. Povestește ce ai făcut; nu face pitch de adopție.
• Luna 3: învață-l pe colegul care întreabă. Scrie împreună cu el un caz mai consistent și invită-ți tech lead-ul la un walkthrough.
• Lunile 4-6: lead-ul recrutează managerul cu dovezi și cu doi ingineri care cer același workflow.

Până în luna șase, practica arată cum arăta arcul ideal în luna trei - dar a durat de două ori mai mult. Compromisul: arcul grassroots pornește repede și e fragil, pentru că dacă singurul inginer pleacă înainte să fie recrutați colegii și managementul, practica moare odată cu el. Arcul cu trei roluri pornește mai încet și rezistă la o plecare. Dacă ai un manager care știe de agenți, un lead implicat și buget, fă arcul cu trei roluri; dacă ai doar propriile ore, fă arcul grassroots.

Arcul de 90 de zile

Curba e asimetrică: primele treizeci de zile nu produc aproape nicio productivitate măsurabilă.

Zilele 31-60 arată câștiguri vizibile pe proiectul verde; zilele 61-90 se compun la nivelul întregii echipe. Companiile care măsoară la treizeci de zile vor fi dezamăgite, așa că spune-le stakeholderilor din capul locului. Calendarul complet e în Anexa B.5.

Angajamentele rolurilor

Fiecare angajament e suficient de mic încât să încapă pe lângă munca normală.

Championul învață primul workflow-ul. Trebuie să fie cel mai dispus să investească primele șaizeci de ore, nu cel mai senior.

• [ ] Săptămâna 1: instalează agentul, rulează review-ul de arhitectură (Capitolul 7) pe un codebase familiar și dă commit artefactului.
• [ ] Săptămâna 2: scrie primul AGENTS.md, sub cincizeci de linii, și invită echipa să contribuie prin pull request-uri.
• [ ] Săptămânile 3-4: rulează bucla în șase faze (Capitolul 4) pe trei feature-uri mici; notează fricțiunile în jurnalul de greșeli.
• [ ] Lunile 2-3: trei feature-uri medii, în care alții preiau câte o singură fază, apoi predă rolul; până în ziua 90, un alt inginer rulează workflow-ul la fel de fluent.

Lead-ul decide ce proiecte primesc agentul și ține semaforul.

• [ ] Săptămâna 1: clasifică primele cinci proiecte după cele opt kill signals (Capitolul 8) și împărtășește culorile.
• [ ] Săptămânile 2-4: pentru câte un proiect de fiecare culoare, scrie ce ar trebui să se schimbe ca să treacă la culoarea următoare.
• [ ] Lunile 2-3: urmărește cycle time-ul, rata de defecte și timpul reviewerilor (cifre zgomotoase; măsoară oricum), apoi prezintă rezultate oneste, inclusiv unde agentul n-a livrat.

Managerul deține bugetul, procurement-ul și sign-off-ul de guvernanță și protejează echipa de metrici premature. Pagina lui e Anexa A, cu proiectul de 20 de ingineri în care PR-urile atinse de agent (41% din total) au avut un cycle time cu 28% sub baseline-ul de dinainte de agent, iar defectele au rămas în marja de zgomot.

Două arhetipuri care omoară rollout-urile

Tratează-l pe fiecare ca pe o problemă structurală cu o soluție structurală, nu ca pe un defect de caracter.

Scepticul de principiu e seniorul care a mai văzut cicluri de hype AI, nu va folosi agentul și face review la PR-urile conduse de agent cu o ostilitate sporită. Ori echipa lucrează pe lângă el și codebase-ul se bifurcă în teritorii prietenoase cu agentul și teritorii ostile, ori el câștigă disputa și rollout-ul se blochează. Nu încerca să-l convertești; dă-i o graniță: „modulele tale, regulile tale, agentul nu se atinge de ele; peste tot în rest se aplică standardul echipei”. Și nu lăsa fiecare PR condus de agent să stea în queue-ul lui, altfel i-ai dat un drept de veto pe care nu l-a vrut nimeni.

Delegatorul necalibrat sare peste citirea atentă pentru că „agentul o nimerește mereu”. Defectele se adună, echipa dă vina pe agent, nu pe pasul de review care lipsește, iar până la urmă inginerul nu mai poate depana ce a ajutat agentul să construiască. Fiecare PR condus de agent primește același review uman ca unul condus de om. În prima lună, pune-l în pereche cu un senior care citește output-ul linie cu linie.

Vendorul va avea o săptămână proastă

Planifică pentru situația în care agentul nu e disponibil.

Am văzut velocity-ul unei echipe înjumătățindu-se timp de o săptămână pentru că modelul lor principal era rate-limited. În iunie 2026, cel mai nou tier flagship al celui mai mare vendor a fost retras la nivel mondial la câteva zile după lansare și a rămas indisponibil aproape trei săptămâni; echipele cu fallback și-au rulat planurile pe bune, iar cele fără și-au redescoperit setup-ul anterior pe deadline. Ține un fallback non-agentic pentru munca sensibilă la timp, un senior care încă poate livra un hotfix la trei dimineața și un runbook pentru „agentul e throttled și clientul așteaptă”.

Când se strică

De făcut luni

• [ ] Configurează un git worktree pe un proiect pe care urmează să trimiți agentul și fă munca agentului acolo.
• [ ] Alege-ți rolul - champion, lead sau manager - fă săptămâna asta primul angajament din checklist-ul lui și pune-l în calendar.
• [ ] Adaugă o regulă de hook de agent pe cel mai periculos director al tău, o regulă de deny pe --no-verify și aceleași verificări în CI.
• [ ] Scrie fallback-ul pentru o săptămână de cădere a vendorului: cine livrează hotfix-ul fără agent.

Mai departe

• Template-uri: Anexa B.5, calendarul de 90 de zile cu traseul managerului; B.6, contractul buclei exterioare; B.4, fișa de punctare a kill signals.
• Deep dive: Anexa D, Capitolul 9 - filiația buclei exterioare și cronologia vendorilor, plus cele două feluri de hook-uri în întregime.
• Pentru manageri: Anexa A.
• Surse: Anexa C.