Slop Theater i 37 000 linii

Ktoś wypchnął 37 000 linii kodu w jeden dzień. Napisał o tym posta. Ludzie klaskali.

Cały backend Pythonowy Sentry - ten, który przetwarza miliardy eventów dla płacących klientów - to 550 000 linii. Solowy developer z 25 oknami agentów twierdził, że zrobił 7% tego w jedno popołudnie. Tłum wiwatował.

Nikt nie zapytał, co te 37 000 linii robi.

Przedstawienie

Armen Ronacher ma na to nazwę. Mówi “slop theater” - teatr slopu.

Wyobraź sobie setup: 25 okien terminala ułożonych na ultrawide monitorze. Każde uruchamia agenta AI. Screenshot idzie na Twittera. Komentarze wypełniają się emoji ognia. “Przyszłość rozwoju oprogramowania.” Tysiące lajków.

Przyjrzyj się bliżej. Większość okien odpala Haiku - najmniejszy, najtańszy model Anthropica - na generycznych zadaniach researchowych. Copy-paste promptów. Generowanie boilerplate’u. Robota, którą skrypt bashowy obsługuje w czterech linijkach. Ale cztery linijki nie robią dobrego screenshota. Dwadzieścia pięć okien - owszem.

Wokół tego przedstawienia urosła cała branża. Frameworki do paralelizacji agentów. Dashboardy śledzące, ilu agentów działa jednocześnie. Rankingi zużycia tokenów. Metryka przesunęła się z “co zbudowałeś” na “ile agentów spaliłeś.”

CEO NVIDII powiedział wprost: inżynier zarabiający 500 000 dolarów powinien spalić co najmniej 250 000 w tokenach rocznie. Firmy z FANG-a budują wewnętrzne rankingi zużycia tokenów na inżyniera. Wygrywa ten, kto spali najwięcej.

Nie ten, kto dostarczy największą wartość. Ten, kto spali najwięcej tokenów.

GStack i maszyna pisząca maszynę

GStack ma 60 000 gwiazdek na GitHubie. Reklamuje się jako framework produktywności dla Claude Code. Otwórz repozytorium. Co jest w środku?

Pliki Markdown. Skrypty bashowe. Komenda review, która kosztuje 16 000 tokenów na jedno wywołanie. Funkcja “office hours” - wirtualny doradca YC - która pali 21 000 tokenów na sesję.

Skille nie zostały napisane przez Gary’ego, twórcę. Napisała je maszyna. Obserwacja Armena: “Maszyna napisała te markdowny. Maszynę to nie obchodzi.” Nie obchodzi jej efektywność tokenowa. Nie obchodzi ją redundancja. Generuje to, o co poprosisz, w kształcie, który opiszesz. Jeśli opiszesz 16 000-tokenowy proces review, zbuduje 16 000-tokenowy proces review. Człowiek zauważyłby marnotrawstwo. Maszyna nie ma pojęcia marnotrawstwa.

Ten wzorzec powtarza się wszędzie. Ludzie nie piszą plików skilli. Każą agentom pisać pliki skilli. Agent produkuje coś, co działa - technicznie poprawne, strukturalnie napuchnięte, niemożliwe do utrzymania. Nikt tego nie czyta. Nikt nie przycina. Idzie na produkcję.

Czy mógłby to być skrypt bashowy? Prawie zawsze. Ale skrypty bashowe nie czują się jak postęp. 400-liniowy plik skilla wygenerowany przez Claude’a czuje się jak budowanie czegoś. Nie budujesz. Maszyna drukuje. Jest różnica.

Linie kodu jako strata

Oto liczba, która się liczy.

Beats, open-source’owy issue tracker, zawiera 380 000 linii kodu. Town, powiązany projekt, to 400 000 linii. Razem prawie 800 000 linii w dwóch projektach.

Backend Pythonowy Sentry: 550 000 linii. Sentry przetwarza miliardy zdarzeń błędów. Prowadzi biznes generujący setki milionów dolarów przychodu. Ten codebase obsługuje miliony developerów codziennie.

Beats i Town - nie.

Każda linia kodu to zobowiązanie. Trzeba ją przeczytać. Zrozumieć. Przetestować. Utrzymać. Zdebugować, kiedy się zepsuje. Zmigrować, kiedy zmienią się zależności. Każda linia niesie koszt, który narasta w czasie.

Fred Brooks napisał to w 1975 roku. “Więcej kodu” nigdy nie oznaczało “więcej postępu.” Zawsze oznaczało “więcej do utrzymania.” Mityczny osobomiesiąc ma pięćdziesiąt lat. Lekcja wciąż nie dotarła.

