Trebuie să vă mărturisesc ceva: sunt parte a problemei. Am scris articole despre cum să construim skilluri IA, am ținut prezentări despre diferența dintre agenți și skilluri, despre MCP, despre pluginuri. Internetul este plin de astfel de conținut, iar o parte din acesta este al meu. Am devenit foarte buni în a răspunde la întrebarea „Cum să construiesc un tool IA customizat?" Dar nu am răspuns la întrebarea care contează cu adevărat: „Ar trebui să fac lucrul acesta?”

Agile a schimbat fundamental modul în care industria software gândește livrarea. Stand-upul zilnic, sprintul de două săptămâni, retrospectiva, fiecare practică a apărut dintr-o nevoie reală: cum menții coerența unei echipe, cum absorbi schimbarea fără să pierzi ritmul, cum creezi spațiu pentru îmbunătățire continuă. Timp de două decenii, modelul a funcționat remarcabil de bine. Contextul în care a fost creat, însă, se schimbă structural: IA-ul agentic și munca asincronă nu sunt doar unelte noi în același cadru, ci forțe care redefinesc premisele pe care Agile le-a luat ca date.

Documentație portabilă, iterație controlată și dezvoltare software asistată de IA. Când vorbim despre IA în programare, discuția ajunge foarte repede la cod. Cât cod poate genera? Cât de repede poate implementa un feature? Cât de mult ne poate crește productivitatea?

Inteligența artificială schimbă fundamental modul în care evaluăm candidații tehnici. Interviurile nu mai pot evalua memorarea sau viteza de implementare. Accentul se mută de la „cine poate scrie cod” la „cine poate înțelege, valida și lua decizii corecte”. Problema nu mai este dacă un candidat folosește IA, ci cum o folosește.

La 5 luni după ce am început primul meu joc, mi-am dat seama că va trebui să refac jumătate din el. Am învățat mai multe despre arhitectura software în acea perioadă decât în toți anii mei anteriori de facultate.

Ai primit vreodată un User Story de migrare Java estimat la 13 puncte Fibonacci — pentru 20–30 de servicii? Știm cu toții cum se termină: zile de erori de compilare, forumuri din anii '90 și promisiunea că „celelalte vor fi copy-paste”. În 2026, avem o veste bună: acele 13 puncte pot deveni 3, iar tu poți urmări totul servind o cafea gustoasă.

Infrastructure as Code (IaC) a devenit o parte importantă a proceselor noastre de CI/CD. Vorbim despre cod care definește și creează infrastructură, scris de persoane (și mai nou, de IA) care sunt, de multe ori, mult mai aproape de zona de infrastructură decât de cea de dezvoltare software propriu-zisă.

Coridorul. Este târziu. Închizi laptopul peste un fișier pe care, tehnic vorbind, nu l-ai făcut tu. Un stakeholder îl va deschide mâine și va spune: Exact așa voiam! Și va spune adevărul. Totuși, tu te vei simți ca și cum o fantomă ți-ar fi umblat prin buzunare.

În ultimii ani, tot mai mulți profesioniști din Generația Z au intrat în echipele de dezvoltare software, aducând cu ei perspective, așteptări și moduri de lucru diferite de cele cu care mulți dintre noi ne-am obișnuit. Pentru manageri, această schimbare poate reprezenta atât o provocare, cât și o oportunitate. Colaborarea cu dezvoltatori din Generația Z este una dintre cele mai valoroase experiențe de învățare profesională și personală, deoarece ne obligă să ne adaptăm, să ne actualizăm perspectivele și să construim relații de lucru mai autentice.

Voi fi sinceră cu voi: folosesc IA zilnic. Scriu prompturi, mă cert cu el, îi critic judecata mai mult decât pe a mea și îl văd cum poate produce în doar 10 secunde ceva ce mie mi-ar fi luat o după-masă. Chiar și așa, nu m-am simțit mai relevantă ca designer.