Vibe coding, czyli programowanie na czuja. Co mówią liczby w 2026
TL;DR: Vibe coding, czyli akceptowanie kodu z AI bez czytania go, przeszedł drogę od tweeta Karpathy'ego do Słowa Roku Collinsa i listy przełomowych technologii MIT w niecały rok. Dane przyznają rację obu stronom: 84% programistów używa narzędzi AI i indywidualna produktywność rośnie, ale duplikacja kodu wzrosła 4-krotnie, aplikacje z vibe codingu mają 2,74x więcej podatności, a satysfakcja spada. W Polsce powstał już rynek sprzątania po vibe codingu. Moje zdanie po codziennej pracy z AI: to realna dźwignia, ale tylko wtedy, gdy człowiek odpowiada za każdą linijkę, która idzie na produkcję.
Andrej Karpathy publikuje post na X w lutym 2025. 4,5 miliona wyświetleń. W marcu Merriam-Webster dodaje termin do słownika slangu. W listopadzie Collins Dictionary ogłasza go Słowem Roku. W styczniu 2026 MIT Technology Review wpisuje generatywne kodowanie na listę przełomowych technologii 2026. W lutym 2026 sam Karpathy mówi, że termin jest już „passe”, i wprowadza „agentic engineering” jako następną ewolucję.
W kwietniu 2026 pierwsza europejska konferencja o vibe codingu odbywa się w Gdyni. Nie w San Francisco. W Gdyni.
To szybka trajektoria jak na coś, co zaczęło się od luźnego tweeta o akceptowaniu kodu bez czytania diffów. Moje zdanie: vibe coding jest prawdziwy, jest użyteczny, a większość krytyków mija się z celem.
Co to jest vibe coding?
Oryginalna definicja Karpathy'ego jest prosta: opisujesz, co chcesz, AI generuje kod, a ty „zapominasz, że kod w ogóle istnieje”. Akceptujesz output bez przeglądania, doprecyzowujesz kolejnymi promptami i wdrażasz, jak działa. Albo, jak pisze iMagazine, programowanie na czuja.
Simon Willison narysował granicę, która moim zdaniem jest ważniejsza niż cały hype. Jeśli przejrzałeś, przetestowałeś i rozumiesz kod, to nie jest vibe coding. To użycie LLM jako asystenta do pisania. Różnica dotyczy odpowiedzialności, nie tego, czy AI dotknęło kodu.
Dokładnie tak pracuję. Przeglądam każdy ważny fragment, testuję, rozumiem architekturę, zanim cokolwiek trafi na produkcję. Kiedy budowałem FlowMate, SaaS do zarządzania mailami, który później odłożyłem na półkę, każda linijka kodu wspomaganego przez AI przeszła przez mój review. AI przyspieszało pisanie. Decyzje inżynieryjne były moje, błędy też.
Ale wielu ludzi używa definicji Karpathy'ego dosłownie. Nie-koderzy budują aplikacje. Founderzy wypuszczają MVP bez osoby technicznej. Solowi deweloperzy budują narzędzia wewnętrzne szybciej, niż zrobiłby to zespół. I to właśnie niepokoi seniorów.
Ilu programistów używa AI i co z tego wynika?
Ankieta Stack Overflow 2025 pokazała, że 84% deweloperów używa lub planuje używać narzędzi AI, wzrost z 76% w 2024 i 70% w 2023. Ponad połowa używa ich codziennie. Sam GitHub Copilot przekroczył 20 milionów użytkowników, a badania GitHuba od dawna pokazują, że w plikach z włączonym Copilotem pisze on blisko połowę kodu.
W polskich firmach IT to nie jest odległy trend z Doliny Krzemowej. To codzienność, od korporacji po jednoosobowe działalności.
Deklaracje liderów eskalują: Satya Nadella mówi o 20 do 30% kodu Microsoftu pisanym przez oprogramowanie, Dario Amodei z Anthropic publicznie deklaruje, że zdecydowana większość ich kodu pochodzi z Claude, a na demo day Y Combinatora Garry Tan ujawnił, że 25% startupów batcha miało bazy kodu niemal w całości wygenerowane przez AI.
Mniej nagłaśniana część: satysfakcja z narzędzi AI spadła z ponad 70% do 60% w 2025, a 66% deweloperów zgłasza frustrację rozwiązaniami AI, które są „prawie poprawne, ale nie do końca”. Adopcja jest realna. Zadowolenie nie nadąża.
Czy kod z AI jest gorszy? Badania obok siebie
Obawy nie są urojone. Stan badań na początek 2026:
| Badanie | Co mierzyło | Kluczowy wynik |
|---|---|---|
| GitClear | 211 mln linii kodu, 2020-2024 | Duplikacja kodu 4x w górę; refaktoryzacja spadła z 25% do poniżej 10% zmian |
| CodeRabbit | 470 pull requestów | Kod AI: 1,7x więcej problemów, 2,74x więcej podatności, 3x gorsza czytelność |
| Wiz | 5600 aplikacji z vibe codingu | Ponad 2000 podatności, 400 ujawnionych sekretów; 1 na 5 aplikacji z poważnymi błędami |
| DORA 2025 | Metryki dostarczania w organizacjach | AI to „multiplikator”: wzmacnia zespoły z dobrymi praktykami, obnaża resztę |
Wzorzec u Wiza był zawsze ten sam: uwierzytelnianie po stronie klienta, klucze API na twardo w kodzie, niechroniony dostęp do bazy. A niuans DORA jest ważny: osobne badania telemetryczne Faros AI zmierzyły, że pojedynczy deweloperzy kończą około 21% więcej zadań i mergują 98% więcej pull requestów, ale metryki dostarczania całych organizacji stoją w miejscu. Szybsze pisanie to nie to samo co szybsze dostarczanie.
Ktoś, kto na czuja zbudował aplikację dla klientów bez zrozumienia modelu bezpieczeństwa, stworzył zobowiązanie, nie produkt. A im więcej takich aplikacji trafia na produkcję, tym więcej jest do posprzątania.
Sprzątanie po vibe codingu: polski fenomen
Ciekawostka: jedną z firm, które najszybciej zmonetyzowały ten problem, jest polska. Ulam Labs z Wrocławia oferuje usługę dosłownie nazwaną „sprzątanie po vibe codingu”. Nie są jedyni: iMagazine opisał, jak platforma VibeCodeFixers zebrała ponad 300 deweloperów gotowych naprawiać to, co inni navibe'owali.
AI nie zabrało pracy programistom. Stworzyło nową kategorię pracy: naprawianie tego, co AI zbudowało bez nadzoru.
To jest to, co Kodiwo z Bielska-Białej nazywa długiem zrozumienia, comprehension debt. To nie jest zwykły dług techniczny. To sytuacja, w której nikt w zespole nie rozumie kodu działającego na produkcji. Żadna ilość testów tego nie naprawi, bo nikt nie wie, co testować.
Dlaczego open source broni się przed kodem z AI?
Pull requesty generowane przez AI zaczęły zalewać popularne repozytoria. Daniel Stenberg, maintainer curla, wygasił program bug bounty, gdy odsetek prawdziwych podatności w zgłoszeniach spadł do około 5%. Mitchell Hashimoto zakazał kodu AI w projekcie Ghostty. Steve Ruiz zamknął zewnętrzne PR-y do tldraw. GitHub rozważa ograniczenia pull requestów, żeby maintainerzy nadążyli.
Jak ujęli to prowadzący Patoarchitektów: nie chodzi o to, że AI jest złe. Chodzi o to, że ludzie używają go tam, gdzie nie powinni: w istniejących, złożonych systemach, które wymagają głębokiego zrozumienia, zanim je dotkniesz.
Krytyka mija się z celem
Najgłośniejsze skargi brzmią jak „vibe coding jest zły dla oprogramowania”. Ale między wierszami czytam coś innego: „ludzie, którzy nie wiedzą tego co ja, teraz budują rzeczy”. To nie jest argument techniczny. To gildia chroniąca terytorium.
Buduję strony internetowe i systemy automatyzacji dla lokalnych firm, tu, w Częstochowie i na Śląsku. Restauracje, salony, barberzy. Żadna z tych firm nie potrzebuje zespołu senior inżynierów. Potrzebuje działającej strony z formularzem i przyzwoitym SEO. Używam kodowania wspomaganego AI, żeby budować to szybciej i taniej. To nie kryzys. To rynek działający prawidłowo.
Kryzys jest realny dla firm, które na czuja doszły do 50 000 linii AI-spaghetti i teraz muszą dodać funkcję. Rozwiązaniem nie jest zakaz AI. Rozwiązaniem jest rozumienie tego, co się buduje. Problem martwego internetu dotyczy też kodu: jakość i odpowiedzialność nadal wygrywają.
Co naprawdę liczy się w 2026?
Powiem wprost: vibe codingu boją się deweloperzy, których wartością była znajomość składni i API. To zawsze była krucha pozycja. Spokojni są ci, których wartością jest wiedza, co budować, po co i czy to, co powstało, jest poprawne.
Vibe coding podnosi dolną granicę: każdy może wyprodukować działający kod do prostych problemów, i to jest dobre. Sufit (rozumienie systemów, decyzje architektoniczne, wyłapanie dziury bezpieczeństwa, której AI nie oznaczyło) się nie przesunął. Wręcz zyskał na wartości, bo ktoś musi nadzorować te wszystkie wygenerowane aplikacje.
Polski rynek IT to potwierdza. Według justjoin.it kategoria AI/ML zanotowała 4-krotny wzrost ofert pracy w 2025, ale 51% ofert to pozycje seniorskie, 44% mid, a niecałe 5% juniorskie. Rynek nie szuka ludzi, którzy potrafią pisać kod. Szuka ludzi, którzy potrafią myśleć. Do tego Stanford zmierzył, że zatrudnienie deweloperów w wieku 22-25 lat spadło o prawie 20% w latach 2022-2025, podczas gdy starsi trzymają poziom lub rosną.
Korzystam z Claude przy niemal każdym projekcie, przy integracjach AI i codziennym budowaniu stron. Kiedy tworzyłem workflow automatyzacji do znajdowania firm bez stron, AI robiło powtarzalne części, a ja projektowałem architekturę. Promptuję, przeglądam, poprawiam. Nie oddaję się wibracjom w całości. Ale też nie udaję, że piszę wszystko ręcznie dla czystości, która przestała mieć znaczenie dwa lata temu.
Złoty środek
Ciężko będzie nie tym, którzy przyjmują AI coding. Ciężko będzie tym, którzy go odrzucają, i tym, którzy korzystają z niego bez osądu. Złoty środek, w którym używasz narzędzi i odpowiadasz za output, to miejsce, gdzie dzieje się prawdziwa praca.
Computerworld ujął to trafnie: organizacje potrzebują „wyboru, kontroli i pewności”. Vibe coding daje wybór. Kontrola i pewność nadal zależą od człowieka.
Vibe coding przejmuje tworzenie oprogramowania i część tego będzie bolała. Ale fundamentalna zmiana, że opisanie czego chcesz w naturalnym języku jest teraz prawidłowym sposobem budowania oprogramowania, już się wydarzyła i się nie cofnie. Pytanie nigdy nie brzmiało „czy programiści powinni używać AI?”, tylko „jak używać go, nie tworząc bałaganu?”. Odpowiedź jest ta sama co zawsze w inżynierii: rozumiej, co budujesz, testuj i bierz za to odpowiedzialność.
Ten artykuł jest dostępny również na Medium.
