Vibe Coder vs Software Engineer – nowa wojna światów?

Ostatnio pisałem dość poważnie – we wpisie Programista w czasach AI królowały dane, liczby, wykresy. Dziś sobota, więc będzie lżej, weekendowo i z memami 🙂

Memów o vibe coderach krąży po sieci sporo. Większość w podobnym schemacie: po lewej radosny chaos, po prawej uporządkowany inżynier. Tak jak na okładce – Morty z kłębowiskiem kabli pod biurkiem, a obok Rick ze stosem książek i szafą, której nie powstydziłby się żaden admin.

Śmieszne? A jakże! Ale również – jak każdy dobry mem – trochę prawdziwe.

Skąd się wziął ten cały vibe coder?

Termin jest zaskakująco młody. W lutym 2025 roku Andrej Karpathy (współzałożyciel OpenAI, wcześniej szef AI w Tesli) opisał na X nowy sposób programowania, w którym „poddajesz się vibe’om” i zapominasz, że kod w ogóle istnieje. Mówisz, czego chcesz, AI pisze, Ty akceptujesz, a jak coś nie działa – wklejasz błąd z powrotem bez komentarza i zwykle samo się naprawia. Kilka miesięcy później słownik Collinsa ogłosił „vibe coding” słowem roku 2025. Tak szybko jak to określenie żaden framework JS jeszcze się nie przyjął…

I nie ma się co dziwić. Jeszcze kilka lat temu, żeby zrobić aplikację, trzeba było nauczyć się programować. Dziś wystarczy przeglądarka, subskrypcja za kilkadziesiąt złotych miesięcznie i pomysł. Bariera wejścia spadła praktycznie do zera.

Czy naprawdę każdy może teraz tworzyć oprogramowanie?

Może. I uczciwie mówiąc – to jest fajne. Florysta może sobie zrobić kalkulator wyceny, księgowa skrypt do porządkowania faktur, a nauczyciel quiz dla klasy. Bez czekania na budżet, przetarg i programistę, który i tak ma na głowie 3 inne projekty. Programowanie przestało być wiedzą tajemną – i dobrze.

Tylko że z tym „może” jest jak z wiertarką udarową. Każdy może ją kupić w markecie budowlanym i każdy wywierci nią dziurę w ścianie. Nie znaczy to jednak, że każdy powinien sam sobie robić instalację elektryczną w domu. Dziura w ścianie to efekt widoczny od razu. Przewód, który grzeje się w puszce, da o sobie znać po roku.

Z oprogramowaniem jest dokładnie tak samo. Quiz dla klasy, który padnie w środku lekcji? Trudno, będzie śmiesznie. Sklep z płatnościami i danymi klientów, który padnie w Black Friday? Już mniej śmiesznie. A jeśli przy okazji wyciekną dane – to już kończą się żarty, bo wjeżdża RODO.

Frontend plus backend – i gotowe?

Ten mem lubię szczególnie, bo jest najbardziej bolesny. Z perspektywy vibe codera aplikacja to 2 klocki: coś, co widać, i coś, co gdzieś tam zapisuje dane. Rzeczywistość ma tych klocków kilkanaście, a każdy z nich to osobna kategoria problemów, o których dowiadujemy się zwykle w najmniej odpowiednim momencie:

• Auth & Permissions – czyli czy klient A widzi faktury klienta B (odpowiedź „chyba nie” nie jest odpowiedzią)
• Rate Limiting – nie istnieje, dopóki jakiś bot nie zrobi w nocy 10 tysięcy requestów
• Error Tracking & Logs – skąd wiesz, że coś nie działa? Bo klient napisał na Messengerze…
• Availability & Recovery – są 2 rodzaje ludzi: ci, którzy robią backupy, i ci, którzy dopiero będą je robić

Przy budowie Florino – SaaS-a, o którym pisałem na początku miesiąca – większość z tych warstw musiałem świadomie zaplanować: Neon, Vercel, kolejka QStash, Sentry, Better Auth, testy, CI. I wiecie co? Nawet mimo planu, testów i pipeline’u lipcowy audyt pokazał, że crony przez 2 miesiące nie uruchomiły się ani razu, a ceny usług przychodziły prosto z przeglądarki. Jeśli tak potrafi się wyłożyć ktoś, kto o tych warstwach wie – to co dopiero ktoś, kto nie wie, że one w ogóle istnieją?

AI zrobi dokładnie to, o co poprosisz. Problem w tym, że nie zrobi tego, o co nie przyszło Ci do głowy poprosić.

