Czym jest vibe coding?
Jak AI tworzy oprogramowanie w 2026 roku?

Kiedy zespół CodeRabbit przeanalizował 470 pull requestów, okazało się, że kod tworzony z pomocą AI miał 1,7 razy więcej poważnych błędów i 2,74 razy wyższy wskaźnik luk bezpieczeństwa niż kod pisany przez ludzi. Mniej więcej tak wygląda dziś branża i tak wygląda vibe coding w 2026 roku. AI pisze sporą część nowego kodu, a duża jego część zawodzi w miejscach, których osoba pisząca prompt nie miała szans przewidzieć.

Jeśli kiedykolwiek zleciłeś sztucznej inteligencji napisanie aplikacji i patrzyłeś, jak na żywo, na ekranie pojawia Ci się działająca apka, to gratulacje, masz za sobą pierwszy vibe coding. Natomiast ekscytacja mija w momencie, gdy wręczasz aplikację swoim klientom lub innym użytkownikom.

W tym tekście chcemy pokazać, czym właściwie jest vibe coding, jak AI buduje dziś oprogramowanie i gdzie zwykle się to załamuje, bo sporą część czasu spędzamy na porządkowaniu takich projektów. Vibe coding jest naprawdę przydatny. Przestaje wystarczać w chwili, gdy z aplikacji zaczyna korzystać ktoś poza Tobą. Jeśli już przekroczyłeś tę granicę i coś zaczyna Cię niepokoić, najprościej dać kod do sprawdzenia komuś, kto zna te błędy na pamięć.

Vibe coding: co to właściwie jest?

Terminu używa się dziś do wszystkiego, co ma cokolwiek wspólnego z AI i kodem, i między innymi dlatego dyskusje o nim donikąd nie prowadzą. Zobaczmy, co znaczył na początku i jak to znaczenie się rozmyło.

Skąd wziął się ten termin?

Vibe coding to tworzenie oprogramowania poprzez opisywanie sztucznej inteligencji tego, czego się oczekuje, i przyjmowanie wygenerowanego kodu bez jego czytania. Piszesz prompt, model generuje kod, ty go uruchamiasz, a gdy coś przestaje działać, przekazujesz mu komunikat błędu i zlecasz kolejną próbę. Istotą tego podejścia jest to, że nie analizujesz kodu i nie planujesz tego robić.

Termin ukuł Andrej Karpathy w poście z lutego 2025 roku. Jego sformułowanie, mówiło o tym, żeby dać się ponieść wibracjom, uwierzyć w wykładniczy wzrost i zapomnieć, że kod w ogóle istnieje. Zwykle urywa się je w tym miejscu i pomija dalszą część, w której autor zaznacza, że nadaje się to do jednorazowych, weekendowych projektów. Opisywał zabawkę, dobrą do eksperymentu, ale nie do prowadzenia na niej firmy.

Materiał Fireship do dziś najzwięźlej tłumaczy, jak ten pomysł się rozszedł i dlaczego część programistów podeszła do niego z rezerwą:

Nic z tego nie mówi, czy efekt jest dobry. Mówi tylko, jak powstał: ty opisywałeś, AI budowało, a nikt nie sprawdził rezultatu.

Vibe coding a programowanie wspierane przez AI: jaka jest różnica?

Wielu traktuje te dwie rzeczy jako jedno i to jest źródło kłopotów, bo ktoś wypuszcza prototyp w przekonaniu, że zbudował produkt. Różnica sprowadza się do jednego nawyku. Przy vibe codingu nie czytasz kodu. Przy programowaniu wspieranym przez AI czytasz.

	Vibe coding	Programowanie wspierane przez AI
Kto sprawdza kod	Nikt albo samo AI	Ty albo drugie AI sprawdzające pierwsze
Cel	Szybko zobaczyć, czy pomysł działa	Zbudować coś realnego i utrzymywalnego
Podejście do kodu	Przyjmujesz i idziesz dalej	Rozumiesz i bierzesz na siebie
Do czego pasuje	Prototypy, narzędzia wewnętrzne, eksperymenty	Produkty z prawdziwymi użytkownikami