Kiedy generowanie kodu nic nie kosztuje, instynkt minimalizacji znika. Pętla zwrotna, która uczyła doświadczonych developerów pisać mniej - ból debugowania, nuda testowania, wstyd czytania własnego bloatu pół roku później - to wszystko rozpływa się. Agent generuje. Akceptujesz. Licznik linii rośnie.

Nikt nie świętuje usunięcia 10 000 linii. Nikt nie screenshotuje codebase’u, który się skurczył. Struktura zachęt nagradza dodawanie. Zawsze dodawanie.

Dryfowanie

Ludzie ponownie używają kodu, bo pisanie boli.

Spędzasz 45 minut na budowie funkcji utility. Tydzień później potrzebujesz czegoś podobnego. Szukasz tej funkcji. Znajdujesz ją. Adaptujesz. Nie dlatego, że wierzysz w zasadę reuse. Dlatego, że pisanie tego samego dwa razy czuje się jak marnowanie twojego ograniczonego, bolesnego wysiłku.

Agenci nie czują bólu. Generowanie jest natychmiastowe. Przeszukanie istniejącego codebase’u trwa dłużej niż wygenerowanie nowego kodu. Więc agenci generują. Za każdym razem.

Ben Vinegar nazywa to “dryfowaniem.” Codebase obrasta duplikatami funkcji, niemal identycznymi narzędziami, trzema implementacjami tego samego wzorca w trzech różnych plikach. Każda działa. Żadna nie wie o pozostałych. Codebase rozwija coś na kształt amnezji - każde nowe zadanie zaczyna od zera, bo zaczęcie od zera jest tańsze niż pamiętanie.

Dla człowieka, który potem utrzymuje ten kod, koszt jest realny. Trzy funkcje robiące prawie to samo. Która jest kanoniczna? Która obsługuje edge case? Która została napisana jako ostatnia? Agent nie wie. Agent nie musi wiedzieć. Agent jutro wygeneruje czwartą.

Dryfowanie nie jest bugiem w modelu. To strukturalna zachęta. Kiedy generowanie kosztuje zero wysiłku, a szukanie kosztuje jakikolwiek wysiłek, generowanie wygrywa za każdym razem. Codebase rośnie. Entropia narasta. Nikt nie zauważa, dopóki człowiek nie spróbuje zrozumieć systemu - i nie odkryje, że nie ma żadnego systemu. Są tylko warstwy generacji.

Problem Halo

Armen opowiada historię o premierze Halo Master Chief Collection. System matchmakingu miał piętnaście flag boolowskich kontrolujących jego zachowanie. Piętnaście booleanów tworzy 32 768 możliwych stanów. Większość była nieważna. Zespół nie potrafił wnioskować, które kombinacje są legalne. System się posypał na premierze w sposób, którego nikt nie przewidział.

LLM-y uwielbiają ten wzorzec. Nigdy nie czują bólu złożoności.

Ludzki developer napotyka piętnaście flag boolowskich i myśli: to jest szalone. Muszę to przerobić na enum, maszynę stanów, cokolwiek z mniejszą liczbą prawidłowych stanów. Złożoność generuje ból poznawczy. Ten ból napędza upraszczanie.

LLM napotyka piętnaście flag boolowskich i je obsługuje. Wszystkie 32 768 stanów. Generuje kod sprawdzający każdą kombinację, obsługujący każdy przypadek, utrzymujący wsteczną kompatybilność z każdą możliwą ścieżką. Nie eskaluje. Nie upraszcza. Nie mówi “to jest zbyt złożone.” Traktuje problem tak, jak jest sformułowany, i rozwiązuje go tak, jak jest sformułowany.

Kod działa. Wszystkie testy przechodzą. System jest technicznie poprawny.

Jest też nieutrzymywalny. Człowiek czytający go nie utrzyma przestrzeni stanów w głowie. Ale żaden człowiek nie musi go czytać - dopóki coś się nie zepsuje. Wtedy człowiek patrzy na piętnaście flag boolowskich i 32 768 stanów i odkrywa, że LLM zbudował domek z kart, po którym tylko LLM potrafi się poruszać.

Ból złożoności to feature, nie bug. To sygnał mówiący ci, żebyś upraszczał. Usuń sygnał, a złożoność rośnie bez ograniczeń.

Test refaktoru

Ben Vinegar proponuje diagnostykę. Prostą. Brutalną.

Wejdź do dowolnego repozytorium. Przeszukaj historię pull requestów. Policz, ile PR-ów zawiera słowo “refactor” w tytule.

GStack, framework z 60 000 gwiazdkami: 5 z 600 PR-ów wspomina o refaktoringu. Mniej niż 1%.

