Adopția: 90 de zile, trei roluri

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

Închei manualul cu întrebarea practică: de unde începi?

Cele mai multe adopții reușite ale livrării cu agenți din 2025 și 2026 n-au început cu trei roluri. Au început cu un singur inginer care a refuzat să renunțe. Championul care și-a instalat agentul în propriile ore de lucru, care a scris primul AGENTS.md împotriva scepticismului tăcut al echipei, care a rulat primul architecture review pe un codebase despre care echipa susținuse că nu se pretează, și care s-a întors luna următoare cu un PR funcțional pe care nimeni altcineva nu reușise să-l scrie. Framework-ul cu trei roluri pe care îl descriu mai târziu în acest capitol e versiunea disponibilă atunci când echipa are buget, buy-in din partea managementului și bandwidth-ul să acopere Championul, Lead-ul și Managerul cu oameni diferiți. Majoritatea echipelor cu care am lucrat nu au luxul ăsta la început. Au un singur om, care joacă toate cele trei roluri pe rând, supraviețuind din inerție până când practica devine suficient de reală încât celelalte roluri să poată fi acoperite. Așa că de aici începe capitolul: cu inginerul singur. Versiunea cu trei roluri e cum arată binele după ce ai demonstrat că practica merită investiția.

Majoritatea adopțiilor încep aici: arcul grassroots

Prima dată când am predat grila celor trei roluri, un inginer din ultimul rând a ridicat mâna și a zis: „Compania mea nu arată așa. 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?”

Răspunsul cinstit e că arcul ideal cu trei roluri nu funcționează pentru el. Nu are toate cele trei roluri. Modelul s-ar împotmoli în luna a doua, când conversația de procurement n-ar avea cu cine să se întâmple.

Dar există un al doilea arc care funcționează pentru el - și pentru mulții ingineri ca el. L-am văzut reușind de două ori. Îl numesc arcul grassroots: adopția de jos în sus. Arcul grassroots e cum arată de fapt majoritatea adopțiilor în viața reală, nu predarea ordonată a ștafetei între trei oameni diferiți.

Arcul grassroots are altă formă. Championul e inginerul cu curiozitatea. Lead-ul și managerul sunt recrutați mai târziu, după ce championul a strâns dovezile cu care să-i recruteze. Un singur om joacă toate cele trei roluri pe rând - champion în luna unu, lead de facto în luna trei, când i se alătură un coleg, avocat de facto pe lângă management în luna șase, când conversația de procurement se leagă în sfârșit - în loc de trei oameni cu câte un rol fiecare.

Luna unu: championul folosește agentul pentru propria productivitate. Architecture review-uri pe codebase-urile pe care le deține. Schițe de AGENTS.md pentru proiectele unde e autorul principal. Bucla în șase faze pe propriile story-uri. Championul pornește în interiorul politicilor existente, pe muncă pe care o deține deja, pe cât posibil pe căi de cod nesensibile. Nu anunță nicio „transformare AI”. Strânge dovezi, în liniște.

Luna doi: championul pune rezultatele pe hârtie. Story-uri concrete livrate cu agentul. Timp concret economisit. Îmbunătățiri concrete de calitate (sau recunoașterea onestă a locurilor unde agentul n-a ajutat). Materialul e intern - un memo de o pagină sau o prezentare într-un meeting de echipă. Championul nu face pitch de adopție; povestește ce a făcut.

Luna trei: un coleg întreabă cum poate face la fel. Championul îl învață. Cei doi produc împreună un material mai consistent. Își invită tech lead-ul la un walkthrough. Lead-ul, care acum are dovezi și doi ingineri care cer același workflow, pledează mult mai ușor pentru angajamentele la nivel de echipă pe care le cere arcul ideal.

Lunile patru-șase: lead-ul recrutează managerul cu același tipar - dovezi plus cerere venită din echipă. Managerul, care vede acum doi ingineri livrând vizibil mai repede, poartă o conversație de procurement care nu mai presupune să vândă conceptul de la zero.

Până în luna șase, arcul grassroots arată cum arăta arcul ideal în luna trei. A durat de două ori mai mult pentru că championul a trebuit să construiască singur condițiile pentru rolurile de lead și de manager, în loc să le primească de-a gata din prima zi.