Do tego samego podziału doszedł zresztą sam Karpathy na początku 2026 roku. W rozmowie ze Stephanie Zhan z Sequoi, podczas wydarzenia AI Ascent, w sesji zatytułowanej „From Vibe Coding to Agentic Engineering”, stwierdził w gruncie rzeczy, że jego własny termin zdążył się już zestarzeć na potrzeby poważnej pracy, a ci, którzy robią to porządnie, przeszli do czegoś, co nazywa agentic engineering: nadal piszą agenty AI, ale nad każdym krokiem czuwa człowiek. Warto obejrzeć, tym bardziej że mówi to osoba, która ten termin wymyśliła:

Więc kiedy następnym razem ktoś powie, że zvibecodował jakąś funkcję, warto dopytać, którą wersję ma na myśli. Jedna to szkic na serwetce. Druga to prawdziwa inżynieria, która przy okazji korzysta z AI.

Jak AI faktycznie buduje oprogramowanie w 2026 roku?

Pod hasłem „platforma do vibe codingu” kryją się narzędzia, które działają zupełnie inaczej, a różnice znaczą znacznie więcej, niż sugerują strony sprzedażowe. Między jednym a drugim zmienia się to, ile narzędzie robi za Ciebie i ile kontroli oddajesz w zamian. Każde narzędzie do vibe codingu z AI leży gdzieś na tej osi.

Jakie są główne rodzaje narzędzi do vibe codingu?

Narzędzia dzielą się zasadniczo na dwie grupy.

Najpierw kreatory aplikacji webowych: Lovable, Replit, Bolt, v0. Wchodzisz na stronę, opisujesz aplikację, a platforma obsługuje niemal wszystko za Ciebie. Wynajmuje serwer, uruchamia agenta AI, spina backend (tę część, która przechowuje dane i obsługuje logikę, której nikt nie widzi) i po kilku minutach oddaje działającą aplikację w przeglądarce. Mają gotową całą infrastrukturę, jakiej potrzebuje porządna aplikacja, i podpowiadają rozsądne ustawienia domyślne. To ich zaleta, ale też, do czego jeszcze wrócimy, sposób, w jaki cię do siebie przywiązują.

Potem narzędzia dla programistów: Cursor, Claude Code, Codex, Antigravity, OpenCode. Działają na Twoim komputerze i dają kod, który możesz umieścić tam, gdzie chcesz. Cursor to edytor, Claude Code (Anthropic) i Codex (OpenAI) to asystenci działający z linii poleceń, Antigravity to propozycja Google, a OpenCode jest darmowy i otwartoźródłowy, więc możesz podpiąć pod niego dowolny model. Kontroli masz znacznie więcej, a w zamian więcej pracy wykonujesz samodzielnie, od instalacji tego, czego potrzebujesz, po decyzję, gdzie gotowa aplikacja ma docelowo działać.

W skrócie:

• Kreatory webowe (Lovable, Replit, Bolt, v0) to platformy do vibe codingu, po które sięga ktoś, kto nie uważa się za programistę. Wszystko jest zrobione za Ciebie, a od pomysłu do działającej aplikacji dochodzisz bez otwierania terminala.
• Narzędzia dla programistów (Cursor, Claude Code, Codex) są w większości używane przez osoby robiące już programowanie z AI, które chcą, żeby model pisał kod, ale i tak zamierzają go przeczytać, uruchomić i wdrożyć samodzielnie.

Prosta zasada: jeśli nigdy nie pisałeś kodu, a aplikacja od razu zadziałała w przeglądarce, to niemal na pewno był to kreator webowy. Jeśli ktoś musiał najpierw coś zainstalować, to było narzędzie dla programistów.

Kim jest vibe coder?

Nie ma jednego typu i traktowanie wszystkich tak samo to źródło większości błędnych opinii na ten temat. Wyobraź to sobie raczej jako spektrum.

1. Kompletny początkujący. Wczoraj obejrzał pierwszy tutorial, założył konto, zaczął klikać kolejne ekrany, bez pojęcia, co dzieje się pod spodem.
2. Poważny uczeń. Od półtora roku codziennie buduje aplikacje z AI, po drodze nadrabia braki z YouTube’a i dokumentacji. Na tym etapie można go nazwać programistą i człowiek się specjalnie nie pomyli.
3. Techniczny przesiadkowicz. Na przykład były developer WordPressa. Wie, jak wygląda luka bezpieczeństwa, wie, że na stronę można się włamać, i porządnie ustawił agenta AI, zanim napisał pierwszą linijkę.

