Orice inginer cunoaște senzația, chiar dacă nu îi dăm întotdeauna acesteia un nume: problema din fața ta este suficient de grea cât să fie interesantă, dar nu atât de grea încât să te blocheze. Distragerile dispar, timpul se comprimă și, două ore mai târziu, îți îndrepți privirea înspre ceva de care ești cu adevărat mândru.
Zilele pe care ni le amintim ca fiind cele mai bune zile de inginerie nu sunt, de obicei, cele în care am închis cele mai multe tichete. Sunt cele în care ne-am putut gândi limpede la un singur lucru dificil și pe care l-am dus până la capăt.
Problema este că starea de flow a devenit tot mai rară pentru că ne-am umplut treptat zilele cu exact lucrurile care fac concentrarea din ce în ce mai dificilă: schimbări de context, notificări, coordonare, statusuri, handoffuri, așteptarea unui code review și zeci de fragmente de informație pe care trebuie să le ținem simultan în minte.
O lentilă utilă prin care putem privi problema este cea a încărcării cognitive.
Flow-ul ține, în esență, de atenție, iar atenția este guvernată de încărcarea cognitivă. Un model util al încărcării cognitive distinge între trei tipuri, iar distincția contează enorm pentru felul în care proiectăm munca de inginerie.
Încărcarea intrinsecă vine din complexitatea problemei în sine: numărul de concepte și relații pe care trebuie să le înțelegi simultan pentru a rezolva ceva. Un algoritm distribuit sau o migrare complexă de date rămân dificile indiferent cât de bine îți organizezi calendarul.
Încărcarea extrinsecă este efortul mental care nu contribuie direct la rezolvarea problemei: schimbări de context, ownership neclar, căutarea informației, handoffuri, așteptarea după alte echipe, întâlniri inutile sau reconstruirea contextului unui pull request la două zile după ce a fost scris.
Mai există și conceptul de încărcare germinativă, efortul prin care construim modele mentale mai bune, învățăm și transformăm experiența în expertiză. Vrem să păstrăm spațiu mental pentru înțelegere, nu doar pentru execuție.
Asta ne oferă un principiu simplu: complexitatea reală a problemelor nu poate fi eliminată. Flow-ul apare mai ușor atunci când atenția noastră rămâne concentrată pe problemă și pe înțelegerea ei, nu pe mecanismele construite în jurul muncii.
Ceea ce știm despre dezvoltarea asistată de IA este simplu: producem mai mult cod. Mult mai mult cod.
Un inginer poate explora mai multe variante, genera boilerplate, scrie teste, modifica mai multe fișiere simultan și delega unui agent sarcini care înainte necesitau zeci de minute sau ore.
Dar generarea codului nu este întregul sistem de livrare software.
Mai mult cod înseamnă mai multe schimbări de înțeles, mai multe pull requesturi, mai multe review-uri, mai multe teste, și, inevitabil, mai multe lucruri de observat și operat în producție
Aici este paradoxul. IA-ul reduce costul producerii unei schimbări, dar poate crește costul sistemic al înțelegerii tuturor schimbărilor produse. Am făcut codul mai rapid, dar nu am îmbunătățit atenția. Iar atenția umană devine noul bottleneck.
O echipă este un grup de oameni care lucrează împreună către același obiectiv. Pare banal, dar definiția are o consecință importantă.
IA-ul ne-a accelerat capacitatea de execuție, iar răspunsul natural al multor organizații a fost să ofere echipelor existente un scop mai mare. Dacă putem produce de două ori mai mult, de ce să nu avem grijă de două ori mai multe lucruri?
Asta încalcă discret definiția și trage grupul în mai multe direcții, slăbind alinierea. Lucrează la mai multe obiective care împart aceiași oameni, iar costul ascuns este acela al periclitării coordonării.
Mișcarea contraintuitivă este să reducem dimensiunea echipelor.
Aceste echipe mici, denumite și poduri (capsulă sau modul), devin unitatea de bază pe care se construiește restul organizației. Într-o echipă mică pot înțelege ce fac colegii mei fără să întrețin permanent un model mental al muncii altor șapte sau zece oameni doar pentru a ști unde mă încadrez. Comunicarea devine mai directă, ownershipul mai clar, iar costul alinierii scade.
Dar mai mic nu înseamnă izolat.
Coordonarea excesivă este costisitoare, însă absența totală a coordonării este la fel de periculoasă. Fără mecanisme prin care informația importantă circulă între poduri, apar alte probleme: echipele reinventează aceleași soluții, standardele diverg, iar două grupuri pot modifica aceeași zonă a sistemului fără să știe unul de celălalt.
Potrivit unei investigații Reuters, Meta s-a lovit chiar de aceste provocări. Sub programul intern Proiectul Transformarea Organizației, compania a reorganizat echipe de 10-20 de oameni în poduri de trei-cinci persoane susținute de IA. Fragmentarea în sine nu a fost vinovatul, ci mecanismele de coordonare și partajare a cunoștințelor care nu au ținut pasul cu schimbarea.
Volumul de cod a crescut cu 220% de la an la an. În paralel, incidentele tehnice și de securitate majore au crescut cu aproximativ 40%, iar timpul petrecut de echipe pentru a le gestiona a crescut cu 70%, ceea ce a dus la punerea pe pauză a proiectului.
Fragmentarea fără mecanisme suficient de bune de coordonare și partajare a cunoștințelor nu elimină încărcarea organizațională, ci doar o mută. Uneori direct în producție.
Rezultatul arată exact acest cost mutat, nu eliminat: uneori direct în producție. Este motivul pentru care structurile transversale precum chapters, guilds sau comunități de practică nu sunt un lux birocratic, ci mecanismul care trebuie întărit.
Modelul de sprint cu backlog fix, estimare și angajament pe două săptămâni devine greu de susținut cu ritmul schimbării pe care IA-ul îl impune. Așa că ne întoarcem la a itera imediat: un flux mai suplu, de tip Kanban, în locul angajamentelor în loturi. Iei următorul lucru cel mai valoros, îl livrezi, iei următorul.
Dacă IA-ul reduce timpul necesar producerii codului, avantajul competitiv se mută către viteza feedbackului. Din perspectiva asta, o serie de practici vechi de peste două decenii devin surprinzător de moderne.
Pair programming. Nu vreau să aflu ce ai construit două zile mai târziu, încercând să reconstruiesc intenția dintr-un pull request de 800 de linii. Prefer să construim înțelegerea împreună, cu un agent care produce rapid variante, teste sau implementări, în timp ce noi păstrăm controlul asupra intenției și designului.
Continuous delivery și continuous deployment. Vreau codul meu în producție cât mai repede posibil. Cod scris dar netestat, nevalidat, neobservat în producție este pură încărcare extrinsecă ce acumulează risc. Cu cât este mai mic intervalul dintre a scrie și a vedea rulând, cu atât mai puțin din acea greutate trebuie dusă de cineva.
Test-driven development. Dacă IA-ul produce cod mai repede decât putem face review linie cu linie, barierele de siguranță trebuie construite continuu, nu după. TDD scrie safeguardurile în paralel cu codul. Modelele IA sunt predictive, nu deterministe, iar predicția e failibilă; nu ne putem sprijini pe ele ca sursă a corectitudinii, ci trebuie să-l înconjurăm cu teste care ne oferă feedback rapid și reduc riscul erorilor.
Release-uri mici. Cele mari sunt scumpe cognitiv. Implică mai multe schimbări, mai multe dependențe, mai mulți oameni și o suprafață mai mare în care ceva poate merge prost. De aceea ajung să necesite ceremonii, checklisturi, coordonare și, uneori, echipe întregi dedicate livrării. Un release mic este mai ușor de înțeles, și mai ușor de observat.
Refactorizare fără frică. Refactorizarea nu ar trebui să fie proiectul anual în care oprim produsul ca să schimbăm frameworkul, să rescriem jumătate din sistem și să sperăm că totul funcționează după trei luni. Când testele oferă feedback rapid, schimbările sunt mici, integrarea este frecventă și sistemul este observabil, designul poate fi îmbunătățit pe măsură ce învățăm.
Pentru liderii unei organizații, trecerea de la cinci echipe la cincisprezece nu înseamnă pur și simplu de trei ori mai multă muncă. Primul lucru care se rupe este iluzia că poți continua să urmărești în detaliu backlogul fiecărei echipe. Cu cinci echipe poate funcționa, dar cu cincisprezece, leadershipul însuși devine bottleneckul.
Sunt trei schimbări importante:
Direcție prin obiective, nu prin backloguri. Nu trebuie să spun fiecărui pod ce să construiască. Echipa primește o problemă, o metrică sau un outcome clar și autonomia de a descoperi cea mai bună cale către el. Leadershipul păstrează direcția, iar echipa păstrează decizia locală.
Semnale în loc de status. La scară, sănătatea organizației trebuie să devină vizibilă prin semnale, nu prin rapoarte manuale: lead time, deployment frequency, change failure rate, incidente. Completate de predictibilitatea livrării, satisfacția utilizatorilor și metrici specifice produsului, acestea înlocuiesc nevoia de status. Scopul nu este să transformăm oamenii într-un dashboard, ci exact invers: să nu îi obligăm să producă manual status doar pentru ca managementul să se simtă informat.
Safeguarduri. Autonomia nu înseamnă absența constrângerilor. Înseamnă că aceste constrângeri sunt suficient de clare încât echipa să poată decide singură în interiorul lor. SLO-uri, politici de securitate, standarde de observability, praguri de testare, reguli pentru rollout și timp de răspuns la incidente conturează limitele în care o echipă poate acționa liber. Adăugate la principii arhitecturale explicite, aceste constrângeri permit auto-guvernare fără aprobare la fiecare pas.
La cincisprezece echipe, rolul liderului se schimbă: de la urmărirea muncii la definirea rezultatelor, proiectarea sistemului organizațional, observarea semnalelor și codificarea constrângerilor.
Scopul nu a fost niciodată mai mult cod, ci ingineri în stare de flow care își consumă atenția pe probleme grele și pline de sens, nu pe mecanismele din jurul lor. IA-ul elimină fricțiune locală și poate crea fricțiune sistemică.
Trei idei duc greutatea acestui articol: flow-ul individual depinde de cât de bine protejăm încărcarea intrinsecă și germinativă de zgomotul extrinsec; echipele mici funcționează doar când coordonarea între ele este proiectată și nu lăsată la voia întâmplării; iar la scară mai mare, rolul liderului se mută de la urmărirea muncii la proiectarea semnalelor și a constrângerilor care permit autonomie reală.
În era IA, organizațiile care vor câștiga nu vor fi cele care produc cel mai mult cod, ci acelea care știu cel mai bine unde merită consumată atenția umană.
Surse: DORA, State of AI-assisted Software Development 2025; Faros AI, AI Productivity Paradox 2025 și AI Engineering Report 2026 - The Acceleration Whiplash.
Human-in-the-loop: Keeping people at the center of AI
Miercuri, 23 septembrie, ora 18:00
Betfair Romania Development
Facebook Meetup StreamEvent YouTubede Ovidiu Mățan
de Ovidiu Mățan
de Tibor Boné
