Zanim pod koniec 2022 roku pojawił się ChatGPT, pisanie backendu wymagało sporo powtarzalnego kodu. Frameworki ułatwiały routing i połączenia z bazą, ale modele, serializację i schematy walidacji pisało się ręcznie, a większość tej pracy była mechaniczna.
Modele językowe zamieniły tę pracę w tani surowiec. Nadal nie mamy do czynienia z AGI: modele nie rozumieją problemów biznesowych i nie myślą jak inżynier, co dobrze pokazują przykłady takie jak ten:
Przetworzyły za to ogromne ilości publicznych repozytoriów, zgłoszeń i dyskusji technicznych, więc typowy kod odtwarzają niezawodnie: struktury projektów, zapytania do bazy, testy. Skoro generowanie składni stało się tanie, praca programisty przesunęła się z klepania kodu na kierowanie modelami.
Ciekawe pytanie brzmi więc: które procesy naprawdę zyskują na generowaniu, a gdzie bezrefleksyjny vibecoding staje się obciążeniem.
Gdzie generowanie bez kontroli zawodzi
Aplikacja zbudowana w całości z promptów przez kogoś, kto nie rozumie kodu, zwykle działa, dopóki nie pojawią się prawdziwi użytkownicy. Wtedy niesprawdzone zależności i wystawione klucze zamieniają się w wycieki danych. Afera z aplikacją Tea, w której wyciekły skany dowodów tożsamości, pokazuje, jak to się kończy.
Model nie odpowiada za awarie na produkcji, dług technologiczny ani izolację danych klientów. Generuje odpowiedź i kończy sesję.
Wąskie gardło przeniosło się na projektowanie systemów
Generowanie kodu jest szybkie, więc wolną częścią pracy są dziś architektura, przepływ danych, granice uprawnień i koszty utrzymania. Czysty kod z modelu nie gwarantuje, że dwa serwisy zintegrują się bezpiecznie, ani że zapytanie wytrzyma tabelę większą niż sto wierszy.
Vibecoding przyspiesza inżynierów, którzy te ograniczenia już rozumieją. Użyty zamiast tego zrozumienia produkuje dług technologiczny szybciej, niż zrobiłby to ręcznie jakikolwiek zespół.
Czym jest vibecoding
Termin vibecoding pochodzi od Andreja Karpathy'ego, który w lutym 2025 opisał tak styl pracy, w którym dajesz się ponieść fali, zapominasz, że kod w ogóle istnieje, a zamiast pisać, mówisz do edytora:
I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while.
Karpathy miał na myśli jednorazowe projekty na weekend. W praktyce zrobiło się z tego spektrum: od oddania modelowi całej aplikacji po świadome przyspieszanie pracy, w którym nadal piszesz wymagania, czytasz diffy i ustalasz architekturę, a model pisze powtarzalne fragmenty. Takie użycie też kosztuje: 30 USD za milion tokenów wejściowych i 180 USD za milion wyjściowych w GPT-5.5 Pro.
Narzędzia takie jak Claude Code czy Cursor sprawdzają się, dopóki model wspiera twoją implementację. Problem zaczyna się, gdy zastępuje twój osąd.
Trzy poziomy użycia
Produktywne użycie od ryzykownego odróżnia to, czy ktokolwiek rozumie wygenerowany system:
| Poziom | Diffy | Gdyby model jutro zniknął |
|---|---|---|
| Wspomaganie pod kontrolą | czytasz każdy | zwalniasz, architektura nadal jest twoja |
| Bierna akceptacja | mergowane, gdy testy przechodzą | nikt nie potrafi wyjaśnić części systemu |
| Całkowita delegacja | nikt ich nie czyta | nikt w ogóle nie rozumie kodu |
Wspomaganie pod kontrolą
Rozumiesz każdy plik, którego dotyka model. Sprawdzasz wygenerowany kod i pokrycie testami, a przypadki brzegowe przechodzisz w debuggerze. Prompt jest skrótem do kodu, który i tak mógłbyś napisać. Tak na co dzień korzystam z Cursora Pro.
Bierna akceptacja
Wygoda zaczyna obniżać jakość. Znasz podstawy, ale przestajesz czytać każdy diff: jeśli testy przechodzą lokalnie i serwer wstaje, kod trafia do repozytorium. Refaktoryzacja i audyty bezpieczeństwa są odkładane, a projekt wygląda na szybko rozwijany, dopóki nie wyjdą edge case'y, które zespół potrafi wyjaśnić tylko pytając model o jego własny kod.
Całkowita delegacja
Cały stack trafia do agentów i platform takich jak v0.dev, Bolt czy Lovable: frontend, schemat bazy, uwierzytelnianie i infrastruktura, bez zaglądania do plików. W kilka godzin powstaje działający interfejs z endpointami CRUD. Potem rosną rachunki za tokeny i subskrypcje agentów, a baza kodu zostaje nieprzejrzystym zbiorem niesprawdzonych zależności.
Dobre strony vibecodingu
Najlepsza część może wcale nie być twoja. Pentesterzy czekają na takie aplikacje. Spokojnie, i tak im zapłacisz. Albo nie.
Często zresztą nikt się nie zgłosi. Najpierw psują się zwykle banalne rzeczy: endpoint, który miał być wewnętrzny, bez sprawdzania ról, więc każdy użytkownik może wyciągnąć cudze dane, czasem całą bazę naraz. Ci, którzy to znajdą, nie chcą bug bounty. Chcą danych, a ty dowiadujesz się o tym, budząc się ze zrzuconą bazą.
Prywatne projekty nadal mają sens: małe narzędzia i automatyzacje, których nikt inny nie dotyka. Prototypy też, gdy chcesz w jeden wieczór zamiast tygodnia sprawdzić, czy pomysł działa.
Vibecoding jest okej, 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ę, że z twojej aplikacji leją się cudze dane).
Nauka programowania a narzędzia generatywne
Jeśli uczysz się programować, opieranie się wyłącznie na generowaniu hamuje rozwój. Patrzenie, jak model produkuje działający kod, pomija etap, w którym sam rozbijasz problem na części.
A to właśnie jest ta praca: rozumienie, jak zmienia się stan, gdzie zawodzą żądania sieciowe i dlaczego dana struktura danych pasuje do obciążenia. Szukanie przyczyny padającego testu, błędu off-by-one czy komunikatu kompilatora buduje intuicję potrzebną do oceny kodu produkcyjnego. Bez niego nie naprawisz systemu w dniu, w którym model się pomyli.
Których programistów zastąpi automatyzacja
Modele językowe nie wyeliminują programistów. Zastąpią pracę, która jest samą powtarzalną składnią bez zrozumienia architektury, a osoby żyjące z szablonów albo oddające całe debugowanie narzędziom zobaczą, że ich pracę łatwo zastąpić.
Chociaż... może zastąpi też mnie? I ciebie? Mam plan: hodowla krewetek. A ty?