Arcul grassroots cere un champion dispus să facă munca lipsită de glorie a productivității personale timp de două luni fără să-l observe nimeni, și apoi munca mai grea de a converti cu răbdare colegi și manageri în următoarele patru. Nu e pentru oricine. Dar pentru inginerii din companiile care nu sunt încă pregătite pentru arcul ideal, arcul grassroots e calea care funcționează - și, din experiența mea, e calea pe care o iau mai multe echipe decât oricare alta.

Compromisul, numit onest

Arcul grassroots pornește mai repede și e fragil la plecarea championului. Dacă singurul inginer care duce practica în spate schimbă echipa sau face burnout înainte ca colegii și managementul să fi fost recrutați, practica moare odată cu el. Arcul ideal cu trei roluri pornește mai încet și rezistă mai bine la schimbările de rol. Dacă championul pleacă în luna a doua a arcului cu trei roluri, lead-ul și managerul continuă munca și recrutează un champion nou; practica supraviețuiește. Dacă championul pleacă în luna a doua a arcului grassroots, nu există nicio practică ce ar putea supraviețui.

Alege arcul care se potrivește situației tale. Dacă managerul tău a auzit de AI agentic, tech lead-ul tău e implicat și există buget pe masă, fă arcul cu trei roluri - plătești startul mai lent cu o practică mai durabilă. Dacă ești singur în povestea asta și singurele resurse pe care le ai sunt propriile ore de lucru și propria disponibilitate de a scrie un memo pe care nu ți l-a cerut nimeni, fă arcul grassroots. E ceea ce funcționează când n-ai ceea ce presupune versiunea ideală.

Versiunea ideală: trei roluri în paralel

Framework-ul pe care îl recomand atunci când echipa are buget și buy-in din partea managementului are trei roluri și un arc de nouăzeci de zile. Rolurile sunt champion, lead, manager. Fiecare vine cu angajamente concrete. Fiecare angajament e suficient de mic încât să încapă pe lângă munca normală; efectul cumulat e suficient cât să mute echipa într-un regim susținut de livrare cu agenți.

Arcul e asimetric, ceea ce surprinde lumea prima dată când îl descriu. Primele treizeci de zile nu produc aproape nicio productivitate măsurabilă. Championul învață, lead-ul clasifică, managerul ține la distanță întrebările premature despre metrici. Echipa investește. Metricile nu vor arăta încă beneficii, iar cei care așteaptă ROI imediat vor fi dezamăgiți.

Următoarele treizeci de zile produc productivitate vizibilă pe proiectul verde. Echipa începe să livreze așa cum am descris în Partea a II-a - Research, Plan, Execute, Review, Verify, Ship. Timpii de ciclu se îmbunătățesc. Calitatea se menține. Reviewerii încep să observe că PR-urile produse de agent sunt mai ușor de citit la review decât erau PR-urile dinainte de agent, pentru că descrierea e mai structurată.

Ultimele treizeci de zile produc efecte care se compun la nivelul întregii echipe. Alți ingineri intră în workflow. AGENTS.md crește. Jurnalul de greșeli acumulează intrări reale. Proiectele galbene încep să se miște spre verde pe măsură ce investițiile structurale dau roade. Conversația de la finalul trimestrului nu mai e „am economisit timp?”, ci „cum scalăm asta?”.

Forma curbei e aproximativ exponențială - mică la început, mai mare la mijloc, consistentă la final. Companiile care măsoară productivitatea la treizeci de zile vor fi dezamăgite. Companiile care măsoară la nouăzeci vor vedea tabloul întreg. Spune-le stakeholderilor despre asimetrie din capul locului; gestionează așteptările în consecință. Framework-ul funcționează; nu funcționează rapid în primele treizeci de zile, și asta prin design.

Cele trei roluri intră în joc la momente diferite, pentru că arcul asimetric o cere. Championul intră primul, pentru că investiția timpurie e tehnică. Lead-ul intră când munca devine vizibilă și are nevoie de decizii la nivel de portofoliu. Managerul închide bucla în luna a treia, când rezultatele trebuie traduse în termeni strategici. Angajamentele fiecărui rol, descrise mai jos, reflectă acest calendar. (În arcul grassroots de mai sus se aplică același arc, doar că un singur om joacă rolurile pe rând - citește angajamentele de mai jos ca munca ce trebuie făcută, nu ca munca pe care trebuie s-o facă trei oameni diferiți.)

