Vibe coding: programistą nie zostałem, a stronę mam
Stronę, na której czytasz ten tekst, zrobił mi Codex, czyli asystent AI od OpenAI, który pisze kod.
A skończyłem podyplomówkę z frontendu. Prowadziłem Developer Wannabe, czyli podcast dla uczących się programowania. W 2022 roku napisałem nawet na blogu: „Gdybym nie był podcasterem, chciałbym zostać programistą-podróżnikiem”.
Programistą nie zostałem. Naukę programowania i bloga o programowaniu zaliczam dziś do swoich nieudanych prób. Codex dłubie przy tej stronie dalej, a teksty piszę z Claude'em. Na końcu zawsze jest jednak człowiek: nic tu nie trafia, dopóki tego nie zatwierdzę.
Przed jednym z warsztatów w Szkole Praktyków AI, programie Youniversity, w którym uczę, powiedziałem, że bawię się obecnie oprogramowaniem vibe kodingowym. Dziś można bez nauki programowania zrobić aplikację w wieczór, dwa, pokazać ją zespołowi i wszystko wygląda świetnie.
Mnie najbardziej ciekawi, co się dzieje po tych dwóch wieczorach.
Co Karpathy nazwał vibe codingiem
Mówisz modelowi AI, jaką aplikację chcesz, a on pisze kod. Uruchamiasz, patrzysz, mówisz, co nie gra, a on poprawia. W kodzie nie grzebiesz i często nawet go nie czytasz.
Nazwę wymyślił Andrej Karpathy, współzałożyciel OpenAI. W lutym 2025 roku napisał o nowym rodzaju kodowania, w którym „zapominasz, że kod w ogóle istnieje”. Mówi do edytora przez SuperWhisper (też dyktuję). Prosi o najgłupsze rzeczy, na przykład o zmniejszenie odstępów w pasku bocznym o połowę, bo jest zbyt leniwy, żeby je znaleźć. Zawsze klika „Accept All”, czyli „zatwierdź wszystko”, a komunikaty o błędach wkleja bez komentarza.
I dodaje, że przy jednorazowych projektach na weekend nie jest to najgorsze.
Dziewięć miesięcy później „vibe coding” zostało słowem roku słownika Collinsa, który opisuje to jako zamienianie języka naturalnego w kod komputerowy. Mnie takie rzeczy jarają. Termin „język naturalny” znam z językoznawstwa, informatycy używają go od dekad, a w 2025 roku trafił do opisu słowa roku.
Nie znam na to dobrego polskiego słowa. Ja bym powiedział: programowanie na YOLO (you only live once, czyli raz się żyje).
Vibe coding a programowanie z pomocą AI
Te dwie rzeczy w rozmowach często się zlewają.
Simon Willison, programista, który dużo o tym pisze, postawił w marcu 2025 roku prostą granicę. Vibe coding to budowanie oprogramowania z modelem bez przeglądania kodu, który ten model napisał. Zawodowy programista też korzysta z Cursora czy Claude Code, ale jego praca wygląda inaczej. Willison wylicza, czego się od programisty wymaga: ma pisać kod, o którym umie pokazać, że działa, który inni ludzie rozumieją i który da się dalej rozwijać.
Ja jestem po tej pierwszej stronie. Nie mam umiejętności programistycznych, więc np. utrzymywanie takiej aplikacji byłoby dla mnie trudne, a programu od środka nie ocenię.
OWASP to organizacja, która od lat opisuje, co w bezpieczeństwie aplikacji może się popsuć. W swojej ściądze o kodowaniu z AI pisze, że za kod wygenerowany przez AI musi odpowiadać człowiek, bo narzędzia AI odpowiedzialności nie biorą. Gdy aplikację zrobi Ci programista z AI, wiadomo, kto ją rozumie i kto za nią odpowiada. A jak zrobi ją w dwa wieczory kolega z marketingu, to ja bym o to zapytał.
Czy vibe coding zastąpi programistów
Nie wiem. Około pięciu lat pracowałem w marketingu w IT i przy podcastach o programowaniu, ale programistą nie zostałem, więc niech odpowiedzą programiści. Ja jestem przekonany, że współpraca ja + AI jest lepsza niż AI zrobi wszystko za mnie.
Aplikacja z weekendu za pół roku
Firmowa aplikacja rzadko jest jednorazowa. Jak już działa, ludzie zaczynają na niej polegać.
Przykład zmyślony, ale całkiem możliwy: kolega z operacji robi narzędzie, które przepisuje zadania do Monday. Działa od pół roku, wszyscy zadowoleni. Potem kolega zmienia pracę. Po jakimś czasie zadania przestają się aktualizować i nikt nie wie, gdzie zajrzeć.
Sam Monday akurat nikogo nie zaskakuje. Nowa wersja API, czyli sposobu, w jaki łączą się z nim inne programy, wychodzi co kwartał, a wycofanie starej zapowiada z co najmniej półrocznym wyprzedzeniem. Aktualizacja wcale nie musi niczego popsuć.
Tylko że ktoś musi przeczytać komunikat, zrozumieć go i coś z tym zrobić. Jeżeli jedyna osoba, która wiedziała, jak to działa, pracuje już gdzie indziej, a kod napisał model, to nikt tego szybko nie naprawi.
Zanim takie narzędzie wejdzie do codziennej pracy, warto znać odpowiedź na trzy pytania. Kto się nim opiekuje? Co robimy, gdy przestanie działać? Jak wracamy do pracy ręcznej?
Rachunek też wychodzi inny, niż się wydaje. Pierwszy dzień kosztuje wieczór i abonament, który i tak płacę. Kolejne miesiące to opłaty za narzędzia, z których aplikacja korzysta, i poprawki, gdy zacznie pomijać część zadań albo coś się zmieni w programie, z którym się łączy. Do tego godziny osoby, która to wszystko obsługuje.
Gdzie vibe coding może się wyłożyć
Na warsztacie w Szkole Praktyków AI uczestniczka pokazała CRM, który sama sobie zbudowała. Kalendarz podpięty, faktura rozbijana na zadania, PDF-y generowane same, role użytkowników poustawiane. Wszystko powstało z opisu, w narzędziu AI do tworzenia aplikacji. Naprawdę było na co popatrzeć.
Na tym warsztacie padło też, żeby bez zabezpieczeń nie przyjmować od klientów kart ani PESEL-i.
Na pokazie nie widać testów ani debugowania, czyli szukania, dlaczego coś nie działa. Nie widać też, gdzie te dane właściwie lądują i kto ma do nich dostęp. Nie jestem specjalistą od bezpieczeństwa, więc cytuję Veracode i OWASP.
Gramatyka się zgadza, a kod bywa dziurawy
Veracode od dłuższego czasu testuje kod pisany przez modele. W raporcie z lipca 2026 roku podaje, że składnia zgadza się niemal zawsze, a w testach bezpieczeństwa modele zawodzą w prawie 44% przypadków. Średni wynik, 56%, od roku praktycznie się nie rusza.
Biorę na to poprawkę, bo Veracode sprzedaje testy bezpieczeństwa. Tu dwa niuanse. Chodzi o zadania, w których nikt wprost nie poprosił modelu o bezpieczeństwo. I testowano same modele, bez agentów, dodatkowych narzędzi i przeglądu przez człowieka, więc kreator aplikacji może dać inny wynik. Tyle że kto prosi o bezpieczeństwo, gdy robi aplikację w wieczór?
Składnia to gramatyka kodu. Językoznawcy znają zdanie Chomsky'ego: „Bezbarwne zielone idee wściekle śpią”. Gramatyka bez zarzutu, sensu zero. Z kodem może być podobnie. To, że składnia się zgadza, nie mówi, czy program robi to, co trzeba, i czy nikogo nie wpuszcza tylnymi drzwiami.
Zmyślone słowa i złośliwe paczki
Asystenci kodowania często podsuwają nazwy paczek, czyli gotowych kawałków oprogramowania, których w ogóle nie ma. Model zmyśla słowo, które brzmi jak prawdziwe. Tyle że są ludzie, którzy wypatrują takich zmyślonych nazw i rejestrują pod nimi złośliwe paczki.
Programista może sprawdzić, czy paczka istnieje, jak długo i kto ją prowadzi, a przy „Accept All” nikt tego nie robi.
Model sam sobie stawia ocenę
Agenci AI, czyli programy, które same wykonują kolejne kroki, potrafią zaliczyć wszystkie testy sprawdzające, czy program działa. Kasują te, których nie zaliczają, albo obniżają poprzeczkę. Według OWASP, gdy testy pisze ten sam agent, który pisał kod, nikt z zewnątrz tego nie sprawdził.
Uczyłem przez pięć lat na uniwersytecie. Student, który sam sobie wycina z egzaminu trudne pytania, też ma same piątki.
Agent rusza więcej, niż mu kazałeś
OWASP opisuje też, że agenci regularnie ruszają pliki, których nikt im nie kazał ruszać, a człowiek sprawdza tylko to, co zlecił. Według tej samej ściągi agent do pisania kodu nie potrzebuje dostępu do maila, płatności ani narzędzi administracyjnych. A po drodze czyta opisy zgłoszeń, strony z internetu i pliki z dokumentacją, więc może trafić na coś, co potraktuje jak polecenie. Z dostępem do maila może wysłać coś, czego nikt od niego nie chciał.
Pięć pytań, zanim podłączysz aplikację do CRM
Gdyby ktoś pokazał mi aplikację zrobioną z AI i podpiętą do firmowego CRM, zadałbym pięć pytań. Może je zadać każdy właściciel firmy, nie trzeba znać się na programowaniu.
- Jakie dane aplikacja widzi? Wszystkich klientów czy tylko te pola, których potrzebuje do zadania?
- Co może zmienić sama, a co tylko proponuje? Szkic odpowiedzi, który człowiek czyta, to mała sprawa. Zmiana danych klienta bez niczyjej zgody już nie.
- Kto zatwierdza ważne decyzje? Z nazwiska. Gdybym usłyszał „zespół”, pytałbym dalej.
- Jak ją zatrzymać? Kto to zrobi, ile mu to zajmie i co się stanie z tym, co akurat było w trakcie?
- Gdzie leżą hasła i klucze API? Klucz API to po ludzku hasło, którym jeden program loguje się do drugiego. Jeśli siedzi w kodzie albo w dokumencie, do którego ma dostęp pół firmy, to niedobrze.
Te same pytania zadałbym, gdy aplikacja już stoi i korzysta z danych klientów. Jeśli nikt nie umie na nie odpowiedzieć, szukałbym szybko programisty, który ją utrzyma, albo firmy od testów bezpieczeństwa, tak zwanych testów penetracyjnych, bo sama lista bezpieczeństwa nie załatwi. Zapytałbym ich też, czy przejmą kod napisany przez model, czy wolą zacząć od nowa.
Czy w ogóle potrzebna jest aplikacja
Nauczono nas w szkole, po prusku, że jest jedna odpowiedź, za którą dostaje się piątkę. Przy vibe codingu tą odpowiedzią robi się aplikacja, bo da się ją zrobić w wieczór.
Zanim ktoś zacznie budować, zapytałbym o zadanie, dane i o to, co ma się poprawić w pracy zespołu. Weźmy zespół, który odpowiada na zapytania ofertowe i chce robić to szybciej. Czasem wystarczy dobrze ustawiony Claude albo ChatGPT i stały szablon odpowiedzi. Czasem narzędzie, którego już używacie, ma to w środku. Własna aplikacja bywa dopiero trzecim krokiem, a wtedy warto zapłacić komuś, kto ją potem utrzyma.
Vibe coding w firmie: co wolno na YOLO, a co już nie
Ułożyłbym to według tego, co się stanie, gdy się popsuje. Willison też pisze, że przy prototypach i projektach, na których niewiele można stracić, da się puścić to na żywioł.
- Dla siebie, bez cudzych danych. Licznik, strona, mały skrypt, prototyp do pokazania zespołowi albo programiście. Jak się popsuje, nic nie wybuchnie. Tu można na YOLO. Od tego bym zaczął.
- Dla zespołu, bez danych klientów. Tu dochodzą kopie przed zmianami, plik z zasadami dla modelu i odpowiedź, kto się tym zajmuje, gdy autor jest na urlopie.
- Dane klientów, pieniądze albo zmiany w firmowych systemach. Tu vibe coding wystarczy na działający pokaz, z którym możesz iść do programisty. Dalej idzie już ktoś, kto rozumie kod i umie go zabezpieczyć.
„Nie bójcie się eksperymentować, to nie boli i nic nie zepsujecie”. Tak bym powiedział każdemu, ale przy vibe codingu tylko wtedy, gdy nie ma cudzych danych. Przy danych klientów zepsuć się da.
W czym się robi vibe coding
Kiedy coś buduję, pracuję w Claude Code i w Codexie, a do tego na czacie. Cursora i kreatory aplikacji znam z cudzych opisów, bo ich nie potrzebuję. Rozdzielam je sobie na grupy:
- Asystenci, którzy pracują na plikach na Twoim komputerze. Claude Code, Codex, Cursor. Dajesz im folder i zadanie, a oni sami czytają, piszą i uruchamiają.
- Kreatory aplikacji. Lovable, Replit, Base44. Opisujesz, co ma powstać, i po chwili masz coś, co się klika.
- Zwykły czat. Claude albo ChatGPT potrafią napisać prostą stronę czy skrypt, a Ty przeklejasz wynik.
Co sobie zrobiłem i co mi grozi
Pierwszy szkic tej strony powstał w Codexie w połowie października, a dzień po kupnie domeny strona była już w sieci. Kiedy coś hurtem skasowało duże pliki w MacWhisperze, moim programie do transkrypcji, Claude znalazł w raportach o awariach, czego brakuje, i napisał skrypt, który to dociąga.
Przy tej stronie niewiele ryzykuję. Nie ma tu logowania, bazy klientów ani formularza. Rezerwację i ankietę przed rozmową obsługuje TidyCal, a kontakt idzie zwykłym mailem. Jeśli strona się wysypie, będzie mi głupio i przez chwilę nikt się nie umówi.
A i tak już przy takiej prostej stronie trzeba było ogarnąć trzy rzeczy.
Mam klucz API do jednego z narzędzi, których używam przy tekstach. Pliki w folderze strony na serwerze może otworzyć każdy, kto trafi na właściwy adres, więc klucz leży osobno, poza tym, co idzie na serwer.
Do tego stare kopie: w folderze roboczym leży kilka starych wersji głównego pliku, a na serwer strona idzie bez nich.
I zasady, bo nad tą stroną pracują dwa modele i ja. Plik w folderze mówi, gdzie co trafia, czego nie wolno ruszać bez mojej prośby i jak wygląda publikacja. Hasła do serwera nie wolno zapisywać w żadnym pliku projektu.
Jak rozmawiam z modelem, gdy coś buduję
„Kawkę czy herbatkę?”, pytała babcia. „Obojętnie, babciu”. „A to dostaniesz”. Nauczyłem się być zdecydowanym chłopcem, bo się bałem, że dostanę to pośrodku.
Model przy poleceniu „zrób mi aplikację do zadań” zachowuje się jak moja babcia. Skoro Ci obojętnie, to dostaniesz to, co sam wybierze. Dlatego na warsztacie powiedziałem: hulaj dusza, piekła nie ma, daj mu mnóstwo detali. Co dokładnie ma powstać, dla kogo, w jakiej formie i po czym poznam, że jest dobrze.
Potem zaczyna się marudzenie, czyli mówienie modelowi, co jest nie tak. Piszę o nim więcej w tekście o ChatGPT w firmie.
Masz w firmie aplikację zrobioną w dwa wieczory albo ktoś właśnie o niej myśli? Pogadajmy o tym przez 30 minut, bezpłatnie. Kod i zabezpieczenia zostawiam specjalistom, a z Tobą usiądę nad zadaniem, danymi i tym, co ma się poprawić.