Agenți AI pentru infrastructură și DevOps: ce funcționează cu adevărat în 2026

Fiecare prezentare de vendor din anul ăsta promite un agent AI care „îți rulează infrastructura”. Noi folosim agenți AI zilnic — ne-au ajutat să livrăm trei tool-uri open-source de infrastructură — și operăm o rețea reală, AS210622, unde o schimbare greșită înseamnă că pachete reale se opresc din a mai circula. Combinația asta ne-a dat o perspectivă destul de lipsită de sentimentalism asupra a ceea ce fac bine agenții în munca de infrastructură și unde marketingul o ia înaintea realității.

Versiunea scurtă: agenții sunt excelenți la a propune schimbări de infrastructură și îngrozitori când li se acordă încrederea să le aplice. Aproape tot restul decurge din această distincție.

Unde își câștigă agenții pâinea

Câștigurile sunt reale și se grupează în jurul muncii care are un pattern clar de urmat și un checkpoint uman la final:

• Terraform și manifeste Kubernetes după un pattern existent. Odată ce repo-ul tău are un modul bine construit sau un Deployment configurat corect, un agent poate produce următoarele zece variante mai repede decât oricine din echipă — și, important, consistente cu stilul existent. Pattern-ul este specificația. Funcționează pentru că Terraform la scară este în mare parte repetiție disciplinată, iar repetiția disciplinată este exact ce fac agenții bine.
• Dockerfile-uri și pipeline-uri de CI. Build-uri multi-stage, cache mounts, matrix builds, workflow-uri de release — este teren bătătorit, cu convenții puternice. Agenții produc prime drafturi bune și prind flag-urile pe care le-ai uitat.
• Drafturi de runbook-uri. Dă-i unui agent definiția alertei, dashboard-ul și politica de escaladare, și va produce un schelet de runbook pe care un inginer on-call îl poate corecta în douăzeci de minute în loc să-l scrie în trei ore. Pasul de corectare nu este opțional — dar este mult mai ieftin decât pagina goală. Playbook-ul nostru de incident response și-a primit primele drafturi așa.
• Rezumarea log-urilor și a incidentelor. Să-i dai unui agent un canal de incident zgomotos sau un zid de log-uri și să-l întrebi „ce s-a întâmplat de fapt, în ordine” este una dintre cele mai valoroase utilizări cu risc minim pe care le știm. Este read-only prin construcție.
• Corvezi de migrare. Redenumirea unei resurse în patruzeci de module, actualizarea versiunii unui provider și repararea deprecărilor, conversia sintaxei unui sistem de CI în a altuia. Mecanic, plictisitor și exact munca pe care nu o vrea nimeni.

Observă ce au în comun: output-ul agentului ajunge într-un fișier, un PR sau un document. Un om — sau un pipeline care acționează pe baza aprobării unui om — stă între output și producție.

Unde nu

Modul de eșec nu este că agenții scriu configurații proaste. O fac uneori, și review-ul prinde asta. Modul de eșec este să legi un agent astfel încât output-ul lui să intre în vigoare fără review.

Un agent care poate rula kubectl apply pe producție, sau poate face push pe un branch care se deployează automat, sau poate modifica direct un security group, are un blast radius egal cu credențialele lui — și, spre deosebire de un operator uman, va acționa pe baza unei neînțelegeri cu încredere totală și la viteza automatizării. Am văzut agenți (ai noștri, în sandbox-uri) „reparând” cu încredere o problemă prin ștergerea lucrului care o raporta. Într-un sandbox e amuzant. Cu credențiale de producție este un incident cu o secțiune de root cause neobișnuită.

Nu este o limitare temporară pe care o rezolvă următoarea versiune de model. Este o proprietate structurală: agenții acționează pe baza unui text, textul poate fi greșit sau rău intenționat, iar producția este locul în care greșelile devin outage-uri.

Regula de aur: agenții propun, pipeline-urile aplică

Pattern-ul care funcționează — cel pe care l-am recomanda oricărei echipe care leagă agenți de infrastructură — este că agenții propun, pipeline-urile aplică.

