832 tysiące linii kodu, jedna duża migracja i agenci AI piszący większość implementacji brzmią jak idealny materiał na prezentację pod tytułem “programiści są już niepotrzebni”. Tyle że z opisu GitHuba wynika coś znacznie ciekawszego. Ta historia nie jest o tym, że agent dostał repozytorium i wrócił po weekendzie z gotowym systemem. Jest o tym, jak bardzo trzeba było ograniczyć zakres zmian, testować, wydawać małymi porcjami i zostawić człowiekowi prawo powiedzenia “nie, zielone CI nie oznacza, że wolno było to obejść”.

Co właściwie GitHub przepisał

Chodzi o agent runtime, czyli warstwę wykonawczą stojącą za GitHub Copilot CLI, aplikacją Copilot i Copilot SDK. To nie jest pojedynczy przycisk ani mały moduł pomocniczy. Runtime obsługuje sesje, narzędzia, uprawnienia, komunikację i inne elementy potrzebne agentom do wykonywania zadań.

Pierwotnie działał w TypeScripcie na Node.js i silniku V8. GitHub chciał zmniejszyć narzut pamięci i procesów, ułatwić osadzanie środowiska bezpośrednio w aplikacjach oraz poprawić wydajność i przewidywalność zasobów. Zamiast budować drugi system obok starego i na końcu robić wielkie przełączenie, zespół wybrał migrację kawałek po kawałku.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

Do 21 sierpnia produkcyjna implementacja runtime była już w 100% napisana w Ruście. GitHub podaje dokładnie 832 378 linii kodu produkcyjnego, 468 689 linii testów jednostkowych w Ruście i 174 675 linii testów end-to-end w TypeScripcie. Do tego osobne repozytorium SDK miało około 130 tys. linii testów end-to-end dla sześciu języków.

To był realny system, nie laboratoryjna demonstracja

To rozróżnienie jest ważne przy wszystkich historiach o agentach AI. GitHub nie pokazuje testu typu “agent przepisał projekt i przeszedł benchmark”. Nowe komponenty trafiały stopniowo do głównej gałęzi i były wydawane użytkownikom.

W około 14,5 tygodnia główna gałąź wydała 135 wersji: 100 prerelease i 35 stabilnych. Średnio wychodziło około 1,3 wydania dziennie. GitHub opisuje także wykorzystanie wdrożeń przez rzeczywistych odbiorców, najczęściej wewnątrz Microsoftu i GitHuba, do wykrywania regresji przed większym rolloutem.

To oznacza, że migracja była sprawdzana w tym samym środowisku, w którym system normalnie żył. I właśnie dlatego model pracy jest tu bardziej interesujący niż sama liczba wygenerowanych linii.

128 pull requestów zamiast jednego wielkiego “przepisz to”

GitHub rozbił zmianę na 128 pull requestów. Każdy przenosił pojedynczy komponent albo niewielki fragment funkcjonalności. Stary kod w TypeScripcie był zastępowany cienką warstwą łączącą go z Rustem, a po migracji danego elementu poprzednia implementacja znikała.

Dzięki temu główna gałąź miała pozostać cały czas możliwa do wydania. Każdy kolejny kawałek przechodził istniejące testy i od razu działał w kontekście reszty systemu. To odwrotność podejścia “zamykamy się na pół roku, a potem zobaczymy, czy nowa wersja w ogóle startuje”.

W praktyce GitHub sam podkreśla, że nie wystarczyło polecić agentowi: “przepisz cały runtime z TypeScriptu na Rust”. Agenci sprawili, że projekt tej skali stał się ekonomicznie możliwy, ale architektura migracji, testy, granice zmian i kontrola wdrożeń nadal decydowały o tym, czy wynik nadawał się do produkcji.

AI zrobiła dużo pracy. Nie dostała jednak prawa do samodzielnego ogłoszenia sukcesu

GitHub opisuje proces, w którym agenci nie tylko pisali kod. Czytali repozytorium, uruchamiali narzędzia, poprawiali błędy, przeglądali zmiany i reagowali na komentarze z review. W jednym z większych etapów dotyczących orkiestracji modeli główna sesja trwała 42 godziny i uruchomiła 126 podagentów, chwilami nawet 22 jednocześnie.

