Pattern-uri pentru codebase-uri brownfield

Semaforul îți spune care codebase-uri sunt pregătite pentru agent. Capitolul ăsta e despre pattern-urile operaționale care fac lucrul cu agenți eficient pe codebase-uri legacy - în special pe proiectele galbene, acolo unde practica contează cel mai mult. Ultimul pattern e excepția; e ceea ce devine posibil când un codebase promovează la verde.

Voi trece prin opt pattern-uri. Primele patru sunt pattern-urile de operare implicite pe care le instalez în majoritatea echipelor brownfield: worktree-uri, championi, hook-uri și review-ul de PR-uri. Ultimele patru sunt pattern-uri de maturitate, pentru echipele care au trecut de primele luni: review-ul jurnalului de greșeli, plasa de siguranță pentru demo (demo-day backstop), watchlist-ul de eșecuri și bucla exterioară (outer loop). Între cele două seturi, un sidebar acoperă guvernanța pentru companiile care vând AI propriilor clienți - o preocupare specifică unui segment, nu un pattern de operare brownfield, dar care merită numită.

Fiecare dintre ele e ceva ce am văzut cu ochii mei făcând diferența între un agent care contribuie și un agent care frustrează.

Pattern-ul unu: worktree-urile.

Fiecare sesiune de agent rulează în propriul ei git worktree. Un worktree e o copie separată a repository-ului, checked out pe un branch separat. Agentul poate să experimenteze, să eșueze, să reia, să refactorizeze pe worktree-ul lui fără să atingă copia de lucru a nimănui. Când rezultatul e bun, branch-ul trece prin review-ul normal de PR. Când rezultatul e prost, ștergi worktree-ul și o iei de la capăt.

Costul daunelor asupra stării locale, cu worktree-uri: aproape zero. Tentativa ratată a agentului nu atinge niciodată copia ta de lucru - nici pe a altcuiva.

Costul unui eșec fără worktree-uri: agentul se încurcă în lucrul tău local neterminat, strică ceva subtil, iar tu pierzi o oră încercând să-ți dai seama ce s-a schimbat.

Worktree-urile sunt cea mai subapreciată funcționalitate din git pentru lucrul cu agenți. Orice developer dintr-o echipă care programează cu agenți ar trebui să aibă comanda git worktree add în reflex. Folosește-le.

Pattern-ul doi: championii.

O singură persoană din echipă deține AGENTS.md și jurnalul de greșeli pentru un repository dat. Championul face mentenanța săptămânală: citește ce au adăugat ceilalți developeri în jurnalul de greșeli, refactorizează regulile care s-au adunat, scoate din uz regulile care nu se mai aplică, actualizează convențiile când practica echipei se schimbă.

Championul se rotește trimestrial. Primul champion are costul cel mai mare - el pune pattern-urile pe picioare. Următorii au costul cel mai mic - ei doar întrețin. Rotația previne single-point-of-failure pe tribal knowledge-ul despre „cum folosim noi agenții aici”. Și mai face ceva: distribuie practica; fiecare senior din echipă ajunge la un moment dat la rând, fiecare senior internalizează mentenanța.

Championul nu e singura persoană care editează AGENTS.md. Toată lumea îl editează, prin pull request-uri, când dă peste un pattern nou sau o greșeală nouă. Treaba championului e curatoriatul, nu autoratul. Distincția contează: dacă championul e singurul autor, fișierul devine opinia unei singure persoane despre cum se lucrează cu agenți, iar practica reală a echipei o ia în altă direcție. Dacă toți scriu și championul curatoriază, fișierul reprezintă experiența colectivă a echipei, ținută în frâu de un singur responsabil la un moment dat.

Pattern-ul trei: două feluri de hook-uri.

hookify (sau plugin-ul echivalent al agentului tău) îți permite să scrii hook-uri care se declanșează înainte de execuția unui tool. Hook-ul citește acțiunea propusă, o evaluează după reguli custom și fie o permite, fie îi cere utilizatorului confirmarea, fie o blochează.

Cazul de utilizare pentru hookify în lucrul brownfield e unul precis. Ai zone din codebase pe care e periculos să le modifici fără review de la un senior - module de criptografie, procesare de plăți, scripturi de migrare de date, orice ține de reglementări. Scrii o regulă hookify care blochează agentul să modifice fișiere din directoarele alea sau care cere confirmare explicită de la utilizator când încearcă. Regula trăiește în repository, versionată în git, aplicată automat la fiecare sesiune.