Rakieta stoi. Tylko na czym?

Na demo, na prezentacji dla inwestora, na zrzucie ekranu wrzuconym na LinkedIna – obu rakiet nie da się odróżnić. Różnica jest pod ziemią: z jednej strony „Quick fixes”, „No structure”, „Spaghetti code” i mój faworyt – „Works somehow”. Z drugiej porządna konstrukcja z dopiskiem „Built for the long run”.

I tu dochodzimy do największej pułapki vibe codingu: projekt działa. Do pierwszej awarii. Albo do pierwszego większego ruchu. Albo do pierwszej zmiany, która wymaga zrozumienia, jak to wszystko jest ze sobą połączone. Wtedy zaczyna się wklejanie błędów do czatu, AI dokleja kolejny kawałek taśmy, który naprawia jedno, a psuje dwa inne… i tak w kółko. A najgorsze, że nikt – ani autor, ani AI – nie pamięta już, po co ten kabel tam jest.

Żeby było uczciwie – karteczki „TEMP” i „ADD LATER” z okładki to nie jest wynalazek ery AI. Przez ponad 20 lat w branży widziałem w kodzie więcej komentarzy // TODO: poprawić później, niż jestem w stanie zliczyć. Tyle że kiedyś na takie spaghetti trzeba było pracować miesiącami. Dziś da się je wygenerować w jedno popołudnie…

No dobra, a gdzie vibe coding ma sens?

Wbrew pozorom – w wielu miejscach. Szybki POC, sprawdzenie, czy pomysł się obroni, prototyp do pokazania klientowi, prosta strona do zbadania rynku, jednorazowy skrypt, narzędzie tylko dla siebie. Wszędzie tam, gdzie liczy się czas, a koszt porażki jest bliski zeru.

Żeby sprawdzić, czy ktokolwiek chce polecieć w kosmos, nie muszę od razu budować stanowiska startowego jak w NASA. Wystarczy kartonowa rakieta i ogłoszenie „zapisy na lot”. Jak zapisze się 0 osób – oszczędziłem sobie miesięcy pracy. Jak zapisze się 1000 – no to teraz warto pomyśleć o fundamentach. Zresztą Florino też nie zaczęło się od architektury multi-tenant, tylko od zwykłego formularza na stronie flora-art.pl, który miał rozwiązać nasz własny problem – i od ankiety wśród florystów.

Kłopot zaczyna się wtedy, gdy kartonowa rakieta dostaje pasażerów, bo „przecież działa”. A wiadomo – w IT nie ma nic trwalszego niż rozwiązanie tymczasowe.

To kim w końcu jestem ja?

I tu robi się ciekawie, bo sam od miesięcy prawie nie piszę kodu ręcznie. We Florino 89% merytorycznych commitów ma dopisek Co-Authored-By: Claude, a ten blog po przeprowadzce z WordPressa na Nuxta powstawał dokładnie tak samo. Formalnie więc mówię do AI, czego chcę, a ono pisze. Czy to znaczy, że jestem vibe coderem?

Moim zdaniem nie. Różnica nie leży w tym, kto stuka w klawiaturę, tylko w tym, kto rozumie, co powstaje – i kto bierze za to odpowiedzialność. Karpathy w swojej definicji kazał zapomnieć, że kod w ogóle istnieje. Ja o nim nie zapominam ani na chwilę. Zanim AI napisze pierwszą linijkę, jest analiza, plan, architektura, dobrane narzędzia i zasady: TypeScript strict, walidacja na serwerze, testy, lint, review. Oczywiście nie znaczy to, że czytam każdą linijkę kodu, ale mocno pilnuję, jak AI rozwiązuje problem i w którą stronę idzie projekt. Klawiaturę oddałem, odpowiedzialności – nie.

Rick też ma swoje za uszami

Żeby nie było, że to wpis o tym, jacy inżynierowie są wspaniali. Podejście inżynierskie ma swoje pułapki – i wcale nie są mniej kosztowne.

Ten mem zwykle krąży jako przytyk pod adresem zarządów, które chcą „wdrożyć AI”, tylko nie bardzo wiedzą po co. Ale spróbujcie podmienić CEO na inżynierów, a AI na ulubioną technologię:

Kim jesteśmy? Inżynierami!

Czego chcemy? Mikroserwisów, Kubernetesa i 100% pokrycia testami!

Po co? Nie wiemy!

