CI/CD agentic la OpenAI: ce înseamnă pentru DevOps
CI/CD agentic la OpenAI: ce înseamnă pentru angajările DevOps
Unele sisteme build-test-deploy de la OpenAI au preluat de aproximativ 10 ori mai multă încărcare în circa șase luni, o creștere care la majoritatea companiilor ar putea dura doi-trei ani, pe măsură ce agenții Codex au preluat implementarea, testarea și deschiderea de pull requests. Dacă angajezi ingineri DevOps, SRE sau de platformă seniori, concluzia nu e „AI-ul îi face pe ingineri mai rapizi”. În opinia noastră, competența rară s-a mutat de la ținerea pipeline-urilor în funcțiune la proiectarea nivelurilor de risc, a porților de review și a observabilității care le permit agenților să folosească acele pipeline-uri fără ca un om să aprobe fiecare schimbare.
Interviurile pentru DevOps senior testau dacă un candidat poate ține CI-ul verde. La OpenAI, agenții urmăresc acum CI-ul până devine verde. Ce are încă nevoie de un om este stabilirea regulilor: ce schimbări are voie un agent să aprobe.
Pe 15 septembrie 2026, Gergely Orosz a publicat Inside OpenAI’s agentic software factory în The Pragmatic Engineer. Venkat Venkataramani, VP of Engineering pentru Applied Infra la OpenAI, i-a spus că firma vede „o creștere de aproximativ 10x a încărcării pe unele sisteme” în circa șase luni. La majoritatea companiilor, a spus el, o asemenea creștere ar putea dura doi-trei ani.
Analiza de față acoperă ce a descris OpenAI, de ce e o problemă de platform engineering și nu o poveste despre productivitate, ce competențe devin rare și șase întrebări de selecție pentru următoarea angajare de DevOps sau SRE senior. Suntem foști ingineri software care conducem căutări de Cloud & DevOps, așa că am citit articolul așa cum l-ar citi liderul tău de platformă. Am lucrat pe partea gratuită a articolului; secțiunile ulterioare sunt cu plată.
Pe scurt
- OpenAI raportează o creștere a încărcării de aproximativ 10x pe unele sisteme build-test-deploy în circa șase luni, în timp ce agenții Codex implementează, testează, deschid PR-uri și urmăresc CI-ul până trece.
- Gestionează volumul prin niveluri de risc: agenți revieweri specializați, trasee mai stricte pentru schimbările cu risc mare și aprobare automată opțională (opt-in) pentru PR-urile cu risc mic în unele zone ale codului.
- Incidentele rămân în grija oamenilor. Agentul Sevbot de la OpenAI adună context și propune remedieri, dar inginerii rămân on-call.
- La nivelul industriei, AI-ul crește throughput-ul și afectează stabilitatea. Raportul DORA 2025 asociază o adopție mai mare a AI cu mai mult throughput de livrare și cu o stabilitate mai mică a livrării.
- La angajările de DevOps și SRE seniori, verifică clasificarea riscului, observabilitatea la nivel de schimbare și limitele agenților în incidente. Doar mentenanța pipeline-urilor nu mai e ștacheta de senior.
Ce s-a întâmplat în „fabrica de software” a OpenAI?
The Pragmatic Engineer a descris un pipeline în care agenții Codex de la OpenAI preiau o mare parte din bucla mecanică de livrare (implementare, testare, deschiderea PR-urilor, urmărirea CI), iar oamenii stabilesc regulile după care lucrează agenții. Detaliile de mai jos provin din secțiunile gratuite ale articolului, publicat pe 15 septembrie 2026.
Faptele-cheie:
- Agenții conduc bucla build-test. Codex implementează o schimbare, face build și rulează testele, repară testele stricate, deschide un pull request și monitorizează CI-ul până devine verde.
- Încărcarea crește rapid. Numărul de PR-uri per inginer crește „ca o crosă de hochei”, iar fiecare parte a pipeline-ului build-test-deploy preia mai multă încărcare. Venkataramani a estimat-o la aproximativ 10x pe unele sisteme în circa șase luni.
- Review-ul e împărțit pe domenii. Mai mulți agenți revieweri, fiecare configurat ca specialist într-o zonă precum infrastructura cloud sau securitatea, analizează schimbările.
- Schimbările sunt clasificate după risc. Schimbările cu risc mare pot primi mai multe review-uri AI sau pot cere un review uman după ce agenții termină. Zonele codului pot opta pentru un agent care aprobă automat PR-urile cu risc mic, ceea ce elimină acceptarea umană ca blocaj.
- Deploy-urile vin cu propria monitorizare. Când un agent face deploy la o schimbare, își construiește propriul dashboard de monitorizare ca s-o urmărească.
- Incidentele primesc un asistent agent, nu un agent responsabil. Sevbot, agentul intern de răspuns la incidente al OpenAI, construit pe Codex, adună context, identifică posibile remedieri, răspunde la întrebări în Slack și acționează când îi spune un inginer. Inginerii rămân on-call. Obiectivul declarat este ca Sevbot să remedieze autonom întreruperile de rutină.
Utilizarea Codex s-a extins și dincolo de inginerie: echipele non-tehnice de la OpenAI au trecut de la aproximativ 0% la începutul lui 2025 la 90% până în aprilie 2026, potrivit aceluiași articol.
De ce e o încărcare de 10x în șase luni o problemă de platformă, nu o poveste despre productivitate?
Când agenții înmulțesc numărul de schimbări, blocajul se mută de la scrierea codului la verificarea, integrarea, livrarea și urmărirea lui, iar acestea sunt sarcini de platform engineering. Fiecare PR în plus înseamnă încă o rulare CI, încă un review, încă un deploy și încă un motiv pentru care cineva poate fi trezit la 3 dimineața.
OpenAI este cazul extrem, dar direcția e aceeași în toată industria. Raportul Octoverse 2025 al GitHub, pentru perioada septembrie 2024 – august 2025, a numărat în medie 43,2 milioane de pull requests îmbinate pe lună (+23% față de anul anterior), aproape 1 miliard de commit-uri (+25,1%) și 11,5 miliarde de minute GitHub Actions în proiecte publice (+35%).
În opinia noastră, majoritatea echipelor de platformă își planifică capacitatea în jurul unei creșteri mai apropiate de cele 23–35% pe an ale GitHub decât de cele 10x în șase luni ale OpenAI. Metricile diferă, dar diferența de scară contează. O echipă care își scalează capacitatea CI o dată pe an, face review manual la fiecare merge și construiește dashboard-uri per serviciu, nu per schimbare, nu doar se îndoaie sub o asemenea încărcare. Se rupe. De aceea citim acest caz ca pe un semnal de angajare, nu ca pe o anecdotă despre ingineri rapizi.
Throughput-ul crește mai repede decât stabilitatea
Raportul DORA 2025 al Google, bazat pe aproape 5.000 de profesioniști din tehnologie și publicat pe 23 septembrie 2025, a constatat că 90% dintre respondenți folosesc AI la muncă. Raportul a asociat o adopție mai mare a AI cu mai mult throughput în livrarea software, dar și cu o stabilitate mai mică a livrării. În formularea DORA, această accelerare „poate expune slăbiciuni mai departe în flux”.
Același raport a constatat că 90% dintre organizații au adoptat cel puțin o platformă internă și că există o corelație directă între calitatea platformei și capacitatea unei organizații de a obține valoare din AI. Echipa de platformă decide dacă viteza adusă de AI devine valoare livrată sau incidente.
Încrederea o ia înaintea controlului
Liderii declară încredere mare în codul scris de AI și, în același sondaj, mai multe probleme în producție cauzate de el. Acolo, în acest decalaj, își justifică salariul judecata unui DevOps sau SRE senior.
Raportul State of Code Abundance 2026 al CloudBees, un sondaj de furnizor realizat pe peste 200 de lideri tehnologici din companii mari și publicat pe 19 mai 2026, a constatat că 92% sunt încrezători că codul generat de AI e pregătit pentru producție. În același sondaj, 81% au raportat mai multe probleme în producție legate de codul generat de AI. Developerii sunt mai sceptici: în Stack Overflow Developer Survey 2025, 45,7% au spus că nu au încredere în acuratețea instrumentelor AI, iar 32,7% au spus că au.
Răspunsul OpenAI la acest decalaj nu e mai multă încredere sau mai puțină. E rutarea: decizi ce schimbări poate aproba un agent, care au nevoie de mai mult review și care au nevoie de un om. Cineva trebuie să proiecteze aceste reguli, să măsoare dacă funcționează și să le schimbe când nu funcționează. Asta e acum munca unui DevOps sau SRE senior.
Ce competențe DevOps și SRE au devenit rare?
Competențele rare sunt clasificarea riscului, observabilitatea la nivel de schimbare și stabilirea unor limite sigure pentru agenți în livrare și în incidente. Mentenanța pipeline-urilor contează în continuare, dar la OpenAI agenții fac deja o mare parte din ea. Tabelul de mai jos este interpretarea noastră despre ce implică modelul OpenAI pentru ștacheta de senior.
| Zonă | Ștacheta veche de senior | Ștacheta nouă de senior |
|---|---|---|
| CI/CD | Ține pipeline-urile verzi și rapide | Proiectează pipeline-uri care scalează cu volumul de PR-uri al agenților, inclusiv merge queues, selecția testelor și costul CI per schimbare |
| Code review | Impune review uman la fiecare merge | Definește niveluri de risc: ce se poate aproba automat, ce primește review AI suplimentar, ce trebuie să ajungă la un om |
| Observabilitate | Dashboard-uri și alerte per serviciu | Semnale per schimbare, astfel încât un deploy prost să fie prins și legat de PR-ul lui în câteva minute |
| Incidente | Face on-call și scrie postmortem-uri | Stabilește ce poate propune, rula și niciodată atinge un agent de incidente, cu audit trail |
| Metrici | Frecvența deploy-urilor și uptime-ul | Throughput și stabilitate împreună, plus rata de scăpări din fiecare nivel de risc |
Nivelurile de risc sunt o competență de design, nu un document de politici
OpenAI permite zonelor din codebase să opteze pentru aprobarea automată a PR-urilor cu risc mic. Propoziția ascunde partea grea: să definești „risc mic” în termeni pe care o mașină îi poate verifica, precum căile modificate, raza de impact (blast radius), acoperirea cu teste, configurare versus cod și reversibilitatea. Înseamnă și să dovedești că clasificatorul are dreptate, urmărind cât de des schimbările aprobate automat duc la rollback. Un candidat senior ar trebui să poată proiecta asta și să spună cum și-ar da seama că nu funcționează.
Observabilitatea trebuie să urmărească schimbarea
Când agenții livrează multe schimbări mici, dashboard-urile la nivel de serviciu nu mai răspund la singura întrebare care contează într-un incident: ce schimbare a cauzat asta? Agentul OpenAI care face deploy își construiește propriul dashboard de monitorizare ca să urmărească lansarea. Competența umană stă în a decide ce trebuie să conțină aceste dashboard-uri și în a lega între ele evenimentele de deploy, feature flags și SLO-urile, astfel încât o regresie să ducă înapoi la un singur PR.
Agenții din incidente au nevoie de limite ferme
Sevbot propune remedieri și acționează când îi spune un inginer. Inginerul rămâne on-call. Trecerea lui Sevbot de la propunerea de remedieri la gestionarea singur a întreruperilor de rutină, pe care OpenAI o descrie ca obiectiv, este o problemă de reliability engineering: ce acțiuni sunt reversibile, ce runbook-uri pot fi automatizate în siguranță și care e kill switch-ul. E gândire SRE clasică, aplicată unui nou tip de operator. Dacă alegi între profiluri DevOps și SRE pentru această muncă, aceasta e partea care înclină spre SRE.
Susținem în articolul despre ingineria AI-native că, în echipele AI-native, competența rară este verificarea: să dovedești că output-ul AI e suficient de bun înainte să ai încredere în el. Livrarea pe niveluri de risc cere aceeași judecată, construită în pipeline.
Șase întrebări de selecție pentru candidații DevOps și SRE seniori
Cere-le candidaților să proiecteze controalele, nu să enumere instrumente. Întrebările sunt ale noastre, nu ale OpenAI. Sunt gândite să testeze raționamentul din spatele controalelor, așa că nu cer experiență în producție cu agenți de programare.
| # | Întrebare | Un răspuns bun include | Semnal de alarmă |
|---|---|---|---|
| 1 | „Volumul de PR-uri crește de 10 ori în șase luni. Ce cedează primul în CI și ce schimbi?” | Cozile și testele instabile ca primele puncte de cedare; selecția testelor, merge queues, caching, costul CI per schimbare | „Adăugăm mai mulți runneri” ca singur răspuns |
| 2 | „Definește o schimbare cu risc mic pe care un agent o poate aproba automat.” | Criterii verificabile (căi, dimensiune, configurare vs cod, reversibilitate), aplicare doar în zonele cu opt-in, o cale de revocare | O listă de tipuri de fișiere, fără vreo metodă de a măsura erorile |
| 3 | „Cum ți-ai da seama că clasificatorul de risc greșește?” | Rate de rollback și de incidente per nivel, eșantionarea PR-urilor aprobate automat pentru audit uman | „O să aflăm noi” |
| 4 | „Un agent face azi deploy la 40 de schimbări mici. Una provoacă o regresie de latență. Cum o găsești?” | Marcaje de deploy, semnale per schimbare, rollout progresiv, rollback automat la încălcarea SLO | Bisectare manuală pornind de la dashboard-urile de serviciu |
| 5 | „Ce n-ar trebui să facă niciodată un agent de incidente fără un om?” | Acțiuni ireversibile sau care afectează date, orice în afara unui runbook testat, logare clară pentru audit | „Nimic, dacă e suficient de precis” sau „N-ar trebui să facă nimic” |
| 6 | „Throughput-ul a crescut și rata de eșec a schimbărilor a crescut. Ce raportezi conducerii?” | Ambele cifre împreună, stabilitatea ca restricție, un plan legat de porți concrete | Raportarea doar a frecvenței deploy-urilor |
Verificarea realității: „CI/CD agentic” e o etichetă nouă și puține CV-uri o vor conține. Caută în schimb experiența de bază: merge queues la scară, progressive delivery, SLO-uri și error budgets, observabilitate la nivel de schimbare.
Ce nu înseamnă asta
Nu înseamnă că fiecare echipă are nevoie acum de aprobare automată prin agenți sau de un titlu nou de job. Trei limite contează înainte să rescrii o fișă de post.
- OpenAI este o excepție. Construiește Codex și are un stimulent neobișnuit să împingă devreme autonomia agenților. Cifra de 10x se aplică „unor sisteme”, nu întregului pipeline, iar secțiunile ulterioare ale articolului sunt cu plată.
- Oamenii țin încă pager-ul. Sevbot nu remediază încă singur, iar schimbările cu risc mare pot cere în continuare review uman. Obiectivul de design e mai puține blocaje umane, nu zero oameni.
- Nu e nevoie de un titlu nou. „Agent ops engineer” nu e un rol pe care trebuie să-l deschizi. Aceste competențe își au locul în fișele de post existente pentru DevOps, SRE și platform seniori.
Pentru majoritatea echipelor, pasul practic e mai mic: adaugă nivelurile de risc, observabilitatea la nivel de schimbare și limitele agenților în procesul de interviu pentru seniori, înainte ca volumul generat de agenți să te oblige.
Angajarea pentru aceste competențe în România și CEE
Caută ingineri care au operat livrare la volum mare, nu doar ingineri care enumeră instrumente AI. Profilurile care se transferă cel mai bine au rulat merge queues sau CI de monorepo la scară, au construit progressive delivery cu rollback automat sau au deținut SLO-uri și on-call pentru un serviciu aglomerat. Experiența cu agenți e un bonus care se poate învăța; judecata despre raza de impact se construiește în ani. Detaliem asta în articolul despre cum conducem căutările de AI și DevOps în România.
Salariile pentru DevOps și SRE seniori în România variază mult în funcție de stack și de nivel, așa că verifică intervalele actuale în ghidul salariilor IT din România 2026 înainte să stabilești bugetul. Dacă îți construiești echipa la distanță, ghidul nostru pentru angajarea developerilor remote din România acoperă contractele, termenele și procesul. Iar dacă agenții îți umflă și factura de AI, partea de cost e în ghidul nostru despre model routing și costul de inferență.
Întrebări frecvente
Ce este CI/CD agentic?
CI/CD agentic este un pipeline de livrare în care agenții AI fac o mare parte din munca pe care oamenii o făceau manual: scriu schimbări, rulează și repară teste, deschid pull requests, fac code review și monitorizează deploy-urile. Oamenii proiectează regulile, de exemplu ce schimbări au nevoie de review uman, și se ocupă de ce nu pot face agenții.
Cât de repede crește încărcarea pe CI/CD?
Diferă foarte mult. OpenAI a raportat o încărcare de aproximativ 10x pe unele sisteme în circa șase luni. La nivelul GitHub, Octoverse 2025 a numărat cu 23% mai multe pull requests îmbinate pe lună și cu 35% mai multe minute Actions în proiecte publice față de anul anterior. Octoverse nu separă cât din această creștere vine de la AI.
Înlocuiește code review-ul făcut de AI review-ul uman?
Nu la OpenAI. Agenți revieweri specializați verifică schimbările, PR-urile cu risc mic din zonele cu opt-in pot fi aprobate automat, iar schimbările cu risc mare pot cere un review uman după ce agenții termină.
Ce să întreb un inginer DevOps senior despre agenții AI?
Întreabă-l cum ar defini o schimbare cu risc mic pe care un agent o poate aproba, cum ar detecta o clasificare greșită a riscului și ce n-ar trebui să facă niciodată un agent de incidente fără un om. Cele șase întrebări din tabelul de mai sus acoperă capacitatea CI, observabilitatea și raportarea.
Se potrivește mai bine DevOps sau SRE pentru pipeline-urile conduse de agenți?
Amândouă, pentru părți diferite. Inginerii DevOps și de platformă se ocupă de obicei de capacitatea pipeline-ului, de fluxul de merge și de tooling-ul de deploy. SRE-ii se ocupă de obicei de SLO-uri, observabilitate și limitele din incidente, adică exact zona în care autonomia agenților aduce cel mai mare risc.
Concluzia
Fabrica de software a OpenAI arată încotro merge livrarea: agenții produc schimbări mai repede decât le pot aproba oamenii, așa că pipeline-ul trebuie să decidă ce schimbări au nevoie de un om. E o problemă de design și cade în sarcina inginerilor tăi DevOps, SRE și de platformă seniori.
Trei lucruri de reținut:
- Angajează pentru designul riscului, nu pentru întreținerea pipeline-ului. Agenții pot ține CI-ul verde. Cineva tot trebuie să definească ce e sigur să aprobe automat.
- Verifică observabilitatea la nivel de schimbare. Când volumul crește de 10 ori, răspunsul la „ce schimbare a stricat asta?” trebuie să vină în minute.
- Ține oamenii on-call, cu limite clare pentru agenți. Chiar și OpenAI face asta.
Dacă angajezi un inginer DevOps, SRE sau de platformă senior care să dețină aceste lucruri, te putem ajuta să scrii fișa de post și să testezi judecata din spatele ei. Suntem foști ingineri, așa că selectăm cu întrebări ca cele de mai sus. Primești un shortlist atent selectat de trei până la cinci candidați, nu un potop de CV-uri. Spune-ne pe cine angajezi.
Ultima actualizare: 16 septembrie 2026. Surse verificate pe 16 septembrie 2026: The Pragmatic Engineer, „Inside OpenAI’s agentic software factory” (Gergely Orosz, 15 sept. 2026; doar secțiunile gratuite, secțiunile ulterioare sunt cu plată); GitHub, Octoverse 2025 (28 oct. 2025; perioada sept. 2024 – aug. 2025); Google Cloud, raportul DORA 2025 (23 sept. 2025); CloudBees, State of Code Abundance 2026 (19 mai 2026; sondaj de furnizor pe peste 200 de lideri tehnologici din companii mari); Stack Overflow Developer Survey 2025, secțiunea AI. Citatele din surse în limba engleză sunt traduse de noi. Tabelul de competențe și întrebările de selecție sunt analiza Wise Step, nu a OpenAI.