Regulile hookify completează AGENTS.md. AGENTS.md îi spune agentului convențiile echipei și pattern-urile interzise; agentul le citește și le aplică din oficiu. hookify impune regulile structural; dacă agentul încearcă oricum să le încalce (pentru că LLM-urile mai fac și asta), hook-ul îl prinde. AGENTS.md e rugămintea politicoasă. hookify e granița fermă pe agent. Dar agentul nu e singurul autor cu acces de scriere, iar granița care leagă orice autor e un alt fel de hook.

Pentru proiectele galbene, recomand reguli hookify cel puțin pentru zonele sensibile din punct de vedere al reglementărilor și pentru modulele cu istoric de probleme. Cinci până la zece reguli sunt de obicei suficiente. Fiecare regulă înseamnă o linie de configurare plus o justificare de o linie.

Al doilea fel de hook nu e deloc pe agent. E pe repository. Git rulează hook-uri client-side la commit și la push, iar acestea se declanșează pentru oricine face commit - tu, colegul tău, agentul. Aici stă pârghia. Agentul e doar încă un autor cu acces de scriere, așa că un gate de commit i se aplică gratis, fără nicio cablare specifică agentului. Scrii verificarea o singură dată, pe însuși actul de a face commit, și acoperă deopotrivă codul agentului și pe al tău.

Împarte verificările după cost. Hook-ul pre-commit e trecerea rapidă - formatare, lint, verificare de tipuri, o scanare de secrete - lucrurile care rulează în câteva secunde și n-ar trebui să ajungă niciodată pe un branch. Hook-ul pre-push e trecerea mai grea - suita rapidă de teste, build-ul - pe care ți-o poți permite să o aștepți pentru că rulează o dată la fiecare push, nu o dată la fiecare commit. Ține testele în pre-push; un hook pre-commit trebuie să se termine în câteva secunde, altfel oamenii pun mâna pe portița de scăpare, iar de fiecare dată când sari peste, întărești obiceiul de a sări peste. Gestionează-le pe amândouă dintr-o configurație versionată, printr-un manager de hook-uri, ca hook-urile să se instaleze pentru oricine clonează repository-ul, în loc să stea neversionate în .git/hooks-ul unei singure mașini.

Portița de scăpare e --no-verify, iar agentul poate pune mâna pe ea la fel ca oricine; închizi ușa aia cu o regulă hookify de deny pe flag. Cele două granițe își acoperă reciproc unghiul mort: hookify prinde agentul în mijlocul sesiunii, înainte ca modificarea să ajungă în cod, iar gate-ul de git prinde orice autor, pe orice cale pe care hookify n-o vede niciodată, în momentul în care se scrie commit-ul. Fii însă cinstit cu privire la ce sunt hook-urile locale. Sunt feedback rapid, nu enforcement - se pot sări, se configurează într-un fișier pe care agentul îl poate edita el însuși și nu sunt neapărat instalate pe o anumită mașină. Aceleași verificări care rulează în CI sunt cele pe care nu le poți sări de pe laptopul tău, iar acea configurație de hook, împreună cu workflow-ul ei de CI, e gate-ul din pattern-ul opt pe care agentul nu-l poate edita. În orice caz, verificările deterministe nu derivează așa cum o pot face reviewerii probabilistici - un scanner de secrete fie găsește cheia, fie nu.

Pattern-ul patru: PR review toolkit.

Înainte ca un senior engineer să facă review pe un pull request produs de agent, un set de agenți de review trece primul prin diff. Silent failure hunter caută excepții înghițite, retry-uri fără limită, null check-uri lipsă. PR test analyzer identifică metodele noi cu acoperire slabă de teste și recomandă teste concrete de adăugat. Security scanner verifică categoriile standard de vulnerabilități. Documentation reviewer semnalează documentația lipsă sau învechită.

Agenții de review nu înlocuiesc review-ul uman. Rulează înaintea lui și scot la suprafață genul de probleme care se detectează mecanic. Reviewer-ul uman se poate concentra apoi pe lucrurile pe care doar oamenii le pot evalua: corectitudinea de business, potrivirea arhitecturală, deciziile de judecată.

Pârghia stă în timpul economisit pe constatările mecanice. Un senior engineer care face un review de cincisprezece minute prinde bug-urile evidente. Un senior engineer care face un review de cinci minute (pentru că agenții de review au prins deja bug-urile evidente) poate folosi celelalte zece minute pe judecata arhitecturală pe care agenții n-o pot face.