Championul.

Championul e inginerul care învață primul workflow-ul cu agenți, în profunzime, și îl aduce înapoi în echipă. Championul e de obicei un senior sau staff engineer care are timpul și apetitul să învețe tooling nou cu atenție. Championul nu trebuie să fie cel mai senior om din echipă; trebuie să fie cel mai dispus să investească primele șaizeci de ore.

Angajamentele championului în primele nouăzeci de zile:

Săptămâna unu: instalează agentul. Treci prin workflow-ul de architecture review pe un codebase familiar. Citește ce produce agentul. Corectează ce e greșit. Dă commit artefactului. (Timp: vreo trei ore în total, pe parcursul săptămânii.)

Săptămâna doi: scrie primul AGENTS.md al echipei, în formă de schelet. Sub cincizeci de linii. Pattern-uri interzise, jurnal de greșeli (gol deocamdată), convenții, comenzi de build, unde-găsești-ce. Dă-i commit. Invită echipa să contribuie la el prin pull request-uri. (Timp: vreo cinci ore.)

Săptămânile trei și patru: rulează bucla în șase faze pe trei feature-uri mici. Story-uri care ar lua în mod normal o jumătate de zi. Folosește agentul pe toată bucla. Observă ce merge și ce nu. Documentează fricțiunile în jurnalul de greșeli pe măsură ce dai de ele. (Timp: cam cât ți-ar lua să faci feature-urile de mână; valoarea stă în experiență, nu în timpul economisit la început.)

Luna doi: rulează bucla în șase faze pe trei feature-uri medii. Story-uri care ar lua în mod normal o zi sau două. Continuă să documentezi fricțiunile. Trage și alți ingineri în workflow, pe faze individuale - lasă pe altcineva să facă review-ul planului, lasă pe altcineva verificarea conformității cu specificația. Distribuie experiența. (Timp: din nou, comparabil cu munca manuală, dar echipa construiește cunoaștere comună.)

Luna trei: predă rolul de champion. La finalul celor nouăzeci de zile, cel puțin încă un inginer din echipă ar trebui să poată rula workflow-ul la același nivel de fluență. Championul se rotește; workflow-ul nu mai depinde de championul inițial.

Valoarea championului pentru companie în nouăzeci de zile: echipa are un workflow funcțional de livrare cu agenți, un AGENTS.md întreținut, trei-patru feature-uri livrate care validează abordarea și un succesor desemnat. E un rezultat consistent. Costul: atenția parțială a unui singur inginer, timp de un trimestru.

Lead-ul.

Lead-ul e tech lead-ul, staff engineer-ul sau engineering managerul care decide ce proiecte primesc agentul și în ce ordine. Lead-ul e paznicul semaforului. Lead-ul e omul care îi spune echipei „proiectul ăsta e verde, trimite agentul; proiectul ăsta e galben, lucrează în pereche cu agentul; proiectul ăsta e roșu, nu-l atinge”.

Angajamentele lead-ului în primele nouăzeci de zile:

Săptămâna unu: clasifică primele cinci proiecte active ale echipei după cele opt kill signals. Dă fiecăruia o culoare. Pune clasificarea pe hârtie. Împărtășește-o echipei. (Timp: vreo două ore.)

Săptămânile doi-patru: pentru câte un proiect de fiecare culoare, documentează ce ar trebui să se schimbe ca să treacă la culoarea următoare. Pentru proiectul verde, documentează de ce rămâne verde (ca echipa să protejeze condițiile). Pentru proiectul galben, documentează cele două-trei reparații structurale care l-ar duce la verde într-un trimestru. Pentru proiectul roșu, documentează dacă răspunsul corect e investiție, înlocuire sau scoatere din uz. (Timp: vreo cinci ore în total.)

Luna doi: urmărește metricile. Cycle time-ul pe munca făcută cu agentul pe proiectul verde. Rata de defecte. Timpul reviewerilor. Orice măsoară deja echipa, plus întrebarea dacă workflow-ul cu agenți mișcă cifrele în direcția așteptată. Cifrele vor fi zgomotoase la început; obiceiul e să măsori oricum, ca să poți avea o discuție reală despre rezultate în luna trei. (Timp: vreo trei ore.)

