Lansarea catre publicul larg a aplicatiilor de tip LLM si ulterior adoptia agentilor de codare precum Claude Code pe parcursul ultimilor 3 ani au condus la o modificare treptata si a modului de lucru regulat din industria IT&C. Anumiti factori au fost imbunatatiti semnificativ (viteza), altii au devenit mai problematici (code review-ul, calitatea finala).
Discutia e una ce se poate intinde pe mai multe paliere si pe un timp indelungat, iar daca ne gandim si la partea de consecinte viitoare pentru industria software, atunci riscam sa nu ne mai oprim niciodata. Insa putem deschide macar discutia aici pe blog, si sa conturam o dezbatere. Asa ca in articolul de fata vom vorbi despre ce s-a schimbat sau este diferit acum in IT din perspectiva lucratului propriu-zis, fata de acum 3-4 ani.
Cuprins
Contextul actual. O tranzitie in desfasurare
Dezvoltarea si implementarea aplicatiilor LLM si a agentilor de codare AI reprezinta una dintre cele mai mari transformari din cadrul ultimelor decenii si in mod evident conduce daca nu la modificari revolutionare, macar la chestionarea anumitor practici curente din acest domeniu.
Daca inainte mentalitatea era una de a livra rapid, dar respectand totusi sablonul etapelor standardizate in procesul de Software Development Life Cycle, acum aceste etape par ca se eludeaza incet incet si creste dorinta (ca sa ma exprim eufemistic, in loc de presiune) de a livra cat mai rapid la clienti. Cum circula o gluma foarte cunoscuta, “trebuia implementat ieri”.
Cu siguranta anumite lucruri se experimenteaza la nivelul echipelor / companiilor. Daca acum e ceva la moda, toata lumea incepe sa faca asa, maine apare altceva si se da uitarii vechea moda. Pana la un punct e firesc, si asta intareste ideea ca IT-ul se afla intr-o tranzitie spre o noua etapa acuma, una mult mai “agile”, in care anumite cutume si practici probabil ca nu se vor mai regasi. Dupa cum cred ca anticipati modul meu de a gandi dupa atatia ani pe blog, acest lucru presupune si parti bune, si parti mai putin bune.
Iar anumite evenimente precum lansarea unor modele mult mai performante ca Fable 5 sau anumiti agenti dedicati pentru activitati specifice precum Claude Design vor aprofunda si mai mult aceasta tranzitie in urmatorii ani, cel putin pana la aparitia unui eveniment complet neasteptat, cum se zice popular pe la noi “o lebada neagra”.
Ce lucruri s-au schimbat in munca din IT sub factorul AI?
Vazand care este contextul de la care pornim, putem continua discutia prin a vedea mai multe exemple concrete de idei sau locuri unde IT-ul s-a transformat, mai mult sau mai putin, astfel incat sa conturam un tablou mai sistematic al tranzitiei de care vorbeam la punctul precedent, pentru a vedea mai spre final si care ar fi directia de viitor.
Ca un mic disclaimer, mentionez ca aceste idei si situatii au fost fie observate de mine in practica, fie le-am cules din surse publice online precum LinkedIn, Atlassian, forumuri (Reddit) sau stiri legate de IT. Nu inseamna ca aceste lucruri se intampla obligatoriu peste tot, sau ca reprezinta vreun nou standard in intreaga industrie. Sunt doar constatari punctuale, dar in mod cert interesante si de luat in discutie.
De la sprinturi planificate la fluidul Kanban
Un prim lucru ce pare ca treptat se schimba in cadrul industriei IT este tranzitia de la framework-ul de lucru Scrum, din cadrul metodologiei Agile, care presupunea ca munca sa fie desfasurata in unitati de timp standardizate de regula la 2 saptamani si cu anumite sedinte / ceremonii (daily, retro etc.) la un mod de lucru mai flexibil, si anume Kanban.
Kanban-ul este mult mai fluid din perspectiva metodologiei de lucru, exista un board general cu task-uri, dar nu se mai tine cont de deadline-ul standard, ca in ultima zi a sprintului lucrurile sa fie finalizate, si sa se respecte obligatoriu acele estimari in story points, ca nu cumva sa fie date peste cap calculele facute la planning.
Cum si viteza de lucru a crescut, Kanban-ul pare ca se potriveste mai bine si devine o optiune naturala pentru mai multe echipe. Si Scrum avea avantajele sale, fiind un mod de lucru foarte organizat, dar cred ca e un lucru pozitiv faptul ca IT-ul nu ramane ancorat doar in acesta.
Ritm de lucru accelerat (si fara frane)
Ca aminteam deja si in paragrafele anterioare, un factor care in mod cert s-a amplificat de cand cu utilizarea tot mai frecventa a AI-ului in dezvoltarea software este ritmul mult mai accelerat de a face lucrurile. Viteza devine tot mai mult o metrica extrem de importanta in livrarea noilor feature-uri catre clientii finali.
Desigur, nu e nimic gresit in a livra mai repede. Inainte clientii puteau sa astepte saptamani bune pana sa primeasca o versiune cu un fix la un bug suparator, acum se poate intampla in 3 zile. Insa riscul cel mai mai mare aici este sa ne axam doar pe viteza, sacrificand celelalte mecanisme de control si calitate a livrabilelor: verificarea codului, testarea lui temeinica, rularea unor teste de siguranta ca sa ne asiguram ca nu sunt impactate alte arii si asa mai departe.
E ok sa ai posibilitatea unor viteze de lucru mai mari, dar cu conditia obligatorie ca “franele” amintite anterior sa existe, sa fie de incredere si sa isi faca treaba, astfel incat rezultatul final sa fie cel putin la fel de valoros.
AI fara limita… sau nu?
Un alt fenomen ce a aparut in special la marile corporatii precum Amazon sau Meta (Facebook) a fost acela prin care au impus angajatilor sai din departamentele de Engineering sa foloseasca cat mai mult aplicatiile de AI, in special Claude Code de la Anthropic in munca lor de zi cu zi.
Acest lucru a condus la fenomenul (artificial) denumit “token maxxing“, prin care angajatii cautau diverse moduri de a folosi AI-ul, la sarcini care mai de care mai irelevante, doar pentru a-si maximiza consumul de tokens si a atinge sau chiar depasi pragurile impuse de conducerea companiilor respective.
Acest lucru a dus pentru companii precum Amazon sau Uber la depasirea in primele 4 luni din 2026 a intregului buget dedicat AI-ului pe acest an in curs. Concluzia preliminara e ca folosirea artificiala si obligata a unor tool-uri nu conduce neaparat si la rezultate (inclusiv financiare) mai bune, si e bine ca oamenii sa se obisnuiasca natural cu AI-ul.
Jack-of-all-trades, noul superstar in IT?
Mai demult am scris aici pe blog despre diferentele intre a fi generalist sau specialist in domeniul IT. In vremurile ante-AI, fiecare dintre cele 2 categorii prezenta avantajele sale strategice, poate cu un mic plus pentru latura specialistilor, in special a celor pe tehnologii rare sau extrem de nisate.
Astazi insa pare ca rolurile clasice precum programator, QA, SysAdmin ori DevOps incep sa fie din ce in ce mai amestecate, rezultand in mai multe situatii pozitii hibride care in mod cert combina activitati, responsabilitati si tehnologii din mai multe arii. Astazi un programator front-end poate deveni mult mai usor full-stack daca are cat de cat experienta pe proiectul respectiv. Un manual QA daca invata programare la nivel general poate tranzitiona spre automation testing cam cu orice limbaj / framework, poate chiar sa si aduca mici contributii la proiectul principal prin mici update-uri.
Pare deci ca generalistul, acel meserias descurcaret in mai multe arii sau “Jack-of-all-trades” in limbaj colocvial, devine un om tot mai cautat in industrie, mai mult decat un om care stie doar Java cu Springboot si atat. Nu e inca clar pana unde se vor forta aceste limite intre roluri, dar ideea pare simpla: continuati sa invatati orice, ca nu se stie niciodata cand anumite cunostinte tehnice pot fi de folos.
SaaS-urile platite, pe cale de disparitie?
Aplicatiile software terte ce erau platite in calitate de serviciu, celebrele Software-as-a-Services, sunt si ele puse acuma sunt semnul intrebarii odata cu adoptia tot mai mare a AI-ului in multe companii. Exista initiative ca unele firme care nu isi mai permit sa plateasca pentru anumite tool-uri sa isi construiasca propriul lor tool intern care sa le satisfaca nevoie.
Sa zicem ca firma X foloseste Jira de la Atlassian, dar constata ca licentele sunt prea scumpe, si atunci cu ajutorul lui Claude isi poate construi un project management tool intern, optimizat pentru proiectele sale si fara a mai plati licente. Suna absurd? Poate putin, nu toata lumea va face neaparat asta, dar cu siguranta multi se vor gandi si la aceasta optiune, in special la acele tool-uri ale caror licente costa foarte mult. Exista si reversul medaliei, ca odata ce construiesti un tool intern, trebuie sa ii asiguri mentenanta, sa ai oameni care sa se ocupe de el, deci rasar alte costuri.
Productivitate sporita si mai mult de munca
Daca inainte faceam 3 task-uri in 8 ore si acuma fac 9 task-uri tot in 8 ore, asta ar insemna ca suntem de 3 ori mai productivi, corect? Observatia aceasta, desi corecta strict in intelesul economic al termenului “productivitate”, are si o fata mai putin vazuta, anume a faptului ca numarul total de task-uri (Backlog-ul echipei) nu scade, ba dimpotriva, creste constant.
AI-ul ne ajuta in mod cert sa efectuam mai rapid anumite task-uri, insa asta nu inseamna ca muncim doar 6 ore pe zi si in rest suntem liberi. Pretentiile companiilor au crescut si ele, oamenii sunt incurajati sa aiba contributii cat mai diverse, la cat mai multe proiecte ce pot fi acum abordate mai usor cu un code agent la indemana. Astfel, si presiunea si stresul cresc pentru oameni, datoria tehnica (technical debt) se mentine in cele mai bune cazuri la acelasi nivel (ori creste), iar in final constatam un singur lucru: ca muncim mult mai mult.
Atentia noastra este distribuita pe mai multe fronturi intr-o zi, nu ne mai concentram doar la 1 task pana il terminam si gata. Daca nu gestionam corect aceste lucruri, se poate ajunge la lucruri mai grave precum burnout. Iar daca adaugam aici si cazurile in care echipele au fost reduse din punct de vedere numeric, atunci productivitatea mare mult clamata este doar un castig de fatada.
Senior Engineer, dar stii si AI?
Despre senioritati in IT s-au scris si discutat multe lucruri, inclusiv Radu a abordat subiectul pe canalul de YouTube VlogDeIT. Astazi AI-ul pune si el niste intrebari serioase, daca modelele consacrate de a considera oamenii seniori / mid / junior mai sunt relevante sau nu.
Daca de exemplu avem un programator cu 10 ani experienta care exceleaza la partea de Java dar nu stie sa foloseasca deloc aplicatiile AI mai poate fi considerat senior? Invers, daca avem un proaspat absolvent care nu are ani de experienta in spate dar este perfect acomodat cu lucrul folosind AI, mai poate fi privit doar ca entry-level?
Sunt intrebari legitime, si nu exista raspunsuri standardizate pentru acestea. Ramane de vazut industria cum se va reaseza pe baza acestor situatii, si cum vor fi priviti in viitor angajatii. E posibil ca stiinta folosirii AI-ului sa devina un criteriu important pentru a performa in acest domeniu.
Cum vor mai evolua lucrurile in viitor?
Tranzitia industriei IT prilejuita de ceea ce multi numesc deja “revolutia AI” reprezinta cu siguranta una din acele modificari profunde care nu apare oricand ci doar o data la cateva decenii. Din acest motiv, nimeni nu stie cum va arata industria dezvoltarii de software peste 5-10 ani, nici macar peste 1-2 ani.
In mod cert anumite tipare standard vor fi date deoparte, fiind considerate prea rigide si complet neadaptate noilor realitati. Privind dinspre noi ca oameni, cred ca e important sa ramanem deschisi in a invata, in a ne obisnui cu aceste noi tool-uri nu pentru a externaliza absolut totul (inclusiv gandirea critica) catre ele, ci pentru a invata cum putem fi mai eficienti in stilul nostru.
Programatorul nu mai face el munca direct, ci invata cum sa delege fiecare task catre un agent de codare. DevOps-ul nu mai analizeaza el direct logurile, ci primeste analiza facuta direct de AI pentru a vedea care e problema pe server. Mai concret, zona de IT nu mai este despre executia directa, mecanica a task-urilor, ci incepe sa devina tot mai multe despre orchestrarea agentilor care pun lucrurile in miscare pentru noi. Nu vom mai sta asa mult sa scriem de mana codul, dar cu siguranta vom petrece mai mult timp in a-i face review, a-l verifica si testa. Astfel, programatorul devine treptat un orchestrator, un dirijor pentru mai multe instante de agenti care lucreaza simultan.
Foarte probabil si echipele vor deveni mai mici din punct de vedere al efectivelor umane, si se vor diversifica afacerile din IT, oamenii disponibilizati de marile companii gasindu-si astfel un loc in companiile mai mici sau medii ce vor aparea. Loc de speculatii si interpretari este cat cuprinde, iar daca ai alte idei si opinii, te rog sa le lasi in comentarii.
Personal imi propun sa reiau aceasta discutie peste ceva timp deoarece acest subiect nu are cum sa fie epuizat, si sunt convins ca peste ani lucrurile vor fi si mai diferite decat sunt ele acuma, nu mai zic fata de cum erau ele acum 4 ani.
Concluzii
In incheiere, dam un prompt la Claude Code, acesta porneste 10 agenti de codare iar noi ne uitam la seriale. Sunt ironic desigur, si poate parea ca aceasta e noua marota a IT-ului, ca nu trebuie sa faci nimic ca le face AI-ul pe toate pentru tine. Suna la fel de idealist precum ideea aceea de a munci remote de pe plaja cu un cocktail in mana pe care o promovau anumite academii de IT cu multi ani in urma.
Dar pastrand si o nota de seriozitate, lumea se schimba sub ochii nostri, si pentru a nu ramane prea in urma, e important sa ii mentinem deschisi, abordand lucrurile critic astfel incat sa separam realitatea factuala de marketing si publicitate de fatada. Cred ca AI-ul este aici ca sa ramana, asa ca cel mai bun mod de a nu-l lasa sa faca prostii este sa stim sa il orchestram.
Leave a Reply