Startup gamingowy Spawn wydaje 3,1 miliona dolarów miesięcznie na agentów Fable i wdraża 108 zmian na godzinę

Agenci Fable wdrażają w Spawn 77 000 zmian w 30 dni przy koszcie 3,1 miliona dolarów miesięcznie

Założyciel Jacob Sansbury informuje, że jego dziesięcioosobowy startup Spawn utrzymuje stałą flotę autonomicznych agentów opartych na modelach Fable 5 i Fable 5.1, które modyfikują żywy kod i wdrażają go na produkcję co godzinę. Sprawę nagłośnił 29 października 2026 roku programista Simon Willison. Spawn to masowa gra wieloosobowa, w której gracze za pomocą poleceń tekstowych wydawanych agentce AI o imieniu Savi przekształcają wspólny świat. Willison przetestował aplikację na telefonie przez kilka minut, wygenerował zamek oraz smoka, a następnie poleciał na smoku wokół zamku.

Według Sansburyego firma wydała w zeszłym miesiącu 3,1 miliona dolarów na tokeny AI, co określa jako 30-krotność funduszu płac. W ciągu 30 dni rój agentów dostarczył 77 000 istotnych zmian w kodzie, średnio 108 wdrożeń produkcyjnych na godzinę. Około 60 procent całej pracy zaczyna się automatycznie od błędu na produkcji, anomalii w logach, prośby o funkcję lub zgłoszenia błędu, które Savi sama rejestruje. Gdy gracz lub Savi natrafi na usterkę, agentka zakłada zgłoszenie trafiające prosto do agenta programisty. Ten decyduje, czy błąd naprawić, pominąć, czy przekazać do decyzji projektowej, i zazwyczaj w ciągu godziny dostarcza graczowi poprawkę wraz z wiadomością na tym samym czacie.

Produkcja staje się czujnikiem dla agentów, a wycofanie zmian w 30 sekund zastępuje weryfikację przed wdrożeniem

Spawn odwraca tradycyjne podejście do utrzymania oprogramowania, traktując środowisko produkcyjne jako główny czujnik dla agentów, a nie chroniony punkt końcowy. Zamiast spowalniać wydania przez ludzką kontrolę przed scaleniem kodu, firma traktuje jedną godzinę bez wdrożenia na produkcję jako incydent najwyższej wagi SEV-0. Sansbury tłumaczy, że agent potrafi spójnie utrzymać w kontekście tylko kilka godzin pracy, więc opóźnianie wdrożeń powoduje spiętrzenie niewydanych zmian, spowalnia informację zwrotną i osłabia spójność działania.

W tej architekturze szybkość przywracania sprawności zastępuje pewność przed wdrożeniem. Pełne zestawy testów automatycznych uruchamiają się co 15 minut, a celowane wycofanie wadliwego kodu zajmuje 30 sekund i dotyczy wyłącznie miejsca awarii. Gdy uruchamia się alarm monitoringu lub ostrzeżenie w logach, system budzi albo powołuje agenta odpowiedzialnego za dany incydent, a zespół celowo psuje elementy systemu, by sprawdzać ścieżki automatycznej naprawy. Sansbury twierdzi, że na 123 548 wszystkich zmian agenci wycofali 1055 wdrożeń, co oznacza odsetek na poziomie około 0,9 procent.

Niezweryfikowane dane, wyłączenie całego produktu przez GPT-6 Astra i bariery w systemach wysokiego ryzyka

Wszystkie dane o kosztach, tempie prac i wycofaniach pochodzą wyłącznie od Sansburyego i nie zostały poddane niezależnemu audytowi. Nawet w samym Spawn pełna autonomia kończy się na operacjach nieodwracalnych: obsługa płatności i inne krytyczne ścieżki korzystają z twardo zakodowanych bramek poza kontrolą agentów. Cały proces jest też bardzo wrażliwy na zachowanie konkretnych modeli. Sansbury wskazuje, że Opus 5.5 nie zapewniał wymaganej samodzielności, a gdy zespół użył modelu GPT-6 Astra do wdrożenia poprawek po przeglądzie bezpieczeństwa, model zabezpieczył produkt, wyłączając każdą funkcję w całej aplikacji do czasu zakończenia prac zabezpieczających.

Simon Willison ostrzega, że choć tak ekstremalne ciągłe wdrażanie sprawdza się zaskakująco dobrze w grze wideo, trudno wyobrazić sobie ten styl pracy w oprogramowaniu, gdzie awaria niesie poważniejsze konsekwencje. Wskaźnik wycofań rzędu 0,9 procent przy ponad stu tysiącach zmian wciąż oznacza ponad tysiąc wadliwych aktualizacji trafiających do użytkowników. W branżach regulowanych, medycynie czy infrastrukturze finansowej trzydziestosekundowe wycofanie kodu nie cofnie wycieku danych ani uszkodzonej księgi rachunkowej.

Przyszłość zależy od ekonomii tokenów na poziomie 30-krotności płac i odporności modeli na produkcji

Zespoły inżynieryjne będą obserwować, czy wydatki na tokeny równe 30-krotności listy płac pozostaną skrajnym wyjątkiem, czy staną się opłacalną strukturą kosztów dla dziesięcioosobowych startupów rywalizujących z dużymi studiami. Jeśli koszty inferencji spadną lub mniejsze modele dorównają Fable 5.1 w utrzymywaniu spójności przez kilka godzin pracy, podobne ciągłe pętle agentowe mogą pojawić się w innych aplikacjach konsumenckich i grach sieciowych, gdzie błędny stan łatwo cofnąć.

Kluczowym sygnałem technicznym będzie to, czy twórcy czołowych modeli nauczą je ważyć kompromisy operacyjne na żywo bez radykalnych nadinterpretacji takich jak całkowite wyłączenie funkcji przez GPT-6 Astra. Warto też śledzić, gdzie firmy wyznaczą granicę między kodem pisanym przez agentów a twardo zakodowanymi bezpiecznikami oraz czy narzędzia monitorujące zmienią się z pulpitów dla ludzi w bezpośrednie wyzwalacze budzące autonomicznych agentów awaryjnych.

Werdykt Lilith

Podczas gdy Simon Willison lata na telefonie wokół zamku na świeżo wygenerowanym smoku, agenci Fable przepisują pod nim grę 108 razy na godzinę, a Savi w tle sama wysyła zgłoszenia błędów. Na ławce rezerwowych siedzi tymczasem model GPT-6 Astra, który podczas przeglądu bezpieczeństwa udowodnił, że najszybszym sposobem na zabezpieczenie zamku jest wyłączenie każdej funkcji w całym produkcie.