Daniel Stenberg, główny twórca i opiekun projektu cURL, którego narzędzia używa praktycznie cały internet, podjął w styczniu 2026 roku bolesną decyzję. Zakończył trwający od lat program nagród za zgłaszanie błędów, który został zamknięty pod koniec stycznia 2026 roku. Mitchell Hashimoto, współzałożyciel HashiCorp, wprowadził w swoim nowym projekcie Ghostty całkowity zakaz kodu generowanego przez AI. Steve Ruiz poszedł jeszcze dalej: w jego bibliotece tldraw wszystkie zewnętrzne prośby o włączenie kodu (pull requests) są teraz zamykane automatycznie.
To nie są odosobnione przypadki zgorzkniałych programistów. To desperackie reakcje obrońców twierdzy, której fundamenty – oparte na współpracy, uznaniu i wspólnym wysiłku – są systematycznie podmywane przez nową falę. Falę, którą niektórzy analitycy nazywają „AI Slopageddon” – prawdziwe apokalipsy AI-owego „szmelcu”. U jej źródła leży zjawisko zwane „vibe coding”.
Czym jest "vibe coding" i dlaczego to nie tylko "lenistwo"?
„Vibe coding” to potoczny termin na praktykę, w której deweloperzy wykorzystują asystentów AI (agenty) do automatycznego wybierania, łączenia i implementowania gotowych pakietów open source. Brzmi efektywnie? W teorii tak. Problem leży w tym, co w tym procesie zostaje pominięte.
Klasyczny model open source opierał się na pętli sprzężenia zwrotnego: programista, chcąc użyć biblioteki, (1) czytał dokumentację, (2) napotykał problem i zgłaszał buga lub (3) miał pytanie i wpisywał je na Stack Overflow. W ten sposób opiekun projektu (maintainer) otrzymywał bezcenne sygnały: widział, że jego praca jest używana, mógł poprawiać błędy, a przez to zyskiwał reputację, co często przekładało się na oferty pracy, kontrakty konsultingowe czy darowizny.
„Vibe coding” tę pętlę zrywa. AI wybiera pakiet, AI go implementuje, a developer nawet nie wie, jakiej biblioteki użył. Nie odwiedzi strony dokumentacji, nie zgłosi błędnie sformułowanego komunikatu o błędzie. Z punktu widzenia maintainera, jego projekt nagle stał się niewidzialny, mimo że jest używany częściej niż kiedykolwiek.
„AI slop prowadzi atak DDoS na opiekunów open source, a platformy hostingujące projekty nie mają żadnej motywacji, żeby to powstrzymać. Wręcz przeciwnie, są zmotywowane, żeby napompować statystyki AI-generowanych kontrybucji, żeby pokazać ‘wartość’ swoim akcjonariuszom” – mówi Stefan Prodan, główny opiekun projektu Flux CD.
Ekonomia niewidzialnego zużycia: błędne koło
Analizy ekonomiczne tego zjawiska pokazują samonapędzające się błędne koło.
Z jednej strony, AI obniża koszty tworzenia oprogramowania, co teoretycznie powinno zachęcić więcej osób do publikowania swoich pakietów (wzrost podaży). Jednak kluczowy jest przesunięcie popytu. Użytkownicy, dzięki AI, omijają bezpośrednią interakcję z projektem. To zmniejsza wszystkie tradycyjne motywacje maintainera: mniej odsłon dokumentacji, mniej zgłoszeń błędów, mniej rozpoznawalności w społeczności.
W efekcie, utrzymywanie projektu, które już wcześniej było często czynnością charytatywną, staje się jeszcze mniej opłacalne. Twórcy się wypalają i porzucają projekty. W dłuższej perspektywie, jeśli ten efekt „przesunięcia popytu” będzie dominujący, runie cała środkowa półka ekosystemu. Przetrwają tylko giganty (jak Linux, React) z silnym sponsoringiem oraz maleńkie, niszowe skrypty. Zniknie cała warstwa wartościowych, dojrzałych, ale mniej popularnych bibliotek, które są kręgosłupem nowoczesnego rozwoju.
Indywidualna, krótkoterminowa wygoda programisty, który nie chce „marnować czasu” na czytanie dokumentacji, prowadzi do długoterminowego spadku ogólnej dostępności i jakości oprogramowania dla wszystkich – podsumowują analitycy.
Dowody w działaniu: liczby, które nie kłamią
Trend jest już wyraźnie widoczny w danych:
- Stack Overflow odnotował spadek liczby pytań po premierze ChatGPT. Pytania przeniosły się do prywatnych czatów z AI.
- Tailwind CSS, popularny framework CSS, notuje rosnącą liczbę pobrań, ale jednocześnie spadek ruchu w dokumentacji i przychodów komercyjnych. Użycie rośnie, ale twórcy nie odnoszą z tego żadnych korzyści.
- W przypadku cURL, decyzja Daniela Stenberga przyszła, gdy program bug bounty został zalany niskiej jakości zgłoszeniami, w tym generowanymi przez AI. Po wypłaceniu ponad 90 000 dolarów nagród za 81 luk, stało się to po prostu nieopłacalne.
Platformy, zamiast pomagać, często problem pogłębiają. GitHub uruchomił funkcję Copilot Issue Generation, która automatycznie tworzy zgłoszenia problemów z kodu. Nie dał jednak maintainerom żadnych narzędzi do filtrowania tych generowanych przez AI, zalewając ich skrzynki jeszcze większą ilością „szumu”.
Reakcje obronne: od zero tolerancji po całkowitą izolację
Opiekunowie nie są bierni. Ich reakcje układają się w spektrum od stanowczych po radykalne.
Mitchell Hashimoto (Ghostty) wprowadził politykę „zero tolerancji”. „To nie jest stanowisko anty-AI. To stanowisko anty-idiotyczne” – tłumaczy. „Ghostty jest pisany z dużą pomocą AI i wielu naszych opiekunów używa AI na co dzień. Po prostu chcemy jakościowych kontrybucji, niezależnie od tego, jak są tworzone”. Za złamanie zakazu grozi permanentny ban.
Steve Ruiz (tldraw) doszedł do jeszcze bardziej fundamentalnego wniosku. Zdał sobie sprawę, że jego własne skrypty AI generują kiepsko sformułowane zgłoszenia, które następnie ludzie wklejają do swoich narzędzi AI, by te – bazując na błędnych założeniach – tworzyły bezużyteczne prośby o włączenie kodu. Jego decyzja? Całkowite zamknięcie projektu na zewnętrzne kontrybucje. „Jeśli napisanie kodu jest łatwą częścią, to dlaczego miałbym chcieć, żeby pisał go ktoś inny?” – pyta retorycznie.
Craig McLuckie*, współzałożyciel Stacklok, opisuje jak zmienił się świat: „Kiedyś oznaczenie czegoś jako ‘good first issue’ (dobry pierwszy problem) przyciągało inżynierów, którzy potem rośli w stałych współtwórców. Teraz… w ciągu 24 godzin jesteśmy absolutnie zalewani niskiej jakości ‘szmelcem’ z vibe codingu, który tylko odbiera nam czas od prawdziwej pracy”.
Czy jest jakieś wyjście? Model Spotify i ślepe uliczki
Niektórzy proponują ekonomiczne rozwiązanie: „model Spotify” dla open source. Platformy AI (jak GitHub z Copilotem) pobierałyby opłaty subskrypcyjne, a następnie redystrybuowałyby je do autorów bibliotek na podstawie faktycznego użycia przez AI. To teoretycznie sprawiedliwe.
Jednak obliczenia pokazują skalę wyzwania: aby utrzymać dotychczasowy poziom motywacji dla maintainerów, użytkownicy „vibe coding” musieliby generować dla nich znaczną część wartości, jaką generują dziś tradycyjni, zaangażowani użytkownicy. To próg trudny do osiągnięcia.
Tymczasem duże organizacje open source skupiają się na innych aspektach. Fundacja Linuxa zajmuje się zgodnością licencji. Fundacja Apache zaleca dodawanie do kodu znacznika „Generated-by:”. Żadne z tych rozwiązań nie pomaga w faktycznym odsianiu potopu niskiej jakości treści. Niektóre projekty poszły na całość i po prostu zakazały wszystkich kontrybucji generowanych przez AI. Ale jak zauważają niektórzy, wykrywanie naruszeń tego zakazu za rok czy dwa stanie się funkcjonalnie niemożliwe.
Szerszy kontekst: erozja kompetencji i pogoń za dokumentacją
Kryzys w open source nie jest odosobniony. To część większej układanki, w której poświęcamy długoterminową biegłość dla krótkoterminowej wydajności.
Badania z udziałem inżynierów pokazują, że ci, którzy intensywnie korzystają z asystentów AI, mogą zdobywać mniej punktów na testach rozumienia kodu. Ci, którzy całkowicie delegują zadania, osiągają gorsze wyniki, podczas gdy ci, którzy używają AI konceptualnie, angażując swój mózg – lepsze. Jak komentował jeden z ekspertów: „Wymieniasz uczenie się i erozję kompetencji na zastrzyk produktywności, który nie zawsze tam jest”.
Równolegle giganty technologiczne pracują nad serwerami MCP (Model Context Protocol), które mają zapewnić AI agentom dostęp do aktualnej, oficjalnej dokumentacji w czasie rzeczywistym. To wyścig zbrojeń: AI popełnia błędy, bo trenuje na nieaktualnych danych, więc firmy próbują jej te dane dostarczyć. To jednak nie rozwiązuje problemu odcięcia maintainera od użytkownika.
Podsumowanie: co tracimy, gdy znikają maintainerzy
Ostatecznie, zagrożenie nie dotyczy tylko dzisiejszych popularnych bibliotek. Te pewnie sobie poradzą. Niebezpieczeństwo jest głębsze i bardziej subtelne.
„Popularne biblioteki wciąż znajdą sponsorów” – mówi Miklós Koren, współautor badania. „Mniejsze, niszowe projekty są bardziej narażone. Ale pamiętajmy, że wiele dziś sukcesywnych projektów, jak Linux, git, TeX czy grep, zaczynało się od jednej osoby, która chciała podrapać swój własny świąd. Jeśli opiekunowie małych projektów się poddadzą, kto stworzy następnego Linuxa?”.
W tej chwili maintainerzy jak Stenberg, Hashimoto i Ruiz odpowiadają na to pytanie w jeden sposób: zamykając drzwi swojego projektu, jeden po drugim. Bronią resztek swojej produktywności i zdrowia psychicznego przed „AI Slopageddon”. A społeczność programistów, choć może tego jeszcze nie widzieć, już traci coś bezcennego: przyszły fundament, na którym miał stanąć kolejny przełomowy projekt.
Dodaj komentarz