Kategoria: Open Source

  • Wibrujący kod czy agentyczna inżynieria? Twórca OpenClaw mówi, że „vibe coding” stało się obelgą

    Wibrujący kod czy agentyczna inżynieria? Twórca OpenClaw mówi, że „vibe coding” stało się obelgą

    Peter Steinberger, twórca najszybciej rozwijającego się projektu open-source w historii GitHub, ma dość pewnego terminu. Mowa o "vibe coding", które w jego oczach przerodziło się w coś więcej niż tylko żargon. To, według niego, "obelga" używana przez krytyków, by zdyskredytować nowatorskie podejście do programowania z AI.

    Steinberger, którego projekt OpenClaw w krótkim czasie po viralnym wzroście pod koniec stycznia 2026 roku zdobył ponad 215 tysięcy gwiazdek na GitHubie, a on sam został zatrudniony przez OpenAI w lutym 2026 roku do pracy nad rozwojem agentów AI, stawia sprawę jasno. W publicznych wypowiedziach porównał kodowanie z AI do nauki gry na gitarze – to umiejętność, którą trzeba opanować, a nie magiczny trik. I właśnie to przeświadczenie o łatwości jest sednem problemu z terminem "vibe coding".

    Czym naprawdę jest "vibe coding"?

    Sam termin wyłonił się jako potoczne określenie stylu programowania, w którym deweloperzy wykorzystują asystentów AI, takich jak ChatGPT czy Claude, do generowania kodu na podstawie ogólnych wskazówek. Zamiast precyzyjnych specyfikacji czy tradycyjnego, krok po kroku, pisania kodu, chodzi tu o nakreślenie intencji i "wyczucie" właściwego kierunku przy pomocy modelu językowego. To jakby prowadzić rozmowę z niezwykle pojętnym, choć czasem literackim, stażystą.

    To podejście zyskało ogromną popularność w 2025 roku, na tyle dużą, że termin stał się powszechnie rozpoznawany. Szybko jednak, jak to bywa z nowymi zjawiskami, termin zaczął żyć własnym życiem. Dla jednych stał się wygodnym skrótem myślowym opisującym nową rzeczywistość. Dla innych – właśnie jak dla Steinbergera – nabrał pejoratywnego wydźwięku.

    Obelga czy tylko żargon? Spór o słowa

    "Oni nie rozumieją, że to umiejętność" – tak Steinberger skomentował postrzeganie pracy z AI przez część środowiska. Dla niego określenie "vibe coding" jest używane po to, by sprawić, że kodowanie z AI brzmi banalnie i trywialnie. To zdaniem programisty pomija cały warsztat, doświadczenie i intuicję potrzebną do skutecznego prowadzenia "rozmowy" z maszyną.

    Zamiast tego, Steinberger proponuje termin "agentic engineering" – inżynieria agentowa. To określenie ma oddawać powagę i strategiczny charakter tej metody. Nie chodzi już o "wibrowanie", ale o świadome projektowanie i zarządzanie inteligentnymi agentami AI, które wykonują złożone zadania. Ten spór terminologiczny nie jest czysto akademicki. Odzwierciedla głębszy podział w świecie technologii na tych, którzy widzą w AI jedynie narzędzie automatyzacji, i tych, którzy dostrzegają w niej fundament zupełnie nowej metodologii tworzenia oprogramowania.

    Co ciekawe, sam termin "vibe coding" spopularyzował Andrej Karpathy, były szef AI w Tesli. Jednak i on podobno zaczyna dziś preferować "agentic engineering". To sygnał, że nawet twórcy określeń ewoluują wraz ze zrozumieniem zjawiska.

    Od menedżera do wirtuoza AI

    Historia Steinbergera dobrze pokazuje, dlaczego "vibe coding" to uproszczenie. Przed stworzeniem OpenClaw założył on PSPDFKit i przez lata zarządzał zespołami programistów. To doświadczenie okazało się kluczowe. W jednym z wywiadów przyznał, że zarządzanie ludźmi nauczyło go czegoś fundamentalnego: musiał zaakceptować, że podwładni nie napiszą dokładnie takiego kodu, jakiego by on sam oczekiwał. Ta sama zasada dotyczy agentów AI.

    "Wiedzę, kiedy kod jest zły" – mówił, opisując swoją pracę. Dziś potrafi "wydać" kod wygenerowany przez AI, nawet go nie czytając, bo ma wyczucie granic możliwości systemu i wie, na co można mu pozwolić. "Większość kodu jest nudna" – stwierdził, podkreślając, że kluczem jest zrozumienie ogólnych wzorców i architektury, a nie wkuwanie każdej linijki. To połączenie głębokiego doświadczenia programistycznego, umiejętności miękkich wyniesionych z zarządzania i intuicji w pracy z AI złożyło się na sukces OpenClaw.

    Dlaczego OpenAI zatrudniło "wibrującego" programistę?

    Decyzja OpenAI o zatrudnieniu Steinbergera w lutym 2026 roku jest najsilniejszym argumentem w tej dyskusji. Firma ogłosiła to 14 lutego, wskazując, że będzie on pracował nad rozwojem agentów AI. To nie jest zatrudnianie kogoś, kto po prostu "klika prompty". To strategiczny ruch firmy, która dostrzega w jego metodologii przyszłość tworzenia oprogramowania.

    Steinberger nie był zresztą obiektem zainteresowania tylko OpenAI. Jak sam wspominał, prowadził rozmowy z wieloma wiodącymi laboratoriami AI. Firma Anthropic poprosiła go nawet o zmianę nazwy jego chatbota z Clawdbot na Moltbot z powodu kwestii znaku towarowego, co pokazuje, jak poważnie potraktowano jego projekt. Jego sukces dowodzi, że podejście, które niektórzy chcieliby zdyskredytować jako "vibe coding", jest w stanie produkować oprogramowanie na światowym poziomie, przyciągające setki tysięcy zainteresowanych deweloperów.

    Podsumowanie

    Spór o "vibe coding" vs. "agentic engineering" to coś więcej niż tylko wojna na słowa. To starcie dwóch perspektyw na rewolucję, która dzieje się na naszych oczach. Z jednej strony mamy postawę lekceważącą, redukującą złożoną współpracę człowieka z zaawansowaną inteligencją do prostej "wibracji". Z drugiej – widzenie tej relacji jako nowej dyscypliny inżynieryjnej, wymagającej głębokich umiejętności, strategicznego myślenia i zupełnie nowego zestawu kompetencji.

    Sukces Petera Steinbergera i jego OpenClaw, który rozpoczął się jako Clawdbot w listopadzie 2025 roku, a gwałtownie zyskał popularność na przełomie stycznia i lutego 2026, jest mocnym argumentem za tą drugą opcją. Gdy najważniejsze firmy AI świata zabiegają o takiego specjalistę, trudno utrzymywać narrację, że jego praca to jedynie "wyczucie". To raczej zapowiedź nowego zawodu – agentycznego inżyniera – który łączy w sobie znajomość kodu, psychologii zarządzania i sztukę precyzyjnej komunikacji z maszynami. A to już brzmi znacznie poważniej niż jakakolwiek "wibracja".

  • 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.