Plan de 30 de zile: competențe AI pentru developerul angajat

Raportul DORA din 2025, realizat de Google Cloud pe aproape cinci mii de profesioniști din industrie, spune două lucruri care, împreună, descriu exact situația ta: 90% dintre respondenți folosesc AI la muncă, iar 30% raportează încredere mică sau inexistentă în codul generat. Între cele două cifre stă diferența dintre un developer care folosește un agent ca pe un autocomplete mai bun și unul care duce funcționalități cu modele în producție și răspunde pentru ele.

Planul de mai jos e scris pentru cine are deja un job de developer. Nu e reconversie, nu e pregătire pentru primul interviu și nu presupune că renunți la limbajul tău. E un traseu de patru săptămâni, cu un livrabil verificabil pe săptămână, făcut pe codul de la muncă, nu pe un proiect de tutorial.

Ce ai la final

Trei lucruri pe care le poți arăta, nu le poți doar declara:

1. Un depozit configurat în care agentul greșește măsurabil mai rar decât acum: instrucțiuni de proiect, permisiuni, verificări care blochează.
2. O funcționalitate cu model livrată în spatele unui comutator, cu tratarea erorilor, cost măsurat și posibilitate de revenire.
3. O suită de evaluare care spune, în douăzeci de minute, dacă o schimbare de prompt sau de model a stricat ceva.

Dacă la final ai aceste trei lucruri, ai trecut linia care separă „folosesc AI" de „proiectez cu AI". Cadrul conceptual complet — cum se comportă un model, ce înseamnă RAG, agenți, evaluare — e în cursul Introducere în AI Engineering, iar planul de mai jos e felul în care îl transformi în muncă vizibilă.

Planul, pe scurt

Totalul e sub 25 de ore, adică sub o oră pe zi lucrătoare. Ce nu se vede în tabel e partea care contează: fiecare livrabil rămâne în depozit după ce termini, deci beneficiul nu depinde de memoria ta.

Săptămâna 1 — controlul agentului

Obiectivul săptămânii: agentul lucrează în proiectul tău după regulile proiectului, nu după cele generice.

Zilele 1–2. Instrucțiunile de proiect. Scrii fișierul pe care agentul îl citește la fiecare sesiune: comenzile exacte de build și test, convențiile care diferă de implicit, structura, capcanele. Formatul deschis și diferențele dintre unelte sunt tratate în ghidul despre AGENTS.md. Nu îl scrii dintr-o dată: pornești de la cinci linii și adaugi o linie de fiecare dată când corectezi aceeași greșeală a doua oară.

Zilele 3–4. Permisiuni și izolare. Stabilești ce poate atinge agentul: ce fișiere citește, ce comenzi are voie să ruleze, unde scrie. Nu e paranoia, e igienă — detaliile și incidentul din septembrie 2026 care le justifică sunt în articolul despre izolarea agenților de programare.

Ziua 5. Măsurătoarea. Ții o listă cu ce corectezi manual. La finalul săptămânii, fiecare corecție care apare de două ori devine o linie în fișierul de instrucțiuni. Aceasta e singura metrică din prima săptămână și e suficientă.

Livrabil: depozitul configurat, plus lista de corecții recurente. Timp realist: 4–6 ore, împărțite în felii de 45 de minute.

Săptămâna 2 — prima funcționalitate cu model

Obiectivul: un apel către un model, în produsul real, care rezistă la ce se întâmplă în producție.

Alege o sarcină mică și reversibilă. Exemple care funcționează bine: clasificarea automată a tichetelor primite, extragerea structurată a datelor dintr-un document pe care oamenii îl copiază manual acum, generarea unui rezumat afișat lângă o înregistrare, normalizarea unui câmp de text liber. Ce nu alegi în săptămâna a doua: ceva ce atinge plăți, date personale sensibile sau un flux fără cale de întoarcere.

Ce construiești, concret:

• Un singur punct de intrare către furnizor, cu identificatorul modelului în configurație, nu în cod.
• Răspuns structurat, validat cu o schemă. Dacă validarea pică, ai un comportament definit, nu o excepție.
• Tratarea erorilor: limitare de rată, indisponibilitate, răspuns gol, timp de așteptare depășit.
• Un comutator care oprește funcționalitatea fără livrare nouă.
• Jurnal cu versiunea modelului, durata și costul per cerere.

Partea de integrare — streaming, apelarea uneltelor, orchestrare, punere în producție — e acoperită în cursul Integrare Avansată LLM. Iar dacă funcționalitatea are interfață, disciplina de streaming și stările din interfață sunt în ghidul despre streaming în aplicații AI.

Livrabil: funcționalitatea în mediul de test, cu comutator, cu cost pe cerere afișat undeva unde îl vede echipa.

Săptămâna 3 — calitatea, măsurată

Aici se desparte apele. Majoritatea developerilor se opresc după săptămâna a doua, cu o funcționalitate care „merge de obicei". Săptămâna a treia transformă „de obicei" într-un număr.