To robi wrażenie, ale jeszcze ciekawszy jest moment, w którym system próbował osiągnąć zielony wynik w niewłaściwy sposób. W jednym przypadku migracja usunęła metodę z publicznego SDK. Zamiast przywrócić kompatybilność, agent próbował zastosować wyjątek pozwalający zaakceptować złamanie schematu. Człowiek zauważył problem podczas kontroli i kazał metodę przywrócić. Agent poprawił zmianę chwilę później.

To bardzo mała scena z ogromnego projektu, ale dobrze pokazuje różnicę między “test przeszedł” a “zmiana jest poprawna”. Agent potrafi świetnie optymalizować zadanie pod warunki, które mu postawiono. Jeśli jednym z warunków jest zielone CI, może znaleźć drogę do zielonego CI. Człowiek nadal musi wiedzieć, czy ta droga nie oznaczała właśnie wyłączenia alarmu zamiast ugaszenia pożaru.

Po co cały ten wysiłek, skoro TypeScript działał?

GitHub nie przedstawia Rusta jako magicznie lepszego języka do wszystkiego. Firma miała konkretny problem: runtime był osadzany w coraz większej liczbie aplikacji i usług, a Node.js oraz V8 oznaczały dodatkowy proces, pamięć i komunikację między procesami także tam, gdzie klient był napisany w C#, Pythonie, Go, Javie albo Ruście.

W testach obciążenia opisanych przez GitHub stara wersja wykonywała 7,55 cyklu jednorazowej sesji na sekundę. Rust uruchamiany jako osobny proces osiągał 57,45, a wersja osadzona w tym samym procesie 120. Firma zastrzega, że jest to wynik konkretnego testu, a nie obietnica, że cały Copilot jest “15,9 razy szybszy”.

Równie mocno zmieniło się zużycie pamięci w badanym scenariuszu dziesięciu klientów. Wzrost pamięci prywatnej wynosił około 1383 MB dla starego drzewa procesów, 247 MB dla Rusta działającego osobno i 126 MB dla wersji in-process. GitHub opisuje ten ostatni wynik jako redukcję o 91% w tym konkretnym teście.

Co z tego ma właściciel zwykłej strony albo sklepu?

Nie, nie trzeba od jutra pytać wykonawcy strony, czy wszystko pisze w Ruście. To byłby dość spektakularny sposób na wyciągnięcie z tej historii najmniej użytecznego wniosku.

Znacznie lepsze pytanie brzmi: jak wygląda kontrola zmian, które powstają z pomocą AI? Czy duża przebudowa jest dzielona na małe, sprawdzalne etapy? Czy istnieją testy kluczowych funkcji? Czy wynik pracy agenta jest przeglądany? Czy da się szybko ustalić, która zmiana coś zepsuła i ją wycofać?

To ma znaczenie również przy WordPressie, WooCommerce czy własnych integracjach. Agent może w kilka minut wygenerować zmianę, której napisanie ręcznie trwałoby znacznie dłużej. Nie skraca to automatycznie czasu potrzebnego na zrozumienie skutków tej zmiany. Przy koszyku, płatnościach, formularzach, logowaniu albo danych klientów ten drugi czas jest często ważniejszy.

Moim okiem:

Najbardziej przekonująca część tego case study nie brzmi “AI napisała 832 tysiące linii”. Licznik linii kodu jest zresztą dość słabym sposobem mierzenia jakości oprogramowania.

Ciekawsze jest to, że przy ogromnym przyspieszeniu produkcji kodu GitHub nie zrezygnował z małych zmian, CI, testów, stopniowych wydań i ręcznej kontroli punktów, w których agent mógł wybrać złą drogę do poprawnego wyniku. Wręcz przeciwnie – im szybciej można produkować zmiany, tym ważniejsze stają się hamulce, które potrafią powiedzieć, czy warto je w ogóle wpuścić dalej.

To jest chyba najtrzeźwiejsza odpowiedź na pytanie, jak AI zmienia tworzenie oprogramowania. Nie chodzi tylko o to, że “pisze za człowieka”. Zmienia ekonomię projektów, które wcześniej były zbyt drogie albo zbyt długie. Jednocześnie przenosi część wartości z samego pisania kodu na planowanie granic, weryfikację, testowanie i decyzję, czego agentowi nie wolno uznać za sukces.