To, gdzie ktoś leży na tym spektrum, decyduje o tym, czy jego aplikacja nadaje się do wypuszczenia, i to samo tłumaczy, dlaczego tylu nieprogramistów w ogóle buduje dziś oprogramowanie. Około 63% osób korzystających z tych narzędzi to nieprogramiści: product managerowie, założyciele firm, projektanci. Narzędzia wpuściły ich wszystkich do środka. Czego narzędzia nie potrafiły przekazać, to lata doświadczeń i błędów, które kiedyś szły z tym w parze.

Gdzie vibe coding się psuje?

AI potrafi pisać dobry, bezpieczny kod. Warto to powiedzieć wprost, bo model zwykle nie jest problemem. Problemem jest to, że osoba pisząca prompt nie wie, o co poprosić, więc trudne rzeczy nigdy nie zostają zamówione. Dalej opisujemy błędy, które widzimy raz za razem, gdy zvibecodowana aplikacja ląduje na naszym biurku.

Scenariusz optymistyczny a przypadki brzegowe

Programista z kilkuletnim stażem robi dwie rzeczy naraz, nawet o tym nie myśląc. Jedna to zbudowanie tego, o co prosisz. Druga to po cichu obsłużenie wszystkiego, co może pójść nie tak: pustego formularza, który ktoś wyśle, wiekowej przeglądarki, podwójnego kliknięcia, które obciąża kartę dwa razy. Ta druga część pracy jest niewidoczna i to za nią głównie płaci się w doświadczeniu.

Zvibecodowana aplikacja robi tylko tę pierwszą rzecz. Powiedziałeś, co ma się dziać, AI to zrobiło i nie zrobiło nic ponadto, więc na Twoim ekranie wygląda idealnie. Problem w tym, że prawdziwi użytkownicy rzadko zachowują się tak, jak zakładałeś. Klikają nie w tej kolejności, wpisują dane w formacie, którego nikt nie przewidział, korzystają z aplikacji na sprzęcie i w warunkach, o których nie pomyślałeś. I dokładnie w tych momentach aplikacja zaczyna zawodzić.

Kilka typowych przykładów:

• Ktoś wpisuje w pole emoji i cała strona przestaje działać.
• Ktoś inny wgrywa zdjęcie ważące 40 megabajtów, którego aplikacji nikt nie kazał zmniejszyć.
• Trzecia osoba otwiera ją na służbowym laptopie, gdzie połowa przycisków ląduje poza ekranem.

Żaden z tych przypadków nie jest tajemnicą, AI po prostu nie dostało informacji, że mają znaczenie, bo osoba pisząca prompt nie wiedziała, że to w ogóle są przypadki do obsłużenia. Ktoś z doświadczeniem we wdrażaniu oprogramowania pomyślałby, żeby dodać „obsłuż duży plik, obsłuż nietypowe znaki, sprawdź to na małym ekranie”, bo każdy z tych scenariuszy już go kiedyś zaskoczył, podczas gdy początkujący nie ma jak na to wpaść.

Bezpieczeństwo, o które nikt nie poprosił

Teraz część, która budzi najwięcej oporu. AI potrafi zrobić dobre zabezpieczenia, ale tylko wtedy, gdy o to poprosisz, a większość osób budujących pierwszą aplikację nigdy o to nie prosi, bo w ogóle nie przychodzi im do głowy, że bezpieczeństwo to coś, o czym trzeba wspomnieć.

Klasyczna katastrofa to wyciek klucza API. Aplikacja potrzebuje klucza, żeby korzystać z funkcji AI, a ten klucz obciąża Twoje konto. Umieść go w złym miejscu, opublikuj i już jest dostępny dla każdego. Są boty, które nie robią nic innego, tylko skanują sieć dokładnie w tym celu, więc zanim się zorientujesz, obce osoby od kilku godzin generują koszty na Twoim koncie. Zdarza się to na tyle często, że Claude Code reaguje dziś alarmem, ledwie wypatrzy klucz w Twojej historii, ostrzega i każe go zrotować, choć oczywiście możesz to zignorować i kazać mu po prostu doprowadzić rzecz do działania.

