GitHub dodał 4 mln rdzeni CPU, bo agenci AI obciążają platformę

GitHub rozbudował w tym roku infrastrukturę o cztery miliony rdzeni CPU, 160 petabajtów szybkiej pamięci masowej i 50 terabitów na sekundę przepustowości sieci. Według danych platformy to dodatkowe zasoby, a nie całkowita jej pojemność, i nie chodzi o cztery miliony fizycznych procesorów. Firma wymienia agentów AI wśród głównych przyczyn rosnącego obciążenia.

Rekordowa liczba commitów

Z raportu Octoverse 2026 wynika, że liczba commitów rocznie wzrosła z 12,9 mld do 34,3 mld w ciągu dwunastu miesięcy do września 2026 roku, wliczając repozytoria publiczne i prywatne. Sam wrzesień przyniósł 7,38 mld commitów. To miara zarejestrowanej aktywności, a nie liczby wygenerowanych linii kodu, bo jeden commit może zawierać zmiany bardzo różnej wielkości.

Zmienia się też sposób pracy programistów. We wrześniu ponad 40% pull requestów zaczynało się od szkicu przygotowanego przez agenta AI, którego platforma była w stanie wykryć. W marcu było to 17%. Nowe repozytoria z plikami konfiguracyjnymi dla agentów miały średnio osiem razy więcej commitów niż te bez nich, choć samo porównanie nie dowodzi proporcjonalnego wzrostu produktywności.

Problemem jest częstotliwość, nie rozmiar

Agent, który dostaje zadanie, analizuje repozytorium, proponuje zmiany i poprawia je po kolejnych testach, generuje wiele wysyłek, odczytów i automatycznych kontroli. Gdy działa równolegle wiele agentów, platforma musi nie tylko przechowywać więcej danych, ale też szybko je przesyłać i przetwarzać.

Ograniczenia dały się już odczuć. 17 sierpnia 2026 roku GitHub miał awarię trwającą siedem godzin i 47 minut. Według firmy ruch osiągnął nowy szczyt, a kluczowy komponent centrum danych w USA nie zdołał się skalować. GitHub przyznał, że nie zwiększył części zasobów odpowiednio wcześnie, ale nie przypisał awarii bezpośrednio agentom AI.

Zmiana architektury

Samo dokładanie mocy nie wystarczy. GitHub przenosi infrastrukturę do kilku regionów Microsoft Azure i oddziela przechowywanie danych od ich przetwarzania, by skalować je niezależnie. Chce też ograniczyć liczbę operacji wymagających wzajemnej koordynacji. W testach wewnętrznych nowa architektura zwiększyła przepustowość zapisu nawet 35-krotnie, ale wynik ten nie odzwierciedla jeszcze ogólnej wydajności platformy.

Dla programistów wniosek jest taki, że łatwiejsze generowanie propozycji kodu nie oznacza automatycznego ich włączania do projektu. Zmiany nadal trzeba przejrzeć, przetestować i zdecydować, które zachować, a usługi muszą obsługiwać coraz bardziej zautomatyzowaną aktywność.