Nic Wam to nie przypomina? To przecież lustrzane odbicie vibe codingu. Perfekcyjna architektura dla produktu, którego nikt nie chce. Skalowanie na milion użytkowników, gdy jest ich 12. Wieczne „jeszcze tylko zrefaktoruję ten moduł”, „jeszcze tylko podbiję wersję frameworka”, „jeszcze tylko dopiszę testy do edge case’ów, które nigdy nie wystąpią”. A każda dodatkowa warstwa kosztuje – czas, pieniądze i cierpliwość kogoś, kto czeka na działający produkt.

Ktoś złośliwy mógłby zauważyć, że ten blog przez lata świetnie działał na WordPressie, a ja przeniosłem go na Nuxta z Postgresem, Redisem, kolejką zadań i Turnstile’em przy komentarzach. Cóż – punkt widzenia zależy od punktu siedzenia. Ja to nazywam poligonem doświadczalnym…

A tak na poważnie – przy Florino technologia przestała być ryzykiem po około 2 tygodniach. Najtrudniejsze okazało się coś zupełnie innego: znalezienie i wdrożenie pierwszych klientów. Nawet najlepsza architektura nie sprzeda za mnie produktu.

Kiedy kod jest „wystarczająco dobry”?

Jak zwykle odpowiedź brzmi: to zależy. Gotowego wzoru nie mam, ale mam kilka pytań, które zadaję sobie coraz częściej:

• kto będzie z tego korzystał – ja, mój zespół czy tysiące obcych ludzi?
• co się stanie, jak to padnie – nic, ktoś się zirytuje czy ktoś straci pieniądze albo dane?
• ile kosztuje kolejna poprawka, a ile problem, który miałaby rozwiązać?
• czy ktoś za to w ogóle zapłaci?

Fajerwerk na sylwestra nie potrzebuje betonowego stanowiska startowego. Rakieta z ludźmi na pokładzie – jak najbardziej. Cała sztuka polega na tym, żeby wiedzieć, co właśnie budujemy. I nie udawać, że fajerwerk to Falcon 9 – ani że Falcon 9 to fajerwerk.

Dla mnie kod jest wystarczająco dobry wtedy, gdy kolejne ulepszenie kosztowałoby więcej niż problem, który miałoby rozwiązać. Ale gdzie dokładnie leży ta granica w Waszym projekcie – to już zostawiam do przemyślenia przy niedzielnej kawie…

Kto wygra tę wojnę?

Obstawiam, że nikt. Bo to nie jest żadna wojna – przynajmniej nie taka, jak sugerują memy. Rick i Morty też przez większość odcinków się kłócą, a i tak lecą razem na kolejną przygodę. Morty bez Ricka utknąłby w pierwszym lepszym wymiarze, a Rick bez Morty’ego pewnie dawno zapomniałby, po co w ogóle gdzieś leci.

Jest taka maksyma, którą mam na sztandarze:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

– Antoine de Saint-Exupéry

Czyli doskonałość osiąga się nie wtedy, gdy nie można już nic dodać, ale wtedy, gdy nie można już nic ująć. Saint-Exupéry był pilotem i w oryginale – w „Ziemi, planecie ludzi” – pisał to o konstrukcji samolotów. Ale do rakiet i do kodu pasuje równie dobrze. I to jest chyba najlepsza odpowiedź na pytanie o „wystarczająco dobry” kod.

Bo zauważcie – vibe coder dokleja kolejne kawałki taśmy, inżynier dokleja kolejne warstwy, ale obaj robią to samo: dodają. Tymczasem cała rzecz w tym, żeby umieć wyrzucać – zbędną warstwę, zbędny ficzer, zbędną linijkę kodu. A skoro AI wygeneruje dowolną ilość kodu w kilka sekund, to dopisywać potrafi już każdy. Gorzej z wyrzucaniem…

Najlepsze połączenie, jakie widzę, to inżynier, który potrafi czasem odpuścić i zrobić coś „na vibe’ach”, kiedy to ma sens – i vibe coder, który wie, kiedy przestać i zawołać kogoś, kto zajrzy pod biurko. AI dało każdemu z nas pistolet do portali. Ale to nadal od nas zależy, gdzie nim strzelimy… i czy będziemy wiedzieć, jak wrócić.

A Wy – jesteście bardziej Rickiem czy Mortym? A może macie w szufladzie projekt, który „działa, ale lepiej go nie dotykać”? Dajcie znać w komentarzach 🙂