I to naprawdę jest codzienność. Audyt bezpieczeństwa powiązany z Lovable (CVE-2025-48757) wykazał, że 170 z 1645 aplikacji, ponad jedna na dziesięć, miało krytyczne luki pozwalające jednemu użytkownikowi czytać prywatne dane drugiego. Jeśli spojrzeć na kod generowany przez AI szerzej, mniej więcej 45% próbek niesie ze sobą poważne podatności. A kiedy Twoja aplikacja trzyma już dane osobowe, i wystarczy do tego zwykłe forum z logowaniem, taki wyciek jest tym, po czym produkt się nie podnosi. Tu właśnie porządny audyt bezpieczeństwa zwraca się z nawiązką, a przed startem kosztuje dużo mniej niż po włamaniu.

Wyciek danych, którego nie widać

Błędy, które przerażają nas najbardziej, to te, które wyglądają zupełnie w porządku. Wyobraź sobie narzędzie, w którym różne firmy dodają swoje oferty. Logujesz się, widzisz tylko swoje oferty, więc naturalnie zakładasz, że filtrowanie działa. Nie działa. Pod spodem serwer wysyła do Twojej przeglądarki dane wszystkich firm, a ekran chowa resztę, co oznacza, że każdy, kto otworzy wbudowane w przeglądarkę narzędzia dla programistów, może przewijać cudze rekordy.

Dla programisty widać to od pierwszego spojrzenia, bo filtrowanie należy do serwera, który decyduje, co Ci wysłać, a nie do przeglądarki, która decyduje tylko, co pokazać. Osoba nietechniczna nigdy tam nie zajrzy. Widzi na ekranie to, co powinna, więc temu ufa, i to jest właśnie ta luka, którą audyt Lovable wyłapywał raz za razem, w aplikacjach budowanych przez ludzi, którzy nie mieli powodu, żeby nauczyć się, że serwer i przeglądarka to dwa różne miejsca.

Aplikacja przejmuje Twoje złe nawyki

Jeszcze jedno warto wiedzieć: AI uwielbia powielać to, co już zrobiłeś, co brzmi niegroźnie, dopóki nie jesteś przy projekcie budowanym bez żadnych zasad.

Jeśli przez pierwsze dwa tygodnie pozwolisz mu pomijać porządne sprawdzanie po stronie serwera albo przepuścisz niebezpieczne skróty, bo chcesz działać szybko, model po cichu uzna, że tak właśnie robi się ten projekt, i zacznie powielać ten wzorzec wszędzie, więc każda kolejna funkcja odziedziczy ten sam bałagan co poprzednia.

I to jest prawdziwy powód, żeby zamówić drugą parę oczu wcześnie, w pierwszych tygodniach, a nie po pół roku. Ustaw przyzwoite wzorce na starcie, a AI będzie się ich trzymać; ustaw niedbałe, a wiernie odtworzy je w tych fragmentach aplikacji, których nawet nie kazałeś mu ruszać.

Dlaczego lock-in platformy ma znaczenie?

Lock-in polega na tym, że rezygnacja z platformy jest celowo utrudniona i kosztowna. Kiedy Twoja aplikacja już na niej działa i zaczyna przynosić efekty, platforma ma interes w tym, żeby przeniesienie się gdzie indziej było drogie, a pozostanie na miejscu wcale nie tanie.

Mechanizm zwykle wygląda tak:

Płacisz niską miesięczną opłatę i budujesz kolejne aplikacje, z których nikt nie korzysta. W końcu jedna zyskuje popularność, generuje realny ruch i mocno obciąża serwery platformy, a wtedy przewaga negocjacyjna przechodzi na jej stronę. Cena może wzrosnąć akurat w Twoim przypadku, a „bez limitu” z regulaminu okazuje się mieć górny pułap. Platforma cały czas kalkuluje jedno: ile może policzyć danemu klientowi, zanim przepisanie aplikacji od zera stanie się dla niego tańsze niż pozostanie.

