Tłumaczenie maszynowe. Przeczytaj angielski oryginał: Agent-written pull requests turn CI into a metered dependency →
Agent może napisać patch, gdy śpisz. To jest ta część, o której wszyscy chcą rozmawiać. Patch nadal wymaga zainstalowania zależności, uruchomienia macierzy testów, zbudowania kontenerów, przechowania artefaktów i zielonego checka, zanim dotknie gałęzi, na której ci zależy. A to wszystko to rozliczane zasoby obliczeniowe.
Rachunek za CI stał się zależnością tworzenia oprogramowania. Znajduje się w pętli sprzężenia zwrotnego między proponowaną zmianą agenta a jego kolejną próbą, gdzie wolne zadanie oznacza bezczynnego agenta, a drogie zadanie oznacza, że maszyna może iterować tylko do momentu, aż ktoś zauważy fakturę.
GitHub już dokumentuje ten mechanizm prostym językiem. W prywatnych repozytoriach przegląd kodu Copilota zużywa minuty GitHub Actions. Każdy z dostępem do zapisu może wywołać Action, a użycie powyżej wliczonego limitu jest obciążane na konto właściciela repozytorium. Pętla agenta po prostu sprawia, że ten licznik działa częściej.
To ma znaczenie dla nas w TextCortex. Budujemy i uruchamiamy workflowy agentowe. Więcej proponowanych zmian oznacza więcej uruchomień testów, więcej przywracań cache i więcej nieudanych prób, które trzeba doprowadzić do zielonego stanu. Stary obraz CI jako ostatniego punktu poboru opłat nie docenia obciążenia. Teraz jest częścią hali produkcyjnej.
Twierdzenie, że agenci piszą więcej testów, nie ma pokrycia w liczbach.
Generowanie kodu może stworzyć mnóstwo kodu testowego. Może też stworzyć patch bez żadnego użytecznego testu albo test, który utrwala błąd implementacji. Nie mam publicznego korpusu, który dowodziłby, że przeciętny agent produkuje więcej testów niż człowiek, i nie będę go fabrykować dla zdania marketingowego.
Wniosek operacyjny przetrwa bez tej statystyki. Każda proponowana zmiana potrzebuje dowodów przed scaleniem. Agent, który potrafi szybko proponować zmiany, zamienia czas trwania CI, jego przepustowość i koszt w ograniczenia tego, jak szybko może się uczyć. To wystarczający powód, żeby przejmować się runnerami.
Runnerhut przedstawia argument za stosunkiem ceny do wydajności w konkretnych liczbach.
Runnerhut to zarządzana usługa runnerów GitHub Actions. Autoryzujesz jego aplikację GitHub, zamieniasz etykietę runs-on w zadaniu i zachowujesz Actions, sekrety i uprawnienia, które już masz w swoim workflow. Jego dokumentacja pokazuje migrację w jednej linii. Zarządzane cache’owanie, trwałe buildery Docker, analityka per workflow i zasoby obliczeniowe hostowane w UE są w zestawie.
Runnerhut publikuje porównanie cen dla 2 vCPU z runnerami hostowanymi przez GitHub. To są ceny z jego cennika z sierpnia 2026 roku. Windows i macOS kosztują połowę stawki runnerów hostowanych przez GitHub. Linux x64 kosztuje połowę ceny, a Linux arm64 jest o 36% tańszy.
| Typ runnera | GitHub-hosted / min | Runnerhut / min | Oszczędzasz |
|---|---|---|---|
| Linux x64 | $0.0080 | $0.0040 | 50% |
| Linux arm64 | $0.0050 | $0.0032 | 36% |
| Windows | $0.0160 | $0.0080 | 50% |
| macOS | $0.0800 | $0.0400 | 50% |
Runnerhut dodaje do tych niższych stawek szybkie starty, przywracanie cache z prędkością 1 GB/s i trwałe buildery Docker. Jego strona produktowa wymienia start runnera w 3 sekundy i dwukrotnie szybsze pipeline’y. Niższe stawki runnerów sprawiają, że każda minuta CI jest tańsza. Szybsze buildy zużywają mniej tych minut już na starcie.
Runnerhut rozlicza też co sekundę po minimalnej pierwszej minucie, bez opłat za cache, egress, czas w kolejce czy współbieżność. Darmowy poziom obejmuje 3000 minut Linux miesięcznie, wystarczająco, żeby przenieść prawdziwy workflow i obserwować liczby, zanim zobowiążesz się do nowego rachunku za CI.
Runnerhut zamienia szybsze CI w mniejszy rachunek.
Cena i czas trwania mnożą się. Runner za połowę stawki za minutę, który kończy pipeline w połowie czasu, obcina wydatki na obliczenia czterokrotnie. Runnerhut optymalizuje przepustowość cache, czas startu runnera i warstwy Docker obok ceny za minutę, bo zielony pipeline znaczy więcej niż tania, wolna minuta.
Usługa zachowuje GitHub Actions w znanej formie. Zainstaluj aplikację GitHub, podmień etykietę runs-on, a akcje, sekrety i uprawnienia zostają dokładnie takie, jakie były. Runnerhut dodaje zarządzane cache, trwałe buildery Docker, analitykę kosztów dla każdego workflow i obliczenia hostowane w UE — bez wciskania do zespołu osobnego produktu CI.
Twoja pętla agentowa potrzebuje CI, które nadąża.
W kumulacji nie ma żadnej magii. Pull request wygenerowany przez agenta wymaga uruchomienia testów. Błąd prowadzi do kolejnej poprawki i kolejnego uruchomienia. Macierz mnoży pracę. Flaky test dodaje ponowne uruchomienie. Rachunek podąża za pętlą, podobnie jak czas między użytecznymi decyzjami.
Niezawodne CI ma nudną robotę: startować przewidywalnie, przywrócić to, czego potrzebuje zadanie, uruchomić ten sam workflow co wczoraj, pokazać koszt i zejść z drogi. Migracja w jednej linii w Runnerhut utrzymuje tę robotę małą. Zespoły mogą ją wypróbować bez przepisywania pipeline’u czy przenoszenia procesu wdrożeniowego na nową płaszczyznę kontroli.
W TextCortex rachunek przemówił za nas. W okresie rozliczeniowym bezpośrednio przed migracją naszych workflow CI do Runnerhut zapłaciliśmy około 3000 € za GitHub Actions.
Runnerhut drastycznie obciął te wydatki i sprawił, że pipeline CI/CD stał się szybszy i łatwiejszy w obsłudze. Runnery startują przewidywalnie, cache pozostaje ciepły, a zespół widzi, ile kosztuje każdy workflow, zamiast traktować rachunek za CI jako miesięczną niespodziankę.
Rozwój agentowy będzie dalej zwiększać ilość pracy nad kodem i testami przepływającej przez CI. Runnerhut daje temu obciążeniu proste miejsce: ten sam workflow GitHub Actions, szybsze runnery, niższe stawki za obliczenia i rachunek, który pozostaje czytelny w miarę wzrostu liczby zadań.
Dlatego przenieśliśmy TextCortex. CI stało się infrastrukturą produkcyjną dla naszych agentów. Runnerhut uczynił je tańszym i szybszym, nie zamieniając migracji w kolejny projekt inżynieryjny.