Luna trei: prezintă rezultatele. Echipei, propriului management, oricui altcuiva trebuie să știe. Rezultate oneste. Dacă agentul livrează conform așteptărilor, spune-o cu date. Dacă nu, spune-o tot cu date și propune ajustări. (Timp: vreo cinci ore, cu tot cu pregătire.)

Valoarea lead-ului pentru companie în nouăzeci de zile: un portofoliu de proiecte clasificat onest, un roadmap pentru mutarea proiectelor galbene spre verde, o grilă de măsurare care desparte hype-ul de realitate și un raport onest despre rezultate, pe baza căruia restul organizației de inginerie poate acționa.

Managerul.

Managerul e engineering managerul, directorul sau liderul senior care deține bugetul, angajările și procurement-ul. Managerul e rolul pe care cei mai mulți îl uită când planifică adopția de AI agentic. Managerul e omul care decide dacă echipa poate angaja criptograful potrivit pentru problema de la kill signal-ul șase, dacă echipa poate investi un trimestru în mutarea unui proiect galben la verde, dacă echipa poate cheltui pe tooling sau servicii suplimentare.

Faza managerului acoperă zilele șaizeci și unu - nouăzeci, după ce Championul a pus practica pe picioare și Lead-ul a consolidat-o. Munca are trei centre de greutate: procurement (închide decizia de licențiere, ca echipa să nu rămână pe veci pe seat-uri individuale), guvernanță (semnează postura de securitate pe care o redactează Championul) și raportare (traduce rezultatele operaționale în termeni pe care leadership-ul îi va finanța). Niciuna dintre ele nu cere ca managerul să scrie cod sau să ruleze agenți. Toate cer ca managerul să apere granițe: între datele operaționale și promisiunile de ROI, între potrivirea tooling-ului cu utilizarea reală și uniformitatea impusă, între protejarea echipei de metrici premature și pretenția legitimă de dovezi că munca dă roade.

Ce NU face managerul e cel puțin la fel de important. Managerul nu vânează metrici de productivitate per inginer în luna a doua. Managerul nu se angajează la calcule de ROI pe trei ani înainte ca dashboard-ul să aibă măcar un trimestru de date. Managerul nu autorizează benchmark-uri comparative cu alți vendori înainte ca echipa să fi livrat suficient cât să definească ce anume compară. Astea sunt întrebările care omoară adopția când primesc răspuns prea devreme. Treaba managerului e să protejeze echipa de ele în lunile unu-trei, să apere cifra operațională când e solidă și să lase argumentul de venituri în seama celui care deține veniturile.

Până în ziua nouăzeci, rolul managerului s-a mutat de la „pune practica pe picioare” la „urmărește metricile în cadență trimestrială”. Dashboard-ul rămâne. Championul și Lead-ul rămân în rolurile lor. Managerul are capacitate pentru munca trimestrului următor, iar leadership-ul are un plan credibil, ancorat în date operaționale reale din primele nouăzeci de zile, nu în ROI promis pentru următoarele patru trimestre.

Sidebar: un proiect cu 20 de ingineri în servicii financiare, săptămână cu săptămână.

Un caz concret, ca faza managerului să devină palpabilă. Douăzeci de ingineri software într-o firmă reglementată de servicii financiare. Managerul conduce funcția de inginerie și raportează unui CTO care susține inițiativa, dar e atent la costuri. Board-ul a cerut un update de o pagină, la finalul trimestrului trei, despre investiția echipei în AI. Championul a dus primele treizeci de zile; Lead-ul a consolidat practica în zilele treizeci și unu - șaizeci. Managerul preia sarcina în zilele șaizeci și unu - nouăzeci.

Săptămâna unu a fazei managerului, zilele șaizeci și unu - șaizeci și șapte. Championul și Lead-ul predau un dashboard cu trei metrici: procentul de PR-uri merged care au atins cod generat de agent, cycle time-ul pe acel set de PR-uri față de trimestrul anterior și rata de defecte pe același set față de trimestrul anterior. Cifrele din acest proiect: 41% dintre PR-uri erau atinse de agent în luna a doua. Cycle time-ul pe acele PR-uri a fost cu 28% mai mic decât baseline-ul echipei dinainte de agent; rata de defecte a rămas în marja de zgomot a baseline-ului. Treaba managerului în săptămâna unu e să verifice că metricile sunt reale, nu să le crească.