Zilele 1–2. Setul de cazuri. Între 30 și 50 de intrări reale, anonimizate, care acoperă: fluxul obișnuit, intrări scurte și lungi, limba română cu diacritice, cazurile care au produs deja probleme, intrările ostile și situația în care răspunsul corect e „nu știu".

Ziua 3. Ce măsori. Nu doar „e bun răspunsul": rata de răspunsuri valide structural, corectitudinea pe cazurile cu răspuns cunoscut, rata de refuz, latența la percentila 95, costul mediu pe cerere.

Ziua 4. Pragurile. Scrise înainte de prima rulare, nu după. Sub ce valoare nu livrezi.

Ziua 5. În pipeline. Suita rulează la fiecare modificare de prompt sau de model. Dacă durează prea mult pentru fiecare pull request, rulează nocturn — important e să ruleze fără ca cineva să-și amintească.

Metoda completă, cu seturi de referință, model-judecător și porți de calitate în pipeline, e subiectul cursului AI Evals pentru LLM-uri în Producție.

Livrabil: suita de evaluare în depozit, cu un raport care arată scorul curent.

Săptămâna 4 — securitate, cost, și raportul

Zilele 1–2. Codul generat trece prin filtre. Instalare reproductibilă din fișierul de blocare, analiză statică de securitate, verificarea dependențelor noi, protecție la push pentru secrete. Clasele de risc și motivele lor sunt în ghidul despre cod generat de AI în producție.

Ziua 3. Costul. Calculezi costul lunar al funcționalității la volumul real și îl compari cu ce economisește. Dacă nu poți face acest calcul, funcționalitatea nu e gata.

Ziua 4. Ce se întâmplă când greșește. Scrii, în zece rânduri: cum îți dai seama, cine oprește funcționalitatea, ce spui utilizatorului, ce verifici înainte s-o repornești.

Ziua 5. Raportul. O pagină pentru echipă și pentru managerul tău: ce ai construit, ce măsori, ce costă, ce riscuri ai închis. Fără superlative, cu cifre.

Livrabil: raportul. E, de departe, cea mai valoroasă pagină din tot planul — pentru că e singura pe care o citește cineva care decide bugete.

Cum îți alegi proiectul potrivit

Patru criterii, în ordinea importanței:

1. Real. O sarcină pe care echipa o face manual acum. Un proiect inventat nu produce nici context, nici sprijin.
2. Mic. Dacă nu încape în două săptămâni cu jumătate de normă, e prea mare.
3. Reversibil. Trebuie să poți opri funcționalitatea fără consecințe.
4. Cu date neinteresante. Fără date personale sensibile, fără secrete comerciale, la prima încercare.

Dacă nu găsești nimic care să bifeze toate patru, cea mai bună alegere e o unealtă internă pentru echipa ta: triaj de tichete, rezumate de jurnale, verificări pe pull request-uri. Se livrează repede și nimeni nu blochează livrarea.

Cum obții timpul pentru asta

Planul presupune o oră pe zi din programul de lucru, iar felul în care o ceri decide dacă o primești.

Ce nu funcționează: „vreau să învăț AI". Sună a proiect personal făcut pe banii firmei.

Ce funcționează: o propunere de trei rânduri, cu o problemă reală a echipei. „Triajul manual al tichetelor ne ia aproximativ patru ore pe săptămână. Propun să construiesc o clasificare automată în patru săptămâni, cu măsurarea calității și cu buton de oprire. Cer o oră pe zi și accesul la un cont de API cu buget de X pe lună." Managerul evaluează o investiție de douăzeci de ore cu rezultat măsurabil, nu o dorință de dezvoltare personală.

Trei detalii care cresc șansele de aprobare: numeri costul în avans, ceri un buget mic și explicit, și te angajezi la un raport la final, indiferent de rezultat. Un proiect care se poate opri fără pierderi e ușor de aprobat.

Dacă răspunsul rămâne nu, planul funcționează și pe un proiect propriu, cu un singur compromis: livrezi pentru tine, nu pentru o echipă, deci pierzi partea de context real. Restul — controlul agentului, evaluarea, costul, procedura de avarie — rămâne identic.

Greșelile care fac planul să eșueze

Începi cu unealta, nu cu problema. Trei zile de comparat agenți și configurat extensii, urmate de nicio livrare. Alegi unealta pe care o ai deja și treci la treabă.

Alegi un proiect prea ambițios. Un asistent peste toată documentația companiei pare impresionant și nu se termină niciodată. O clasificare de tichete se livrează în două săptămâni și produce cifre reale.

Sari peste săptămâna a treia. E cea mai puțin spectaculoasă și singura care transformă rezultatul într-un argument. Fără măsurare, ai o demonstrație, nu o funcționalitate.

Nu scrii nimic. Dacă nu rămâne un fișier de instrucțiuni, o suită de evaluare și un raport, peste trei luni ai doar amintirea vagă că „a mers bine".

