Kategoria: AI i Technologia

  • Twórca OpenClaw o „vibe coding”: To obelga, która deprecjonuje umiejętność

    Twórca OpenClaw o „vibe coding”: To obelga, która deprecjonuje umiejętność

    Peter Steinberger, programista, który w swoim wiedeńskim salonie stworzył jeden z najszybciej rozwijających się projektów open source na GitHubie, ma dosyć jednego terminu. Chodzi o „vibe coding”, czyli intuicyjne promptowanie modeli AI do generowania kodu. Dla niego to „obelga”, która ma sprawiać, że programowanie z pomocą sztucznej inteligencji brzmi banalnie łatwo. Jego słowa nabierają szczególnej wagi, bo właśnie został gwiazdowym nabytkiem OpenAI. To opowieść o tym, jak pewien developer, wydający 20 tysięcy dolarów miesięcznie z własnej kieszeni, przekonał do siebie szefów największych firm technologicznych świata.

    Czym jest OpenClaw i jak podbił GitHub?

    Historia projektu, który pierwotnie nazywał się Clawdbot (nawiązanie do Claude’a Code), a potem Moltbot, to gotowy materiał na film. W ciągu niecałych trzech miesięcy zdobył niemal 196 tysięcy gwiazdek na GitHubie, stając się najszybciej rosnącym repozytorium open source. Do rozwoju przyczyniło się ponad 600 współtwórców i ponad 10 tysięcy commitów.

    To nie był jednak spokojny rozwój. Projekt przetrwał spór o znak towarowy, ataki crypto scammerów, którzy przejęli repozytorium, a także poważną lukę bezpieczeństwa umożliwiającą zdalne wykonanie kodu. Tuż przed ogłoszeniem zatrudnienia Steinbergera, luka została załatana ponad 40 poprawkami. Sam Steinberger budował OpenClaw, uruchamiając jednocześnie od 4 do 10 agentów AI do kodowania. W samym styczniu 2026 roku nagromadził 6600 commitów, nazywając siebie „największym nieopłacanym promotorem Codexa”.

    „Vibe coding” to słowo na „L”? Kontrowersje wokół terminu

    Termin „vibe coding” spopularyzował Andrej Karpathy, były szef AI w Tesli. Jednak, jak przyznaje sam Karpathy, przyszłość należy do „inżynierii agentycznej” (agentic engineering). To właśnie to określenie preferuje Steinberger.

    • Dlaczego „vibe coding” jest tak problematyczne? W podcaście OpenAI „Builders Unscripted” Steinberger wyjaśnił, że termin ten jest używany przez tradycjonalistów do deprecjonowania nowego podejścia. „Są ludzie, którzy piszą oprogramowanie w stary sposób, a stary sposób odejdzie. Nazywają to 'vibe coding’. Myślę, że 'vibe coding’ to obelga” – stwierdził.

    Jego zdaniem, słowo to implikuje, że chodzi o bezmyślne „wibrowanie” z maszyną, a nie o prawdziwą umiejętność. „Nie rozumieją, że to jest umiejętność” – podkreślił, porównując kodowanie z AI do nauki gry na gitarze. Na początku wydaje się trudne, ale z czasem i praktyką staje się drugą naturą. Steinberger posunął się nawet do tego, że – jak przyznał w rozmowie – wysyła do produkcji kod wygenerowany przez AI, nawet go nie czytając. „Większość kodu jest nudna” – uzasadnił, dodając, że ma już dobre wyczucie tego, co model napisze.

    Do krytyki terminu przyłączył się też Andrew Ng, były naukowiec Google Brain, nazywając go „niefortunnym” i „mylącym”. Paradoksalnie, w 2025 roku słowo „vibe coding” trafiło do słownika Collinsa jako „słowo roku”.

    Wojny o agentów: Zuckerberg vs. Altman, Google vs. cały świat

    Sukces OpenClawa nie uszedł uwadze największych graczy. Steinberger przyznał, że kontaktowali się z nim przedstawiciele wszystkich czołowych laboratoriów AI. Meta – gdzie Mark Zuckerberg osobiście dzielił się swoimi doświadczeniami z testowania projektu – złożyła mu ofertę pracy. Również OpenAI z Samem Altmanem na czele chciało go zatrudnić.

    • Dlaczego wybrał OpenAI? Steinberger wskazał na misję. Altman, nazywając go „geniuszem z mnóstwem niesamowitych pomysłów na przyszłość bardzo inteligentnych agentów”, przekonał go wizją rozwoju. 15 lutego 2026 roku ogłoszono, że Steinberger dołącza do OpenAI, by prowadzić rozwój „agentów osobistych nowej generacji”. Samo OpenClaw przeszło pod skrzydła niezależnej fundacji i pozostaje open source.

    Ciekawsze były reakcje innych firm na sam projekt. Podczas gdy OpenAI zatrudniło twórcę, a Anthropic uprzejmie prosiło o zmiany i aktualizowało regulamin, Google przyjął twardą linię.

    FirmaStanowisko wobec użytkowników OpenClawSzczegóły
    GoogleBanuje konta bez zwrotów (Antigravity)Fala banów 12-23.02.2026; Steinberger wycofał wsparcie 23 lutego
    AnthropicUpominki, bezpośredni kontakt z twórcąKoniec stycznia fingerprinting; 20 lutego zakaz OAuth w TOS
    OpenAIZatrudnia twórcę, nie banuje użytkownikówOgłoszenie zatrudnienia 15 lutego

    Steinberger skomentował to krótko: zakazy Google’a były „dość drakońskie”. „Nawet Anthropic do mnie pisze i miło załatwia sprawy. Google po prostu banuje” – stwierdził.

    Bezpieczeństwo, sceptycy i nowa norma

    Szybki sukces OpenClawa budzi też obawy. Na forach takich jak Hacker News dyskutanci zwracali uwagę na historię projektu: niewspółosiowość agentów, włamania i oszustwa, które miały miejsce podczas jego używania. Dla niektórych zatrudnienie Steinbergera przez OpenAI, firmę deklarującą priorytet bezpieczeństwa, stanowiło pewną sprzeczność.

    Jednocześnie nie sposób nie docenić rozmachu. Projekt w dużej mierze zbudowany przez AI, rozwijany przez społeczność, który przetrwał kryzysy, stał się symbolem zmiany. Jak zauważyli komentatorzy, taka ścieżka rozwoju – od pomysłu jednej osoby do globalnego fenomenu przy wsparciu agentów AI – może być „nową normą”.

    Rynek agentów AI jest gorący. Claude Code, konkurencyjne narzędzie Anthropic, notuje podobno przychody na poziomie miliarda dolarów rocznie. Największe firmy ścigają się, by zdobyć przewagę w tej dziedzinie, a otwarte modele zaczynają nadganiać dystans.

    Jaka przyszłość? Agent, którego użyje nawet mama

    Co dalej? Dla Petera Steinbergera najważniejszy jest kolejny krok. Jego osobistą misją, jak sam mówi, jest „zbudowanie agenta, którego będzie mogła użyć nawet moja mama”. To kwintesencja jego filozofii: prawdziwa moc technologii ujawnia się wtedy, gdy staje się dostępna dla każdego, a nie tylko dla wtajemniczonych.

    Jego przejście z roli samotnego, finansującego się z oszczędności twórcy open source do lidera w OpenAI to opowieść o zmianie paradygmatu. „Vibe coding” może być dla niego obelgą, ale ta dyskusja o semantyce to tylko symptom głębszego przeobrażenia. Chodzi o uznanie, że sterowanie zespołami inteligentnych agentów, precyzyjne promptowanie i architektura systemów opartych na AI to zupełnie nowa, wymagająca dyscyplina. To nie jest po prostu „wibrowanie” – to inżynieria.

    Wyczerpany, ale tryumfujący Steinberger, który przez miesiące „krwawił” 20 tysięcy dolarów miesięcznie w wiedeńskim salonie, właśnie dostał największe możliwe validation. Nie tylko od rynku (gwiazdki na GitHubie), ale od samego Sama Altmana. Teraz ma zasoby i platformę, aby swoje pomysły wprowadzić w życie. A termin „vibe coding”? Cóż, prawdopodobnie przejdzie do historii tak, jak „horseless carriage” (powóz bez konia) na określenie samochodu. Jako nieporęczne, przejściowe słowo, które nie było w stanie objąć skali nadchodzącej zmiany.

  • Claude Cowork zyskuje supermoc: harmonogram zadań już dostępny

    Claude Cowork zyskuje supermoc: harmonogram zadań już dostępny

    Wielu z nas marzy o asystencie, który wykonuje za nas powtarzalną pracę. Nie tylko na żądanie, ale też sam, o wyznaczonej godzinie. To marzenie właśnie staje się rzeczywistością dla użytkowników Claude’a. W Claude Cowork pojawiła się bowiem długo wyczekiwana funkcja: harmonogram zadań (Scheduled Tasks). To nie jest zwykłe przypomnienie, lecz pełnoprawna automatyzacja procesów. Dostępna jest dla wszystkich posiadaczy płatnych planów.

    Funkcja trafia stopniowo do użytkowników, więc jeśli jeszcze jej nie widzisz w swojej aplikacji, to najpewniej kwestia dni. A warto na nią czekać, bo zmienia ona sposób współpracy z AI z interakcji „na żądanie” na relację partnerską, w której Claude podejmuje inicjatywę.

    Jak to właściwie działa?

    Zacznijmy od absolutnych podstaw. Scheduled tasks to funkcja, która pozwala zautomatyzować powtarzalną pracę w ustalonych interwałach, bez konieczności ręcznego uruchamiania. Brzmi prosto? I tak właśnie jest w praktyce.

    Tworzenie zaplanowanego zadania jest błyskawiczne. Wystarczy w dowolnym zadaniu w Cowork wpisać komendę /schedule. Możesz też od razu przejść do dedykowanej sekcji „Scheduled” w lewym pasku bocznym aplikacji. Tam masz pełen przegląd, możliwość tworzenia nowych harmonogramów i zarządzania istniejącymi.

    Kluczową decyzją jest wybór częstotliwości. System oferuje elastyczne opcje: codziennie, co tydzień, co miesiąc lub własny, niestandardowy cykl powtarzania. To ty decydujesz, czy praca ma być wykonywana każdego poranka o 8:00, w każdy piątek po południu, czy może pierwszego dnia miesiąca.

    Nie tylko proste skrypty: potencjał harmonogramu

    Prawdziwa siła tej funkcji leży nie w samym planowaniu, ale w tym, co można zaplanować. Claude Cowork obsługuje złożone, wieloetapowe automatyzacje. To nie jest tylko wysłanie e-maila. To pełne przepływy pracy.

    Wyobraź sobie kilka scenariuszy. Jesteś naukowcem lub analitykiem. Możesz ustawić cotygodniowy „przegląd literatury” na śledzone przez ciebie tematy. Claude samodzielnie przeszuka nowe publikacje, streści kluczowe wnioski i zaktualizuje Twoją bazę danych. Albo, w ramach zarządzania danymi, zautomatyzujesz cotygodniowe czyszczenie zbioru, aktualizację kluczowych metryk i generowanie gotowej tabeli ze statystykami podsumowującymi.

    Funkcja świetnie sprawdza się też w życiu codziennym. Regularne podsumowanie zawartości skrzynki e-mail? Organizacja plików w folderze „Downloads” co weekend? Przetwarzanie zeskanowanych paragonów w formacie do rozliczenia? To wszystko można powierzyć Claude’owi, który wykona to sam, bez twojego udziału.

    Jeden z wczesnych testerów funkcji ujął to dosadnie: „Opisujesz oczekiwany rezultat, odchodzisz od komputera, wracasz i praca jest wykonana”. To właśnie sedno tej innowacji.

    Ważne ograniczenie: świadomy asystent

    Zanim jednak rzucimy się w wir automatyzacji, jest jeden istotny techniczny warunek, o którym trzeba pamiętać. Zaplanowane zadania uruchomią się tylko wtedy, gdy twój komputer nie śpi i gdy aplikacja Claude Desktop jest otwarta.

    Jeśli twoja maszyna będzie w stanie uśpienia w momencie planowego wykonania zadania, to po prostu je pominie. Wykona je dopiero wtedy, gdy obudzisz komputer. To oznacza, że harmonogramy idealnie nadają się do pracy w ciągu dnia (np. „w południe każdego dnia roboczego”), ale już mniej do zadań zaplanowanych na 3:00 w nocy, chyba że masz zwyczaj nie wyłączać komputera.

    Warto o tym pamiętać przy projektowaniu swoich automatyzacji. To trochę jak zaufany asystent, który jest gotów do pracy tylko wtedy, gdy jesteś w biurze. Na razie nie ma opcji zdalnego „budzenia” maszyny czy działania przez chmurę bez otwartej aplikacji desktopowej.

    Przykłady z życia wzięte

    Żeby lepiej zrozumieć potencjał, spójrzmy na konkretne zastosowania, które już teraz sprawdzają się w praktyce.

    • Badaczka medyczna używa harmonogramu, by co poniedziałek rano otrzymywać zestawienie najnowszych artykułów z wybranych czasopism naukowych. Claude nie tylko podaje tytuły, ale też ekstrahuje metodologię i kluczowe wyniki, oszczędzając jej godziny manualnego przeglądania.

    • Freelancer zajmujący się social media zaplanował zadanie na każdy piątek o 16:00. Jego celem jest przeanalizowanie statystyk tygodnia dla wszystkich prowadzonych kont i wygenerowanie krótkiego raportu z rekomendacjami na następny tydzień. W piątek po południu ma gotowy materiał do pracy.

    • Księgowy w małej firmie wykorzystuje harmonogram do miesięcznego porządkowania. Pierwszego dnia miesiąca Claude przetwarza folder z fakturami z poprzedniego miesiąca, kategoryzuje je, wyciąga kluczowe kwoty i przygotuje wstępny plik do rozliczenia VAT.

    Możliwości są naprawdę ograniczone tylko naszą wyobraźnią i tym, co Claude potrafi zrobić na nasze żądanie. Teraz te umiejętności może wykorzystywać samodzielnie, według naszego scenariusza.

    Jak zacząć i o czym pamiętać?

    Jeśli masz już dostęp do funkcji, rozpoczęcie przygody jest proste. Otwórz sekcję „Scheduled” i kliknij „Create New”. Kluczowy jest jasny, precyzyjny prompt – taki sam, jakiego używasz w codziennej pracy z Claude’em. Opisz krok po kroku, co ma zostać wykonane, na jakich danych i w jakiej formie oczekujesz rezultatu.

    Potem wystarczy ustawić częstotliwość i godzinę. Na koniec warto przetestować zadanie, uruchamiając je ręcznie raz lub dwa, by upewnić się, że wszystko działa zgodnie z oczekiwaniami. Później już możesz o nim zapomnieć.

    Pamiętaj też, że te automatyzacje działają w oparciu o twoje konto i kontekst. Claude ma dostęp do twoich danych w Cowork (plików, notatek, przestrzeni), więc zadania mogą być bardzo spersonalizowane i głęboko zintegrowane z twoją pracą.

    Podsumowanie: krok w stronę autonomicznej współpracy

    Wprowadzenie harmonogramu zadań w Claude Cowork to znacznie więcej niż kolejna funkcja. To zmiana paradygmatu. Przesuwamy się z modelu, w którym AI jest narzędziem reagującym na nasze komendy, w stronę modelu aktywnego partnera, który samodzielnie inicjuje i prowadzi procesy.

    Dla każdego, kto mierzy się z cyklicznymi, czasochłonnymi zadaniami, to prawdziwy game-changer. Zyskujemy nie tylko czas, ale i pewność, że żaden ważny, rutynowy proces nie zostanie przez nas przeoczony w natłoku codziennych obowiązków.

    Funkcja, choć na razie wymaga, by aplikacja była otwarta, stanowi mocny fundament pod przyszły rozwój. Można sobie wyobrazić, że kolejnym krokiem będzie zdalne wyzwalanie zadań lub integracja z kalendarzem i systemami zewnętrznymi. Na razie jednak to, co dostajemy, już znacząco podnosi poprzeczkę w zakresie produktywności z pomocą AI. Warto sprawdzić, czy harmonogram już na ciebie czeka w twojej aplikacji, i zacząć planować swoją pracę w zupełnie nowy sposób.

  • Kiedy AI odcina dopływ tlenu: jak „vibe coding” dusi open source i zniechęca jego twórców

    Kiedy AI odcina dopływ tlenu: jak „vibe coding” dusi open source i zniechęca jego twórców

    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.