Configurează agenții de review. Leagă-i de fluxul de pull request. Agenții fac munca mecanică; oamenii fac munca de oameni.

O poveste de eșec pentru pattern-ul ăsta, pentru că e singurul cu un mod de eșec pe care celelalte nu-l au. O echipă cu care am lucrat a instalat toolkit-ul complet, și toolkit-ul era bun. Agenții de review prindeau bug-uri reale, săptămână după săptămână, iar reviewerii seniori au învățat să aibă încredere în bifele verzi. Într-un trimestru, review-urile umane de cincisprezece minute deveniseră scanări de trei minute. Nimeni n-a decis asta. Atenția alunecă singură de pe munca ce pare deja făcută.

Apoi a intrat în producție un PR pe care toți agenții îl trecuseră. Teste verzi, zero constatări de securitate, diff curat. Mai aplica și o regulă de discount pe segmentul greșit de clienți - o eroare de corectitudine de business, exact categoria pe care agenții de review n-o evaluează și exact categoria pe care pattern-ul ăsta o rezervă oamenilor. A rulat în producție săptămâni întregi până a scos-o la iveală un tichet de suport.

Post-mortem-ul a fost cinstit: toolkit-ul funcționase exact cum fusese proiectat. Eliminase constatările mecanice din review-ul uman, iar oamenii lăsaseră munca de judecată să se ducă odată cu munca mecanică. Capitolul 10 numește un arhetip - delegatorul necalibrat; aici, o echipă întreagă devenise unul, cu tooling bun pe post de alibi.

Soluția n-a fost scoaterea agenților de review. Soluția a fost un prag uman făcut explicit: un review minim pe corectitudinea de business și pe potrivirea arhitecturală pentru fiecare PR atins de agent, urmărit ca o cifră, lângă rata de defecte; ordinea de citire pentru diff-urile de agent din Capitolul 5 e pragul ăsta făcut concret. Agenții de review sunt un filtru pus în fața judecății umane. Din clipa în care devin un substitut pentru ea, pattern-ul ăsta îți face review-urile mai proaste exact în timp ce le face să arate mai bine.

Patru pattern-uri. Worktree-uri. Championi. Hook-uri. PR review toolkit. Niciunul nu cere să inventezi un proces nou. Toate se așază peste felul în care echipele de inginerie livrează deja cod, cu micile completări pe care lucrul cu agenți le cere.

Sidebar: guvernanța pentru companiile care vând AI clienților lor.

Ăsta nu e un pattern de operare brownfield - e un sfat pentru un anumit segment de public, ținut separat de pattern-urile numerotate tocmai din motivul ăsta. Dacă firma ta vinde capabilități AI propriilor clienți - nu doar consumă AI intern, ci revinde AI ca parte din produs - atunci pattern-ul de guvernanță e diferit față de cel al unui simplu consumator de AI. Demo-urile tale, call-urile de vânzări, proiectele cu clienții sunt toate situații în care disciplina echipei tale e la vedere. Clientul evaluează dacă știi să faci AI responsabil, nu doar dacă AI-ul funcționează.

Asta cere câteva pattern-uri suplimentare, peste cele generale.

Unu: demo-urile n-au voie să sară peste rigoare. Dacă îi arăți unui client cum folosești un agent ca să livrezi cod, îi arăți faza de Research, faza de Plan, faza de Review, faza de Verify. Nu-i arăți doar agentul generând cod și livrându-l, pentru că ăla e demo-ul care creează la client așteptări pe care nu le vei onora în producție.

Doi: AGENTS.md-ul tău e un instrument de vânzare. Clienții vor vrea să vadă ce a codificat echipa ta. Un AGENTS.md bine întreținut, de o sută de linii, cu un jurnal de greșeli care arată lecții reale, e mai credibil decât un AGENTS.md de o mie de linii care pare scris de un consultant. Arată disciplina, nu volumul.

Trei: framework-ul de kill signals e ceva ce îi înveți pe clienți. Grila valorează pentru client mai mult decât orice recomandare punctuală ai face tu, pentru că lentila asta îi permite clientului să-și evalueze singur codebase-urile, fără să depindă de tine. Când dai framework-ul mai departe, întărești relația de încredere. Echipele care țin framework-urile doar pentru ele pierd în fața echipelor care le împărtășesc.