Confunzi volumul cu progresul. Zece ore într-o sâmbătă produc mai puțin decât cinci sesiuni scurte în cinci zile, pentru că învățarea aici e o buclă de feedback: scrii, rulezi, corectezi, notezi.

Ce nu faci în aceste 30 de zile

• Fine-tuning. Aproape niciodată nu e primul răspuns, iar diagnosticul corect cere date pe care încă nu le ai.
• Un sistem de regăsire peste toată documentația companiei. E un proiect în sine, cu permisiuni și evaluare proprie.
• Schimbarea limbajului. Exemplele din ecosistem sunt în Python și TypeScript, dar componentele se proiectează în limbajul aplicației tale. Traseele pe limbaj sunt în secțiunea AI pentru programatori.
• Trei unelte în paralel. Alegi una, o înveți bine, o compari abia după.

Cum arăți rezultatul fără să te lauzi

Raportul de o pagină, scris în limbajul consecințelor: „triajul tichetelor durează acum 4 secunde în loc de 3 minute, la un cost de X pe lună, cu o rată de clasificare corectă de Y% măsurată pe 50 de cazuri, cu oprire dintr-un comutator". Adaugi linkul către suita de evaluare și către jurnalul de cost.

E singura formă de dovadă care funcționează în interiorul unei firme, pentru că poate fi verificată de oricine, în cinci minute. Certificările și cursurile susțin povestea; ele nu o înlocuiesc.

Ce urmează după ziua 30

Depinde de unde te-a dus proiectul. Dacă partea grea a fost calitatea răspunsurilor, continui cu evaluarea și cu ingineria de context. Dacă a fost integrarea, continui cu arhitectura sistemelor AI și cu costul. Dacă ai descoperit că cel mai mult te-a costat verificarea codului generat, continui cu partea de securitate și cu automatizarea verificărilor.

Raportul DORA formulează, de fapt, concluzia acestui plan: „AI nu repară o echipă; amplifică ce există deja". La nivel individual funcționează la fel — amplifică disciplina pe care o ai, nu pe cea pe care ți-o dorești.

Întrebări frecvente

Î: Am nevoie să știu Python ca să urmez planul? R: Trebuie să-l poți citi, pentru că majoritatea exemplelor și a uneltelor de evaluare sunt scrise în Python sau TypeScript. Nu trebuie să-ți schimbi limbajul: componentele AI se proiectează în limbajul aplicației tale, iar ecosistemele Java, C#, PHP, Go și Rust au SDK-uri oficiale. Traseele pe limbaj sunt detaliate în secțiunea pentru programatori.

Î: Cât timp pe zi cere planul? R: Aproximativ o oră pe zi lucrătoare, cu vârfuri în săptămâna a treia. Ritmul contează mai mult decât volumul: patru sesiuni de 45 de minute pe săptămână, făcute constant, produc mai mult decât o zi întreagă la final de lună.

Î: Ce fac dacă firma nu îmi permite să folosesc un model extern pe codul de producție? R: Alegi o sarcină pe date interne neconfidențiale sau, dacă politica interzice complet transmiterea către exterior, faci partea de evaluare și de proces pe un proiect propriu și duci în firmă rezultatul sub formă de propunere. Tot planul funcționează și cu modele găzduite intern; ce se schimbă e costul de operare, nu metoda.

Î: Planul mă ajută să obțin o mărire sau alt job? R: Nu există garanții în această privință și nimeni nu ți le poate da. Ce produce planul e o dovadă verificabilă — o funcționalitate în producție, o suită de evaluare, un raport cu cifre — pe care o poți pune pe masă într-o discuție de evaluare sau într-un interviu. Restul depinde de context, de firmă și de piață.

Î: De unde știu că am făcut progres real, nu doar că am bifat pași? R: Din trei semnale măsurabile: numărul de corecții repetate pe care i le dai agentului scade, suita de evaluare prinde cel puțin o regresie pe care ai fi scăpat-o altfel, iar costul funcționalității tale e un număr pe care îl poți spune din memorie. Dacă niciunul nu s-a schimbat, ai citit, nu ai construit.

Concluzie

Diferența dintre developerii care rămân valoroși în 2026 și restul nu e viteza de scriere a codului — agenții au rezolvat asta pentru toată lumea. E capacitatea de a garanta ceva: că funcționalitatea se comportă previzibil, că defectele sunt prinse înainte de producție, că un cost e cunoscut, că există un buton de oprire.

Cele patru săptămâni de mai sus nu te transformă în specialist. Îți dau exact atât cât să poți spune, cu dovezi, că duci o funcționalitate cu model de la idee la producție fără să rupi nimic. În multe echipe, asta e deja mai mult decât are oricine altcineva.

Surse: Raportul DORA 2025, anunț Google Cloud

Articol informativ, publicat la 18 septembrie 2026. Are caracter educativ, nu constituie consultanță profesională și nu promite rezultate de carieră. Parcursul descris presupune respectarea politicilor interne ale angajatorului privind folosirea instrumentelor AI și a datelor companiei.