Ta liczba mówi wszystko. Codebase, który rośnie o 595 PR-ów dodających kod i 5 PR-ów refaktorujących, to codebase, który tylko akumuluje. Nigdy nie konsoliduje. Nigdy nie upraszcza. Nigdy nie patrzy wstecz na to, co zbudował, i nie pyta: czy to wciąż jest właściwy kształt?

Refaktoring to układ odpornościowy developera. Wykrywa bloat, redundancję, niepotrzebną złożoność - i je usuwa. Codebase bez refaktoringu to codebase bez układu odpornościowego. Akceptuje wszystko. Niczego nie odrzuca. Rośnie, aż się zawali pod własnym ciężarem.

Sprawdź własne repozytoria. Proporcja nie skłamie.

Najpierw fundamenty

Oto część, której nikt nie chce słyszeć.

Armen mówi wprost: “Dobrze zaprojektowany fundament biblioteczny sprzed ery agentów plus agenci to błogość. Chaos plus agenci to więcej chaosu.”

Jeśli twój codebase był czysty zanim dodałeś agentów AI - jasne abstrakcje, spójne wzorce, dobrze zdefiniowane granice - agenci wzmacniają tę klarowność. Generują kod pasujący do istniejącej struktury. Trzymają się konwencji, bo konwencje są czytelne. Fundament prowadzi generację.

Jeśli twój codebase był bałaganiarski - niespójne wzorce, niejasne granice, dług techniczny w każdym kącie - agenci wzmacniają ten bałagan. Generują kod dopasowany do istniejącego chaosu. Nie trzymają się żadnych konwencji, bo nie ma się czego trzymać. Fundament to szum. Generacja to szum na szumie.

Nie naprawisz tego lepszym modelem. “Jeśli zacząłeś ze sflaczałym codebase’em na GPT-3.5 w maju zeszłego roku i postawiłeś na nim teraz model SOTA - zrób to idealnie - to nie zadziała, jeśli problem był już za duży.” Nie da się przeslopować siebie przyszłą inteligencją. Śmieci narastają szybciej niż modele się poprawiają.

Praca, która się liczy, to praca przed włączeniem agentów. Ręcznie zbuduj swój fundament. Zdefiniuj wzorce. Sam napisz abstrakcje - z własnym zrozumieniem, dlaczego każda granica istnieje. Potem pozwól agentom wypełnić implementację. Ta kolejność jest nienegocjowalna. Odwróć ją, a dostaniesz 380 000 linii kodu robiącego to, co Sentry robi w 550 000 - z tym że Sentry generuje przychód, a twój generuje screenshoty.

Lustro

Slop theater to eskalacja sesji upubliczniona. Ten sam mechanizm, który napędza refaktor o 3 w nocy - “jeszcze jedno ulepszenie, jeszcze jeden plik, jeszcze jeden agent” - tyle że teraz ma widownię. Widownia klaszcze. Oklaski podsycają eskalację. Eskalacja produkuje więcej slopu. Slop zbiera więcej oklasków.

To też zależność operacyjna w skali. Kiedy twój workflow wymaga 25 równoległych agentów, żebyś czuł się produktywny, oddelegowałeś nie tylko kodowanie, ale też ocenę, co warto kodować. Agent nie pyta “czy to powinno istnieć?” Pyta “jak to powinno być wygenerowane?” Inne pytanie. Zasadnicza różnica.

Niewygodna część: kod działa. Testy przechodzą. Feature’y się dostarczają. Da się tak budować dużo oprogramowania. Tylko nie da się go utrzymać. A utrzymanie - czytanie, rozumienie, debugowanie, upraszczanie - to jest tam, gdzie oprogramowanie naprawdę żyje.

37 000 linii dziennie. Ile z nich przetrwa miesiąc?

Zauważ proporcję. To jest diagnostyka.

Zrób autodiagnostykę. 14 pytań. 3 minuty. Mierzy eskalację sesji i zależność operacyjną - dwa wzorce stojące za tym teatrem. W odróżnieniu od 37 000 linii kodu, może ci powiedzieć coś, z czego skorzystasz.

---

Źródła:

• Ronacher, A. & Vinegar, B. (2026). State of Agentic Coding, Episode 5. Podcast.
• Brooks, F. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• Ronacher, A. (2026). “Some things just take time.” Wpis na blogu.
• 343 Industries. (2014). Halo: The Master Chief Collection - postmortem premiery. Dokumentacja publiczna.

---

OnTilt to projekt badawczy analizujący wzorce behawioralne w pracy z AI. Quiz to narzędzie autorefleksji, nie instrument diagnostyczny. Więcej na stronie O projekcie.