Săptămâna doi, zilele șaizeci și opt - șaptezeci și patru. Procurement-ul ridică întrebarea seat-uri individuale versus contract enterprise. Echipa e momentan pe seat-uri Pro individuale; managerul trebuie să decidă dacă le consolidează într-un contract Team sau Enterprise înainte de finalul trimestrului. Matematica seat versus enterprise e în Anexa A. Decizia în acest caz a fost nivelul Team pentru 13 din cei 20 de ingineri și seat-uri Pro pentru cei 7 care folosesc agentul rar. Managerul apără împărțirea asta în fața procurement-ului cu argumentul că uniformitatea tooling-ului nu e scopul; scopul e o cheltuială ținută în frâu, potrivită cu utilizarea reală.

Săptămâna trei, zilele șaptezeci și cinci - optzeci și unu. Apare comitetul de securitate. Comitetul a citit despre clasa de injecție prin fișiere de configurare din Claude Code, dezvăluită de Check Point Research la începutul lui 2026 (citarea e în Anexa C), și vrea o postură de guvernanță scrisă. Managerul produce un document de o pagină care numește cele patru puncte de control: hooks, sandbox, vault de secrete, telemetrie. Managerul nu scrie documentul; îl scrie Championul. Managerul îl editează și îl semnează.

Săptămâna patru, zilele optzeci și doi - optzeci și opt. Sosește cererea board-ului. Update-ul managerului are două fraze și un singur număr. „Avem douăzeci de ingineri pe livrare asistată de agenți. Cycle time-ul pe PR-urile atinse de agent e cu 28% sub baseline, fără nicio schimbare măsurabilă în rata de defecte. Continuăm să evaluăm extinderea pe parcursul trimestrului următor.” Managerul nu promite o cifră de venituri; managerul apără cifra operațională și lasă argumentul de venituri în seama CTO-ului.

Ziua nouăzeci. Predarea înapoi către operațiunile curente. Dashboard-ul rămâne. Championul și Lead-ul rămân în rolurile lor.

Două arhetipuri de ingineri care omoară rollout-urile dacă nu le numești

Cele trei roluri descriu ce se întâmplă când arcul funcționează. Există însă două arhetipuri de ingineri pe care le vei vedea în orice echipă în timpul adopției și care vor omorî rollout-ul pe tăcute dacă nu le numești cu voce tare.

Arhetipul unu: scepticul de principiu. Seniorul care a mai văzut cicluri de hype AI și nu e convins că ăsta e diferit. Nu va folosi agentul. Nu va scrie AGENTS.md pentru modulele pe care le deține. Va face review la PR-urile conduse de agent cu o ostilitate în plus, căutând dovezi că abordarea e greșită. Două feluri în care iese prost. Echipa începe să lucreze pe lângă el - review-urile lui întârzie PR-urile, modulele lui devin o insulă pe care agentul n-o atinge, codebase-ul se bifurcă în teritorii prietenoase cu agentul și teritorii ostile. Sau scepticul de principiu câștigă disputa politică din interiorul echipei și rollout-ul se blochează. Soluția nu e să-l convertești pe scepticul de principiu. Inginerii seniori și-au câștigat dreptul de a nu fi de acord. Soluția e să-i dai o graniță clară: „modulele tale, regulile tale, agentul nu se atinge de ele; peste tot în rest se aplică standardul echipei”. Și ai grijă ca sarcina lui de review să nu devină bottleneck-ul velocity-ului echipei - dacă fiecare PR condus de agent stă în queue-ul lui, echipa i-a dat scepticului de principiu un drept de veto pe care nu intenționa să i-l acorde.

