Wstęp#
Jeszcze trzy-cztery lata temu (2022 - premiera ChatGPT) napisanie sensownego backendu było żmudnym procesem. Nie dlatego, że brakowało frameworków, bibliotek czy narzędzi. Wszystko było. Nieważne. Problem leżał w czasie i skupieniu. Trzeba było ręcznie tworzyć modele, endpointy, walidację itd. Innymi słowy: dużo powtarzalnej pracy i dużo kodu, który sam w sobie nie był trudny ani szczególnie kreatywny (chyba że robisz coś naprawdę niestandardowego).
Dziś ten sam backend można zbudować w ułamku tego czasu. Nie dlatego, że programiści nagle stali się szybsi albo dostali implant Neuralink. Po prostu pojawiło się coś... nowego obok nas.
Sztuczna inteligencja w obecnej formie nie jest nawet blisko pełnej "inteligencji" w sensie AGI. Nie myśli jak człowiek. Nie rozumie problemów. Ten post to świetnie ilustruje:
ALE jest coś, w czym AI może być dobre: kodowanie. Podczas trenowania modeli LLM do ich głów wylądowały absurdalne ilości kodu - posty ze Stack Overflow, repozytoria z GitHub i masa innych źródeł.
Dlatego modele LLM świetnie radzą sobie z tym, co dla ludzi jest nudne i powtarzalne. Syntetyzują wzorce. Składają fragmenty w sensowną całość. W praktyce oznacza to generowanie struktur projektów, API, zapytań do bazy czy testów. Programista coraz rzadziej pisze kod linijka po linijce, a coraz częściej dyktuje "komuś", co trzeba zrobić.
Ten tekst więc nie jest o tym, czy AI zastąpi programistów w sensie technicznym. Jest o tym, których programistów na pewno zastąpi i dlaczego vibecoding może być zarówno największym akceleratorem kariery, jak i najszybszą drogą do zawodowej stagnacji.
Problemy z tym związane#
Wraz z tym podejściem pojawiły się komplikacje. Każda potężna technologia, trafiając w niewłaściwe ręce, prędzej czy później zaczyna szkodzić. Czasem bardzo konkretnie. Klasyczny przykład to Alfred Nobel, który wynalazł dynamit, żeby zrewolucjonizować przemysł i górnictwo. Szybko okazało się jednak, że jego wynalazek świetnie nadaje się też do zabijania ludzi.
Podobnie jest z AI. (Dobra, jeszcze nas nie zabijają).
Jeśli ktoś, kto nigdy nie widział kodu na własne oczy, zacznie "vibecodować", wypuści aplikację na szerszą publiczność, a ta zyska popularność, prędzej czy później coś pójdzie nie tak. Wyciekną dane osobowe. Wyciekną ZDJĘCIA DOWODÓW (jak w aferze bezpieczeństwa aplikacji Tea). Numery kart kredytowych. Hasła. Wszystko, co aplikacja kiedykolwiek zebrała.
Dlaczego? Bo sztuczna inteligencja nie bierze odpowiedzialności za dług techniczny, luki bezpieczeństwa ani przyszłą skalowalność systemu. Nie utrzymuje aplikacji.
Programowanie przestało polegać na pisaniu kodu#
Największą zmianą, jaką przyniosło AI, nie jest to, że kod pisze się szybciej. To tylko efekt uboczny. Prawdziwa zmiana polega na tym, że pisanie kodu przestało być najtrudniejszą częścią programowania.
Dziś problemem nie jest jak coś zaimplementować. Problemem jest to, co w ogóle zaimplementować, w jaki sposób i z jakimi konsekwencjami. Architektura, bezpieczeństwo, przepływ danych, granice odpowiedzialności systemu. AI tego za ciebie nie ogarnie, nawet jeśli wygeneruje bardzo ładne pliki.
Dlatego vibecoding świetnie działa w rękach ludzi, którzy już wiedzą, co robią. I dlatego jest całkowicie niebezpieczny w rękach tych, którzy traktują go jak magiczną maszynę do robienia aplikacji. AI nie zastępuje programisty. AI zmusza programistę, żeby przestał być tylko wykonawcą.
Skoro kod przestał być problemem, czas porozmawiać o tym, co jest problemem teraz.
Vibecoding#
Vibecoding to styl pracy, w którym programista przestaje być maszyną do pisania kodu i zaczyna być czymś w rodzaju dyrygenta. Opisuje problem, wyznacza kierunek, poprawia detale, iteruje. Kod powstaje szybciej, bo dużą część mechanicznej pracy przejmuje AI. I równie szybko znika gotówka (30 USD/m tokenów wejściowych i 180 USD/m tokenów wyjściowych dla GPT-5.5 Pro).
Zamiast pisać linie kodu, piszesz prompty używając Claude Code'a, Cursor'a i podobnych narzędzi. Samo w sobie to nie jest złe. Wręcz przeciwnie. Problem zaczyna się w momencie, gdy vibecoding przestaje być wsparciem, a zaczyna być zamiennikiem. Gdy zamiast przyspieszać proces myślenia, zaczyna go wypierać. A co gorsza - robi to bardzo cicho, bez czerwonych flag na starcie.
Rodzaje vibecodingu#
Nie każdy vibecoding wygląda tak samo. To nie jest binarny podział "używasz AI / nie używasz AI". Różnica zaczyna się od tego, kto podejmuje decyzje i kto rozumie konsekwencje. Można wyróżnić kilka poziomów (według mnie - pewnie znajdą się tacy, którzy się nie zgodzą).
Lekki vibecoding#
Programista wie, co robi. Analizuje kod, dokładnie patrzy, co tworzy AI. Potrafi sam coś napisać, zmienić, naprawić, zdebugować wadliwy fragment (co, z mojego doświadczenia, jest bardzo częste, praktycznie nieuniknione). AI działa tu jak narzędzie. Kod powstaje szybciej, ale odpowiedzialność zostaje po stronie człowieka.
Prompt nie zastępuje wiedzy, tylko skraca drogę do efektu, który i tak dałoby się osiągnąć samodzielnie. Zwykle w grę wchodzi jakaś subskrypcja narzędzia (plan podstawowy w zupełności wystarcza). Sam mam plan Pro w Cursorze, więc chyba wpiszę się w tę kategorię.
To najbezpieczniejsza forma vibecodingu, bo nie zmienia fundamentów pracy. Nadal wiesz:
- gdzie są granice systemu,
- które fragmenty są krytyczne,
- co może się wywalić i dlaczego.
Jedyna różnica: nie marnujesz czasu na powtarzalne rzeczy.
W praktyce lekki vibecoding rozpoznasz po jednym prostym sygnale: jeśli AI nagle zniknie, projekt będzie bolał, ale nie umrze.
Problem w tym, że ten poziom bardzo łatwo przekroczyć. I często nie zauważysz momentu, w którym lekki vibecoding zamienia się w coś znacznie gorszego.
Umiarkowany vibecoding#
Tu vibecoding zaczyna być niebezpiecznie wygodny. Programista nadal ogarnia podstawy i potrafi coś naprawić, jak przy lekkim vibecodingu. Problem w tym, że robi to coraz rzadziej. Skoro AI generuje kod szybciej, po co się męczyć?
Analiza kodu nadal istnieje, ale stopniowo zanika. Skoro testy przechodzą i aplikacja działa lokalnie, leci dalej. Debugging staje się reaktywny - jeśli coś się psuje, naprawia. Jeśli działa, nie grzebie.
Na tym etapie zaczynają się typowe objawy:
- architektura jest "jakoś zrobiona",
- bezpieczeństwo odkładane jest "na później",
- dług techniczny rośnie w zawrotnym tempie.
Umiarkowany vibecoding jest podstępny, bo przez długi czas wszystko wygląda dobrze. Projekt się rozwija, funkcje lądują szybko. Problem pojawia się dopiero, gdy trzeba coś zmienić albo przebudować. Nagle okazuje się, że twórca nie do końca wie, co tam się dzieje, i często nie potrafi wyjaśnić logiki (chyba że AI zostawiło komentarz).
W praktyce ten stan rozpoznasz po tym, że bez AI praca mogłaby trwać dalej, ale zajęłaby znacznie więcej czasu i byłaby znacznie bardziej bolesna, niż powinna.
To moment, w którym bardzo łatwo zrobić kolejny krok. I bardzo trudno z niego zawrócić - szczególnie dla osób nietechnicznych.
Pełny vibecoding#
Tu człowiek nawet nie wie, czym jest edytor tekstu (albo IDE). Po co się męczyć, skoro są narzędzia, które "zrobią wszystko"? v0.dev, Bolt, Lovable, agenci CLI. Frontend, backend, baza, auth, deploy. Klik, klik i gotowe.
Nie musisz znać stacku ani architektury. Nie musisz nawet siedzieć przy komputerze. Wrzucasz opis MVP, chwilę czekasz i wypuszczasz kolejne wersje. Pełna jazda bez trzymania kierownicy.
Na początku jest fajnie. Bardzo fajnie - trochę jak na dragach. Po kilkunastu promptach masz coś, co wygląda jak produkt. Wszystko działa, UI jest ładne. Wszystko solo, bez zespołu (chyba że liczysz AI).
A potem przychodzi rachunek.
Plany za 200 USD miesięcznie, tokeny lecą jak szalone. Ale to nie problem - twoja aplikacja zaraz wygeneruje ogromne przychody.
Prawdziwy problem jest inny. W ogóle nie analizujesz już kodu. Po co, skoro masz kilku agentów AI: jeden generuje projekt, drugi debuguje, trzeci "refaktoruje", a czwarty liczy zyski i kupuje prywatne jachty (przecież twoje dziesięć aplikacji w App Store odniosło spektakularny sukces).
Nie bez powodu na początku tej sekcji pada słowo "człowiek", a nie "programista". Bo gdzie tu programista, skoro jedyną rzeczą, którą się pisze, są prompty, a nie linie kodu?
Dobre strony vibecodingu#
A co najlepsze? Może nie dla ciebie, ale dla pentesterów, którzy tylko czekają na takie w pełni vibe-coded aplikacje. Spokojnie, i tak im zapłacisz. Albo nie.
Bo bardzo często żaden pentester do ciebie nie zgłosi. Obudzisz się z wyciekiem bazy, bo jakiś zły aktor wykorzystał lukę i zrobił dokładnie to, co chciał.
Najczęściej to nie są egzotyczne podatności. Żadnych 0-dayów, żadnej czarnej magii. To najprostsze, najbardziej kliszowane błędy, które każdy ogarnięty widział setki razy.
Brak autoryzacji na endpointach, które "miały być wewnętrzne". Endpoint działa, ale nikt nie dodał sprawdzania ról. Efekt? Zwykły użytkownik może pobrać cudze dane. Czasem wszystkie naraz.
Dlatego pełny vibecoding to złoto nie tylko dla pentesterów, ale przede wszystkim dla ludzi bez zasad etycznych, którzy nie zamierzają pisać do ciebie maila. Nie chcą bug bounty. Chcą danych. Albo dostępu. Albo po prostu sprawdzić, ile mogą zepsuć.
Dobra, może są jakieś dobre strony (dla vibecoderów). Pierwsza: projekty prywatne. Jeśli robisz coś tylko dla siebie, żeby ułatwić sobie życie, zautomatyzować jakąś głupotę, narzędzie do własnego użytku - vibecoding może być złotem. Nikogo nie narażasz.
Druga: prototypy i proof of concept. Chcesz sprawdzić, czy coś w ogóle ma sens. Czy pomysł nie jest totalną bzdurą. Vibecoding pozwala to zrobić w jeden wieczór, co kiedyś zajmowało tydzień. I to jest super.
Na tym zalety się kończą. Dobre strony kończą się tam, gdzie zaczyna się zbieranie wrażliwych danych. Mówiąc wprost - vibecoding jest super, dopóki jedyną osobą, którą możesz skrzywdzić, jesteś ty (chyba że jesteś prawdziwym mężczyzną i dasz radę z wyciekiem egoistą i nie obchodzi cię, jak cudze dane wyciekają z twojej aplikacji).
Nauka programowania vs AI (albo jak nie strzelić sobie w stopę)#
Jeśli dopiero uczysz się programować, powiem wprost: nie polecam używać AI jako głównego narzędzia do nauki. Nie dlatego, że "AI jest złe" albo że trzeba cierpieć, żeby się uczyć. Po prostu bardzo łatwo nauczyć się dokładnie... niczego.
Programowanie to nie pisanie kodu. Kod to tylko notacja.
Programowanie to właściwie:
- zrozumienie problemu,
- umiejętność rozłożenia go na części,
- wiedza, co ma się wydarzyć, w jakiej kolejności i dlaczego,
- i dopiero na końcu napisanie kodu w jakimś języku.
Ten proces powinien najpierw dziać się w twojej głowie. Ewentualnie na papierze. Możesz nawet pogadać z kaczką. Diagram, pseudokod, kilka zdań opisujących logikę. Dopiero potem edytor.
AI robi dokładnie odwrotnie. Dostajesz gotowy kod, który działa. I to jest największy problem. Bo skoro działa, po co się zagłębiać? Po co zastanawiać się, dlaczego jest tak, a nie inaczej. Po co próbować samemu. W efekcie uczysz się promptowania, a nie programowania.
Ale gdy zapytasz: dlaczego to działa albo co się stanie, jeśli zmienimy X, nagle robi się cicho.
Jeśli uczysz się kodować, musisz przez chwilę się pomęczyć. Musisz popełnić głupie błędy. Musisz napisać coś źle, a potem to naprawić. Musisz spędzić pół godziny na bugu, który okazuje się literówką albo źle postawionym warunkiem. To dokładnie moment, w którym w głowie buduje się logika.
Bo jeśli nie masz tej wewnętrznej mapy logiki, vibecoding nie zrobi z ciebie programisty. Zrobi z ciebie użytkownika narzędzia, które w pewnym momencie przestanie wystarczać.
I wracamy do początku tego tekstu: AI nie zastąpi programistów. Zastąpi tych, którzy nigdy nimi nie zostali.
Których programistów AI na pewno zastąpi#
I czy zastąpi? Wątpię. Może. Ale nie teraz.
Jeśli już, to nie wszystkich. I nie "programistów" jako takich. AI zastąpi bardzo konkretne typy ludzi. Tych, którzy już dziś są na granicy zbędności.
-
Zastąpi programistów, którzy nie potrafią samodzielnie rozwiązywać problemów. Ludzi, którzy latami jeździli na "znajomości danego frameworka" - uczyli się wzorców na pamięć, nie wiedząc, jak działają, podążając tylko za tutorialami. Bez refleksji.
-
Zastąpi vibecoderów, którzy outsourcowali całe myślenie do AI. Nie tych, którzy używają AI jako narzędzia. Tylko tych, którzy bez niego nie są w stanie zrobić niczego. Jeśli projekt przestaje istnieć w momencie, gdy model ma przerwę techniczną, to nie był projekt.
I tyle. Chociaż... może AI zastąpi też mnie? I ciebie? I nas wszystkich? Mam plan na taki wypadek. Założę hodowlę krewetek. A ty?