Najwięcej problemów sprawia to, ile danych i kodu faktycznie można zabrać ze sobą przy odejściu. Jeden z założycieli, z którym pracowaliśmy, zbudował aplikację na hostowanym kreatorze, zdobył realny ruch, a przy próbie eksportu okazało się, że może pobrać frontend, ale już nie backend aplikacji. Cały backend napisał agent platformy i nie było sposobu, żeby go wydostać. Founder zgłosił się do nas, żeby zbudować aplikację od nowa, bo platforma nie dawała innej drogi wyjścia.

Nie znaczy to, że tych platform należy unikać z zasady. Chodzi o to, by proporcjonalnie ocenić ryzyko względem tego, jak poważny jest projekt.

Kiedy lock-in naprawdę ma znaczenie?

Jeśli tworzysz aplikację na własny użytek albo prostą aplikację do planowania posiłków dla rodziny, lock-in nie ma żadnego znaczenia i możesz wybrać najprostsze rozwiązanie. Sytuacja zmienia się, gdy planujesz rozwijać aplikację przez lata i inwestować w jej marketing. Wtedy platforma zdolna zablokować dostęp do Twojego backendu dokładnie w momencie, gdy projekt zaczyna odnosić sukces, staje się realnym ryzykiem biznesowym. Rośnie ono proporcjonalnie do tego, ile w ten projekt wkładasz.

Kiedy vibe coding wystarczy, a kiedy zadzwonić do software house’u?

To nie jest tak, że odradzamy vibe coding. Mówimy tylko, że metoda musi pasować do stawki, a większość sporów o to znika w chwili, gdy szczerze powiesz sobie, co właściwie budujesz.

Kiedy sam vibe wystarczy?

Przy sporej części projektów zatrudnianie kogokolwiek to wyrzucanie pieniędzy. Jeśli zbudujesz to sam i robi swoje, buduj sam. Proste przypadki:

1. Aplikacje, których używasz tylko Ty, na własnym komputerze lub telefonie, gdzie błąd nie pociąga za sobą żadnych konsekwencji.
2. Narzędzia wewnętrzne dla małego zespołu, który przeżyje sporadyczną usterkę.
3. Proof of concept, gdzie cały sens to sprawdzić, czy pomysł się broni, zanim się w niego zainwestuje.
4. Walidacja pomysłu, przetestowanie czegoś na kilku znajomych, zanim w grę wejdą prawdziwe pieniądze.

Pierwotne, jednorazowe podejście Karpathy’ego pasuje do każdego z tych przypadków, bo od początku było pomyślane na to, co szybkie i jednorazowe. Błąd pojawia się dopiero wtedy, gdy ktoś bierze tę samą jednorazową rzecz i celuje nią w płacących klientów.

Kiedy potrzebujesz realnego nadzoru?

W chwili, gdy z aplikacji korzystają prawdziwi użytkownicy, gdy dotyka ona danych osobowych, finansowych albo medycznych, albo staje się czymś, co zamierzasz sprzedawać lub skalować, rachunek się zmienia, a przegląd i uporządkowanie kodu staje się mniej więcej najtańszą polisą, jaką możesz kupić. My zwykle prowadzimy to w trzech krokach:

• Konsultacja. Krótka rozmowa, czasem bezpłatna, w której doświadczony programista patrzy na to, co masz, i mówi wprost, czy jest w porządku, czy wystarczy kilka poprawek, czy przyda się pełny audyt. Czasem szczera odpowiedź brzmi „zostaw, działa”, i partner z prawdziwego zdarzenia powie Ci to, zamiast wciskać usługę.
• Audyt. Konkretne sprawdzenia na Twoim kodzie: czy wytrzyma prawdziwy ruch, czy dane są dobrze zabezpieczone, gdzie może wyciekać. Aplikacja zbudowana w tydzień czy dwa to często kwestia kilku godzin. Rozrośnięty, półroczny projekt z milionami linii, których nikt do końca nie pamięta, potrafi zająć znacznie dłużej.
• Naprawa albo przepisanie. W zależności od tego, co wyjdzie w audycie, albo poprawiamy to, co jest, albo przepisujemy części nie do uratowania, czasem na tej samej technologii, czasem przenosząc je na coś, co znamy bardzo dobrze.

