17 milioane de pull request-uri generate de AI în martie 2026 este cifra care contează aici. Nu optica Azure versus AWS. Nu formularea de PR despre „strategie multi-cloud”. Dacă această cifră este măcar aproximativ corectă, atunci problema inginerească este simplă: GitHub nu mai deservește în principal activitate de dezvoltare în ritm uman. Deservește automatizare la viteză de mașină, permanent activă, iar vechiul model de fiabilitate nu mai ține.
De aceea ar trebui să le pese inginerilor. Când GitHub are acum probleme de disponibilitate, nu mai este doar o zi proastă pentru source control. Poate bloca CI/CD, întârzia release-uri în producție, strica fluxuri asistate de Copilot și opri ecosisteme de automatizare pe care multe echipe le-au construit în jurul lui. Dacă lanțul vostru de livrare este legat strâns de GitHub Actions, vorbim despre risc de platformă, nu despre bârfă legată de rivalitatea dintre cloud-uri.
Ce s-a întâmplat de fapt
Sursa spune că Microsoft a confirmat rutarea traficului GitHub prin AWS după ce cererea generată de AI coding agents a împins serviciul peste pragurile de fiabilitate așteptate de clienții enterprise. Mai spune și că GitHub a avut nouă incidente care au degradat serviciul în mai 2026, iar disponibilitatea din iunie era sub 99% la jumătatea lunii.
Creșterea cererii este povestea mai importantă:
- 275 de milioane de commit-uri pe săptămână
- 14 miliarde de commit-uri anualizate pentru 2026 versus 1 miliard în tot 2025
- utilizarea GitHub Actions urcată la 2,1 miliarde de minute într-o singură săptămână la începutul lui 2026
- pull request-urile create de agenți AI crescute de la aproximativ 4 milioane în septembrie 2025 la peste 17 milioane în martie 2026
Acest tipar contează pentru că agenții AI nu se comportă ca dezvoltatorii. Nu se deloghează noaptea și nu urmează curbele de trafic din programul de birou. Lovesc API-uri, deschid PR-uri, pornesc workflow-uri, propagă webhook-uri, alocă runner-e și generează churn de stocare continuu. Dacă implementezi Microsoft Copilot și AI agents fără să te gândești la sarcina de platformă pe care o creează în jurul lor, nu cumperi doar licențe. Schimbi profilul de trafic al sistemului tău de livrare.
De ce mai multă capacitate nu este suficientă
Cea mai credibilă parte din acest material este observația arhitecturală. Problema nu este doar compute brut. Este cuplarea.
CTO-ul GitHub, citat în sursă, a descris trei probleme: creștere rapidă de încărcare, cuplare arhitecturală care a permis defectelor locale să se propage și mecanisme slabe de load shedding pentru clienți rău comportați sau prea agresivi. Asta este formularea reală a problemei.
O platformă poate supraviețui creșterii cererii dacă defectele rămân izolate. Are probleme când o dependență supraîncărcată se transformă simultan în eșecuri pentru Actions, PR-uri, Copilot și interfața web. În practică, rutarea surplusului către AWS cumpără timp. Nu repară un sistem strâns cuplat.
Este și un semnal strategic incomod pe care Microsoft probabil nu vrea să îl sublinieze: o platformă fanion pentru dezvoltatori, legată direct de povestea sa AI, a avut nevoie de capacitate din cloud-ul rival deoarece migrarea și redesenarea nu puteau ține pasul cu cererea. Este o decizie pragmatică și corectă pentru uptime. Dar rămâne un avertisment că adopția agenților depășește planificarea infrastructurii, chiar și la scară de hyperscaler.
Ce schimbă asta pentru echipele enterprise
Pentru majoritatea organizațiilor nu există motiv de panică. Există însă un motiv să nu mai presupuneți că GitHub este o utilitate infinită.
La ce m-aș uita:
- Dacă GitHub Actions este singura voastră cale de CI/CD, procesul de release are risc de concentrare.
- Dacă agenții interni AI pot deschide PR-uri și porni workflow-uri fără control, s-ar putea să creați presiune de cost și de fiabilitate pe care nici măcar nu o măsurați încă.
- Dacă automatizarea depinde de un singur control plane SaaS, raza de impact a unui outage este acum o problemă de guvernanță, nu doar de operațiuni.
Aici începe să conteze un audit AI și automatizare. Nu pentru că GitHub ar fi unic de slab, ci pentru că multe echipe au adoptat dezvoltarea agentică drept o decizie de tooling, nu o decizie de sistem.
O măsură practică este să puneți disciplină în jurul workflow-urilor pornite de agenți. Principiul least privilege se aplică și aici: un agent nu ar trebui să primească acces nelimitat la repo și un buget CI nelimitat. Dacă construiți automatizări cu PowerShell, Azure Functions, Logic Apps, ServiceNow sau n8n în jurul acestor fluxuri, rate limiting, token-uri cu scope redus, controale de concurență și căi de fallback ar trebui să fie parte din design, nu o idee de după.
Părerea mea
Este o poveste mixtă, nu un scandal și nici un non-eveniment.
Merită credit: folosirea AWS ca overflow temporar este mișcarea pragmatică. Clienții au nevoie de uptime, nu de teatru despre puritatea cloud-ului.
Dar partea incomodă este reală: AI coding agents nu au crescut doar utilizarea GitHub; au schimbat forma cererii mai repede decât puteau absorbi arhitectura GitHub și migrarea către Azure. Acest efect de ordinul doi va lovi orice platformă care confundă creșterea agenților cu o creștere obișnuită de utilizatori.
Dacă operezi platforme de engineering, lecția este clară: tratează agenții ca generatori de încărcare pentru infrastructură. Dacă folosești aceste platforme, pornește de la premisa că vor exista outage-uri și proiectează procesul de livrare astfel încât un incident într-un singur SaaS să nu înghețe business-ul.