Pattern-urile de mai sus se aplică oricărei echipe. Se aplică însă cu forță dublă echipelor ai căror clienți stau cu ochii pe ele - companiilor la care calitatea ingineriei e o suprafață vizibilă de produs, nu un centru intern de cost. Maturitatea guvernanței face parte din oferta acelor companii, iar disciplina descrisă în manualul ăsta e ceea ce face maturitatea apărabilă.

Încă patru pattern-uri. Trei sunt scurte, pentru că apar în echipele funcționale cu care am lucrat chiar dacă se vorbește mai rar despre ele. Al patrulea e materialul cel mai nou din capitolul ăsta și primește spațiul de care are nevoie.

Pattern-ul cinci: review-ul jurnalului de greșeli.

Jurnalul de greșeli din AGENTS.md e viu. Fiecare intrare e un eșec real prin care a trecut echipa. Dar jurnalul crește în timp, și nu orice intrare rămâne esențială la nesfârșit. Unele eșecuri se rezolvă structural - cauza de fond a fost eliminată printr-un refactoring, dependența a fost înlocuită, convenția a fost internalizată până în punctul în care nimeni n-ar mai face greșeala aia. Intrările astea pot fi retrase fără să pierzi nimic din siguranță, iar retragerea lor ține jurnalul suplu.

Championul rulează un review trimestrial al jurnalului. Pentru fiecare intrare, întrebarea e: a salvat regula asta pe cineva în ultimele trei luni? Dacă da, o păstrezi. Dacă nu, dar regula încă se aplică pe codebase, o păstrezi (regulile care previn eșecuri rare rămân valoroase chiar dacă eșecul nu s-a mai repetat recent). Dacă nu, și regula nu se mai aplică pentru că problema de fond a dispărut, o retragi, cu o notă în mesajul de commit care explică de ce.

Obiceiul ăsta împiedică jurnalul să devină un cimitir. Un cimitir de reguli e aproape la fel de inutil ca lipsa oricărei reguli, pentru că echipa nu mai are încredere în nicio regulă luată individual atunci când sunt prea multe, iar context window-ul agentului se aglomerează cu instrucțiuni perimate.

Pattern-ul șase: plasa de siguranță pentru demo (demo-day backstop).

Când echipa pregătește un demo de lucru cu agenți - pentru leadership, pentru clienți, pentru un showcase intern - apare tentația de a face demo-ul live, cu agentul lucrând pe bune în fața publicului. Uneori merge. Alteori agentul are o zi proastă, rețeaua sughite, modelul decide să fie neobișnuit de vorbăreț. Demo-urile live cu sisteme probabilistice vin cu un risc real de eșec.

Pattern-ul pe care îl recomand: pregătește o înregistrare de rezervă a aceluiași demo, făcută cu succes dinainte. Dacă demo-ul live intră în probleme, comuți pe înregistrare la secunda treizeci. Publicul nu trebuie să simtă diferența. Lecția ajunge la destinație oricum.

Plasa de siguranță nu e trișare. Plasa de siguranță e execuție profesionistă. Orice vorbitor cu experiență, din orice domeniu, are un plan de rezervă pentru momentul în care partea live cedează. Echivalentul în lumea agenților e o versiune înregistrată a aceleiași munci, ținută la îndemână.

Pattern-ul șapte: watchlist-ul de eșecuri.

După câteva luni de lucru cu agenți, începi să observi moduri de eșec care se repetă. Anumite tipuri de greșeli pe care agentul le face și pe care trebuie să le corectezi iar și iar. Anumite situații în care workflow-ul se împotmolește. Anumite comportamente ale utilizatorilor care duc la probleme previzibile.

Pattern-ul e să întreții un watchlist de eșecuri - un document care cataloghează aceste moduri de eșec recurente, condițiile în care apar și răspunsul standard al echipei când se întâmplă. Lista crește. Echipa o parcurge împreună cam o dată pe lună. Intrările noi se adaugă; intrările vechi, rezolvate structural, se retrag.

Watchlist-ul e pentru operațiuni ceea ce e jurnalul de greșeli pentru development. Jurnalul de greșeli previne greșelile de cod; watchlist-ul previne greșelile de proces. Amândouă sunt ținute în repository, versionate. Amândouă sunt revizuite regulat. Amândouă sunt felul în care experiența acumulată a echipei devine infrastructură.

Pattern-ul opt: bucla exterioară (outer loop).