Jeśli masz zapamiętać jedno, to niech będzie to: im dłużej budujesz, sam nie wiedząc, co budujesz, tym większa szansa, że to wyrzucisz. Pokazanie tego komuś, póki aplikacja jest jeszcze mała, prawie zawsze wychodzi taniej niż rozplątywanie tego później. A jeśli Twój projekt urósł już do punktu, w którym nie masz pewności, że jest w porządku, to sygnał, żeby oddać go do przeglądu, zanim zaczniesz skalować.

FAQ – najczęstsze pytania dotyczące vibe codingu

Co to właściwie jest vibe coding?

Vibe coding to tworzenie oprogramowania poprzez opisywanie sztucznej inteligencji tego, czego się oczekuje, i przyjmowanie otrzymanego kodu bez jego przeglądania. Prompt formułujesz zwykłym językiem, uruchamiasz wynik, a ewentualne błędy przekazujesz z powrotem do poprawy. Kluczowe jest to, że nie czytasz kodu ani nie próbujesz go zrozumieć. Termin ukuł Andrej Karpathy w lutym 2025 roku na określenie właśnie tego bezpośredniego, eksperymentalnego sposobu pracy.

Dlaczego vibe coding zawiódł?

Nie zawiódł, raczej został źle użyty. Jako sposób na prototypowanie i eksperyment działa świetnie i jest dziś popularniejszy niż kiedykolwiek. Kłopoty zaczynają się, gdy ktoś bierze zvibecodowaną aplikację, której z definicji nikt nie sprawdził, i wypuszcza ją na produkcję do prawdziwych użytkowników. Wtedy naraz wychodzą pominięte przypadki brzegowe, brak zabezpieczeń i ukryte wycieki danych. Nawet Karpathy odszedł od tego terminu przy poważnej pracy, na rzecz ostrożniejszego, opartego na przeglądach podejścia, które nazywa agentic engineering.

Czy vibe coder to już prawdziwy zawód?

Poniekąd, choć nikt nie ma w wizytówce „vibe coder”. Płatna praca, która narasta wokół kodu z AI, wygląda raczej tak:

• Przegląd i utwardzanie aplikacji zbudowanych szybko, które teraz muszą być bezpieczne na produkcji.
• Audyt kodu pod kątem luk bezpieczeństwa i wycieków danych, których pierwotny twórca nie był w stanie zobaczyć.
• Projektowanie produktu i systemu, które zyskało na wartości właśnie dlatego, że pisanie kodu staniało.

Wspólny mianownik: pisanie kodu przestało być rzadką umiejętnością. Rzadka jest ocena tego kodu, jego zabezpieczanie i decyzja, co w ogóle zbudować.

Na ile poważny jest vibe coding?

Bardzo poważny jako technika, z realnymi ograniczeniami. Y Combinator podał, że 25% jego startupów z zimowej edycji 2025 działało na kodzie w 95% wygenerowanym przez AI, a mowa o finansowanych firmach wypuszczających produkty do prawdziwych użytkowników, nie o weekendowych amatorach. Pytanie nigdy nie brzmiało, czy AI potrafi budować oprogramowanie, bo najwyraźniej potrafi. Pytanie brzmi, czy dana aplikacja dostała przegląd, zabezpieczenia i testy, których wymaga produkcja, czy skończyło się na samym vibie.

Czy vibe coding jest bezpieczny dla aplikacji produkcyjnych?

Sam z siebie nie. Zvibecodowana aplikacja jak najbardziej może dojrzeć do produkcji, tyle że nie wtedy, kiedy jest jeszcze wyłącznie zvibecodowana:

• Dobra wiadomość: narzędzie AI do vibe codingu potrafi napisać bezpieczny, przetestowany, produkcyjny kod, kiedy się mu to poleci.
• Haczyk: trzeba mu to polecić, a osoby nietechniczne rzadko wiedzą, o co poprosić.
• Rozwiązanie: audyt przed startem, obejmujący bezpieczeństwo, dostęp do danych, obciążenie ruchem i przypadki brzegowe, które pierwsza wersja pominęła.

Przy czymkolwiek z prawdziwymi użytkownikami albo wrażliwymi danymi potraktuj działający prototyp jako punkt wyjścia i oddaj go do przeglądu oraz utwardzenia, zanim trafi na produkcję.