Arhetipul doi: delegatorul necalibrat. Inginerul (deseori mai junior, alteori mai senior decât te-ai aștepta) care sare peste citirea atentă a output-ului agentului pentru că „agentul o nimerește mereu”. Problema nu e delegarea în sine; problema e calibrarea proastă a momentelor în care să ai încredere și a celor în care să inspectezi. Livrează PR-uri conduse de agent fără să le parcurgă. Defectele se adună, pentru că agentul face greșeli pe care omul le-ar fi prins dacă omul ar fi fost atent. Două feluri în care iese prost. Rata de defecte urcă încet, iar echipa dă vina pe agent, nu pe pasul de review care lipsește. Sau cunoștințele de domeniu ale delegatorului necalibrat se atrofiază, și după șase luni nu mai poate depana sistemul pe care agentul l-a ajutat să-l construiască. Soluția e disciplina de review deja numită: fiecare PR condus de agent primește același review uman ca fiecare PR condus de om, fără excepții. În prima lună, pune-l pe delegatorul necalibrat în pereche cu un reviewer senior care citește output-ul agentului linie cu linie. Calibrează.

Ambele arhetipuri sunt previzibile. Numește-le cu voce tare în rollout. Tratează-le pe fiecare ca pe o problemă structurală cu o soluție structurală, nu ca pe un defect de caracter. Echipele care fac asta țin ambele arhetipuri în joc, productive. Echipele care n-o fac îl pierd pe scepticul de principiu într-o rebeliune tăcută și pe delegatorul necalibrat într-o erodare lentă a judecății.

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

O realitate operațională pentru care rollout-ul trebuie să aibă un plan: agentul nu va fi mereu disponibil. Căderile la vendor se întâmplă. Limitările de capacitate se întâmplă. Modelul pe care îl folosești azi e scos din uz, iar înlocuitorul nu e încă stabil. 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 timpul unui incident regional de capacitate, și nu se gândiseră deloc ce fac atunci când bottleneck-ul e chiar agentul.

Ce pui la punct. Un fallback non-agentic pentru munca cea mai sensibilă la timp. Seniorul care încă poate livra un hotfix la trei dimineața, când modelul e rate-limited. Runbook-ul pentru „ce facem când Claude Code e throttled și clientul așteaptă”. Acceptarea faptului că în unele săptămâni velocity-ul echipei scade pentru că vendorul a avut un incident, la fel cum în unele săptămâni scade pentru că o bază de date a avut un incident.

Nu construi o echipă care nu poate funcționa fără agent. Construiește o echipă al cărei velocity în regim normal presupune agentul și al cărei velocity în regim de fallback presupune că o săptămână doar-cu-oameni e de supraviețuit. Agentul e infrastructură. Ca orice infrastructură, are uptime, iar planul de continuitate al echipei trebuie să țină cont de downtime.

Trei roluri. Champion. Lead. Manager. Fiecare cu angajamente concrete. Niciunul full-time. Toate indispensabile. Niciunul complet fără celelalte.

Cel mai frecvent eșec de adopție pe care îl văd e echipa care are champion, dar n-are lead. Championul învață workflow-ul, îl rulează pe câteva proiecte, dar nu poate convinge echipa să-l aplice consecvent, pentru că nimeni nu ia deciziile la nivel de proiect despre unde merge agentul. Championul ajunge să facă singur toată munca cu agentul, ceea ce nu scalează, iar agentul rămâne catalogat drept „interesant, dar limitat”.

Al doilea cel mai frecvent eșec e echipa care are champion și lead, dar fără implicarea managerului. Munca tehnică merge bine. Procurement-ul stă blocat două luni așteptând avizul de la legal. Bugetul pentru inițiativa de documentare nu se alocă. Proiectele galbene rămân galbene pentru că nu există investiție. Clasificarea făcută de lead era corectă; n-a avut cumpărător.

Al treilea eșec, mai rar dar real, e echipa care are lead și manager, dar n-are champion. Lead-ul înțelege modelul. Managerul a alocat buget. Nimeni de pe partea de inginerie n-are experiența hands-on ca să ruleze workflow-ul. Echipa e angajată teoretic în livrarea cu agenți și blocată practic.

Toate cele trei roluri. Toate cele trei seturi de angajamente. Nouăzeci de zile. Arcul e real, munca e delimitată, rezultatele sunt măsurabile.

Aplică framework-ul ăsta. Pornește cronometrul. Întoarce-te peste nouăzeci de zile și spune-mi cum a mers.

Echipele care urmează arcul ăsta vor fi, peste doi ani, echipele al căror avans s-a compus timp de doi ani. Echipele care au ales un tool, l-au integrat neglijent și au așteptat să apară productivitatea vor fi echipele care spun „am încercat AI și n-a mers”.

Tu alegi în ce fel de echipă ești.