Concret: accesul de scriere al agentului este un pull request. Nimic mai mult. PR-ul declanșează aceeași mașinărie pe care o declanșează PR-ul unui om — terraform plan, verificări de policy, kubeconform, CI. Un om citește output-ul plan-ului. Merge-ul deployează prin aceeași reconciliere GitOps care aplică orice altă schimbare.

GitOps se dovedește a fi harness-ul natural pentru schimbările de infrastructură generate de AI, din același motiv pentru care merita adoptat înainte să existe agenți: forțează fiecare schimbare printr-o cale care poate fi revizuită, auditată și revenită. Dacă rulezi deja plan-on-PR și reconciliere continuă, ai deja cea mai mare parte din infrastructura de guardrail-uri de care au nevoie agenții. Dacă nu, asta — nu tooling-ul pentru agenți — este primul lucru de construit.

Corolarul pentru acces: read-only mai întâi. Un agent care îți poate interoga metricile, citi manifestele și inspecta fișierele de state poate face deja cea mai mare parte din munca valoroasă — rezumă, diagnostichează, schițează. Accesul de scriere, când îl acorzi, trece prin aceleași porți de PR prin care ar trece al unui coleg nou. Am scris mai multe despre cum legi asta în siguranță în postul nostru despre cum dai agenților acces la infrastructură reală.

Întrebarea despre blast radius

Înainte să legăm orice agent de orice sistem, punem o singură întrebare: dacă acest agent face cel mai rău lucru plauzibil pe care i-l permite accesul, ce se întâmplă?

Nu cel mai rău lucru probabil — cel mai rău lucru plauzibil. Un agent cu un token Grafana read-only poate scurge un dashboard. Un agent cu cluster-admin poate șterge namespace-uri. Un agent care își poate face merge la propriile PR-uri poate ocoli fiecare poartă de review pe care ai construit-o. Dacă răspunsul la întrebare este mai rău decât „revenim un commit”, accesul este prea larg.

Este același raționament pe care îl aplicăm credențialelor umane și oricărei automatizări, agenți incluși. Diferența este că echipe care nu i-ar da niciodată unui contractor cluster-admin din prima zi îi dau unui agent, pentru că demo-ul a fost impresionant. Demo-ul este întotdeauna impresionant. Restrânge credențialele oricum.

O evaluare sinceră

Unde lasă asta agenții AI în munca de infrastructură în 2026? Sunt pârghie, nu înlocuire. Deciziile de judecată — ce construiești, ce înseamnă „corect”, ce risc este acceptabil, când output-ul plan-ului miroase a greșit — rămân muncă umană și, din experiența noastră, devin mai importante, nu mai puțin, pentru că volumul de schimbări propuse crește. Un inginer cu un agent bine ținut în frâu produce mai mult decât unul fără. Un agent fără inginer produce incidente.

Spunem asta ca oameni suficient de optimiști cu privire la tehnologie încât să ne fi construit workflow-ul în jurul ei. Echipele care obțin valoare reală nu sunt cele cu setup-ul cel mai autonom. Sunt cele cu cele mai bune guardrail-uri.

Concluzii

1. Folosește agenți acolo unde output-ul ajunge într-un artefact care poate fi revizuit — manifeste, pipeline-uri, runbook-uri, rezumate, migrări
2. Nu lăsa niciodată output-ul unui agent să ajungă în producție fără review — agenții propun, pipeline-urile aplică
3. GitOps și plan-on-PR sunt harness-ul — dacă nu le ai, construiește-le înainte să legi agenți
4. Acces read-only mai întâi; acces de scriere doar prin aceleași porți de PR pe care le folosesc oamenii
5. Pune întrebarea despre blast radius înainte să acorzi orice credențial: care este cea mai rea acțiune plauzibilă pe care o permite acest acces?
6. Tratează agenții ca pârghie pentru ingineri și investește corespunzător în judecata inginerilor

Dacă vrei ajutor ca să pui guardrail-urile la locul lor — GitOps, porți de CI, acces restrâns — astfel încât echipa ta să poată folosi agenți fără să parieze producția pe ei, exact genul ăsta de muncă facem noi.