Cum ajunge o sarcină în producție
Cum lucrez de fapt în 2026: fiecare sarcină trece mai întâi prin două filtre — poate evita complet munca manuală și poate fi accelerată scrierea — și abia apoi ajunge la cod. Mai jos, tot lanțul, pas cu pas.
Precondiție — proprietar sau executantFiltrul funcționează doar când sunt proprietarul zonei mele
Promova mi-a recablat felul de a gândi: nu doar să fiu dezvoltator, ci să validez fiecare sarcină care ajunge la mine. Nu „cum construiesc asta”, ci „ce aduce afacerii”. Filtrul acesta funcționează însă doar cu o condiție.
Sarcina trece imediat prin filtru. Răspund pentru rezultat, deci am dreptul să spun „asta n-ar trebui construită deloc” sau „asta n-ar trebui construită de mine”.
Fără filtru. Există o sarcină, un termen și o livrare. Nu e nimic rău în asta — e pur și simplu alt contract.
Diferența nu e priceperea, ci mandatul. O unitate independentă care deține complet zona ei costă compania mai puțin decât un executant — pentru că nu construiește ce e inutil.
Înainte de cod
Sosește o sarcină
Nu pornesc de la „cum construiesc asta”. Prima întrebare e ce aduce afacerii; a doua, dacă trebuie construită de mână, și de mine, în general.
Filtrul unu — se poate evita complet munca manuală?
Trei ieșiri, și toate trei răspund la o întrebare: cine se ocupă de acum înainte. Dacă sarcina ia oricare dintre ele, încetează să mai fie a mea, iar capacitatea mea rămâne liberă pentru munca ce chiar are nevoie de un dezvoltator.
ieșiri din pipeline- Făcut de agent
Se configurează o dată și nu se mai întoarce la nimeni. De acolo, un agent o rulează și o duce la capăt complet singur, fără nicio implicare.
Review de cod automat · analytics ajunge direct într-un canal Slack dedicat, în loc să scoți loguri de mână
- Făcut de solicitant
Sarcina nu ajunge deloc la mine. Cine are nevoie de ea o face singur, împreună cu AI — partea mea e să construiesc drumul o singură dată.
Mailing de outreach · platformă de influenceri
- Făcut de echipă
O funcționalitate sau un plugin cusut în sistem, prin care echipa face singură modificările — fără tichet, fără dezvoltator.
Plugin de redirecturi în CMS, deținut de echipa SEO
Filtrul doi — accelerarea scrierii propriu-zise
Sarcina a trecut de filtrul unu, deci e a mea. Următoarea întrebare: e rutină în termeni de cod? Dacă tiparul se repetă — stiluri de buton, o structură recurentă — scriu întâi un skill pentru el și abia apoi codul. O dată mai lung, apoi de fiecare dată mai rapid.
Decizie
Plan mode — analiză înainte de o singură linie
Trebuie să trăiesc acest cod, nu să-l primesc. Planul decide cine îl scrie.
- Nu cunosc acest cod
- Îl scriu eu.
- Cunosc acest cod
- Îl scrie agentul.
- Nu-l cunoșteam, dar planul l-a lămurit
- Îl scrie agentul.
Livrare
Implementare
Începe să scrie cine a fost ales de plan — eu sau agentul.
Verificări în dev — agentul
Verifică agentul, nu eu: parcurge fluxul prin Playwright sau citește erorile direct din dev server-ul Next.js prin MCP. Aici nu se duce nimic din capacitatea mea.
Verificări în mod build — agentul
Dev-ul minte. Alte chunk-uri, alte optimizări, alt comportament. Ceva ce merge în dev și moare în build e un clasic, așa că build-ul are propria trecere — condusă din nou de agent.
Teste unitare + Playwright
Doar după ce chiar funcționează. Teste unitare pentru logică, Playwright pentru flux — scrise tot de agent.
Staging — aici intru eu
Primul punct pe care îl verific eu însumi, manual. Local doar când sarcina e sensibilă. Apoi merge la QA — în ordinea asta, nu invers.
Pull request
Verificat de agenți care poartă skill-urile ce guvernează acea zonă a proiectului: o schimbare de performanță e verificată față de regulile de performanță, una de plăți față de regulile de plăți.
Producție
Release.
Verificare finală
QA pe producție. Dacă rezistă — gata.
- OOP
- SOLID
- DRY
- KISS
- YAGNI
- CI/CD
Cunoscând practicile de arhitectură și ținând ordinea pașilor, codul poate fi scris repede și bine în același timp. Viteza vine din secvență, nu din tastat mai rapid.
Expertiza într-o tehnologie anume produce mereu cod mai bun — asta nu se discută. Dar nu se transferă: schimbi stack-ul și o iei de la capăt. Înțelegerea fluxului de dezvoltare, a arhitecturii și a principiilor se transferă în întregime. Ea e cea care face posibilă munca într-un cod pe care nu-l cunoști încă: plan mode (pasul 04) arată cum e alcătuit exact acest proiect, iar să judeci dacă o soluție e cea potrivită știi deja.