Cele șapte pattern-uri de mai sus presupun un om în cameră. Al optulea e cel la care echipele ajung după câteva luni, când cineva pune întrebarea evidentă: dacă agentul poate rula o buclă disciplinată cât timp mă uit eu la el, de ce mă mai uit? Răspunsul industriei e bucla exterioară - reinvocarea automată a agentului, iterație după iterație, până când o condiție e îndeplinită. Bucla în șase faze din Capitolul 5 e bucla interioară (inner loop): o unitate de lucru, șase funcții, cu tine pe post de gate. Bucla exterioară o învelește. Când o iterație se termină, începe următoarea, și nimeni nu mai stă între ele.

Ideea are o preistorie, iar diferența dintre cele două epoci e toată lecția. În 2023, AutoGPT și BabyAGI învârteau un model în buclă pe baza propriei lui păreri despre progres. Nimic din exterior nu nota o iterație - modelul își corecta singur tema -, așa că fiecare tură amplifica deriva, iar abordarea s-a prăbușit în câteva luni ca mod de a livra software. Renașterea e structural diferită. La mijlocul lui 2025, Geoff Huntley a legat un coding agent într-un while-loop de bash - îi dai un singur fișier de prompt, îl lași să ruleze, repeți la nesfârșit - iar tehnica s-a răspândit sub numele Ralph Wiggum. Fiecare iterație pornește cu un context window proaspăt, face o unitate de lucru și se termină în fața unor evaluatori pe care modelul nu-i controlează: compilatorul, suita de teste, diff-ul. Starea trăiește în repository, nu în conversație. Tot ce face bucla să conveargă stă în afara modelului.

Între sfârșitul lui 2025 și primăvara lui 2026, pattern-ul a încetat să mai fie un truc de bash și a devenit o suprafață de produs. Copilot coding agent de la GitHub a devenit general disponibil în septembrie 2025: deleghi un task, un agent lucrează într-un mediu izolat, iar rezultatul se întoarce ca draft de pull request. Cursor a lansat Cloud Agents în octombrie 2025 - mulți agenți rulând detașat, cu laptopul tău închis. Jules de la Google a adăugat Scheduled Tasks în decembrie, pentru lucrările de mentenanță recurente. Un plugin ralph-wiggum aterizase deja în repository-ul oficial Claude Code în noiembrie, iar până în primăvara lui 2026 bucla ajunsese acolo funcționalitate de prim rang: /loop re-rulează un prompt la un interval dat sau își alege singur ritmul când nu specifici unul, Routines pornesc agenți cloud după un program sau după un eveniment GitHub, /goal ține agentul la lucru până când o condiție de finalizare e îndeplinită, /autofix-pr urmărește CI-ul și împinge fix-uri până când pull request-ul trece pe verde. O singură formă, multe grafii. După testul convergenței din Capitolul 1, capabilitatea a ajuns peste tot - deși ceea ce a ajuns la convergență e un workflow înfășurat în jurul componentelor principale, nu o componentă principală nouă.

Trendul e real, și tot aici disciplina e testată cel mai dur, pentru că bucla exterioară adaugă încercări, nu judecată. Multiplică orice îi permite bucla ta interioară. Dacă fiecare iterație se termină într-un gate strict, bucla acumulează progres: un queue de unități mici și verificate se scurtează peste noapte. Dacă gate-ul e slab, aceeași răbdare acumulează rebut. Numele dat de Huntley acestui mod de eșec e overbaking - ai lăsat-o prea mult „în cuptor”: lași bucla să ruleze după ce și-a terminat treaba și continuă să inventeze muncă pe care n-a cerut-o nimeni. Agentul nu obosește. Ăsta e avantajul - și, nesupravegheat, tot ăsta e pericolul.

Așa că pattern-ul nu e bucla; pattern-ul e contractul sub care o rulezi. Cinci linii, scrise înainte de prima iterație nesupravegheată. O condiție de oprire pe care o poate evalua o mașină - queue-ul e gol, suita e verde, bugetul s-a consumat. O buclă fără așa ceva nu e autonomie; e abandon. Un buget - tokeni, bani, iterații sau ore, oricare se atinge primul; o buclă nesupravegheată e clientul ideal al modelului de tarifare per token, iar calculele din Anexa A rulează și ele peste noapte. Un gate pe care agentul nu-l poate edita - testele, configurația de lint, workflow-ul de CI și regulile hookify stau în spatele unei reguli de deny (pattern-ul trei). Avertismentul din Capitolul 5 - o suită verde scrisă de agent e un indiciu, nu o dovadă - se aplică de două ori atunci când nimeni nu citește indiciile până dimineața. Cel mai ieftin mod în care o buclă ajunge pe verde e să negocieze cu propriul evaluator. Context proaspăt la fiecare iterație, stare durabilă în repository - un fișier de queue și un jurnal, ținute în repo prin commit-uri, astfel încât fiecare iterație pornește curată și citește istoria buclei din git, în loc să târască după ea un context care se degradează. Capitolul 5 numea contaminarea contextului drept cel mai mare motiv pentru care sesiunile lungi o iau razna; bucla exterioară făcută corect e un instrument de igienă a contextului - patruzeci de sesiuni scurte și curate în loc de una lungă, în degradare. Izolare dimensionată pentru absență - worktree-ul ei propriu (pattern-ul unu), sandbox-ul pornit, fără credențiale de producție, rețea constrânsă. O sesiune nesupravegheată e singurul loc în care prompt injection nu mai întâlnește niciun sceptic uman; straturile din Capitolul 3 nu sunt opționale aici - pe ele se sprijină toată greutatea. Anexa B.6 e contractul ăsta într-o singură pagină.

Ce pui în queue contează la fel de mult ca contractul. Munca eligibilă pentru buclă are multe unități similare, fiecare verificabilă de o mașină, fiecare reversibilă: migrări, curățenii de lint și de typing, dependency bump-uri, completarea testelor de caracterizare, refactorizări mecanice. Munca de design, cu un singur artefact, nu e eligibilă; mai multe încercări nu adaugă judecată, iar bucla îți va cheltui bugetul demonstrându-ți asta. Semaforul din Capitolul 8 se aplică aici cu forță dublă, pentru că bucla exterioară e munca autonomă a agentului în forma ei cea mai concentrată: doar codebase-uri pe VERDE. GALBEN înseamnă condus de om, iar bucla exterioară n-are, prin definiție, niciun om în ea.

Pragul uman nu dispare; se mută dimineața. Producția de peste noapte sosește sub formă de pull request-uri și primește review ca orice pull request - pragul explicit din pattern-ul patru, corectitudine de business și potrivire arhitecturală, nu o privire aruncată pe bife, pentru că tot ce produce o buclă sosește gata îmbrăcat în bife verzi. Iar bucla însăși primește kill signals, aceeași disciplină pe care Capitolul 8 o aplică pe codebase-uri. Patru sunt de ajuns: același diff aplicat și apoi revertat de la o iterație la alta; buget care arde în timp ce queue-ul nu scade; același eșec apărut a treia oară; orice iterație care a atins gate-ul. Oricare dintre ele înseamnă stop - citești jurnalul, repari cauza, abia apoi relansezi. O buclă repornită pe speranță e o buclă pe care ai încetat s-o mai controlezi.

Două extreme arată cât de departe duc echipele chestia asta. Huntley rulează bucla în forma ei brută și o tarifează ca pe un serviciu de utilități - în jur de 10 dolari pe oră. La capătul industrial, fabrica de software de la StrongDM rulează livrare complet non-interactivă, cu oameni care nici nu scriu, nici nu fac review la cod, și cu scenarii end-to-end ținute în afara codebase-ului, ca un holdout set pe care bucla nu-l poate slăbi - la un consum de tokeni pe care Simon Willison l-a estimat la aproape 20.000 de dolari pe lună per inginer. Pattern-ul ăsta stă deliberat între cele două extreme: contract, queue, gate-uri în afara razei de acțiune a agentului și un om care citește pull request-urile dimineața. Nimic din cele nouăzeci de zile ale Capitolului 10 nu cere bucla exterioară; ea e cum poate arăta luna a patra, dacă primele nouăzeci de zile au fost oneste. Supravegheat, plasa de siguranță ești tu. Nesupravegheat, plasa de siguranță e contractul - ceea ce face din bucla exterioară primul consumator al fiecărui control pe care îl instalează manualul ăsta, și testul cel mai curat dacă au fost vreodată instalate cu adevărat.

Opt pattern-uri în total. Nu se vor aplica toate fiecărei echipe. Primele patru - worktree-uri, championi, hook-uri, PR review toolkit - se aplică pe scară largă. Următoarele trei - review-ul jurnalului de greșeli, plasa de siguranță pentru demo, watchlist-ul de eșecuri - sunt pentru echipele care au trecut de primele luni. Ultimul - bucla exterioară - e pentru echipele care au trecut de celelalte șapte.

Capitolul următor: framework-ul de adopție - cum începe o echipă care a citit manualul ăsta. Trei roluri, nouăzeci de zile, angajamente concrete.