Jak rozpoznać, że AI ‘napisało kod’, ale nikt go nie utrzyma (checklista dla CEO/COO)

Jeśli Twoja firma ma system, który “ktoś szybko zrobił z AI”, a dziś każda zmiana kończy się regresją, wdrożenia robi tylko jedna osoba, a incydenty wpadają po godzinach, to to nie jest “pech”. To vibe coding.

W tym artykule dostajesz checklistę dla CEO/COO: jak rozpoznać, że kod powstał szybko, ale nie da się go utrzymać – i co zrobić, zanim koszty operacyjne wymkną się spod kontroli.

 ZBUDUJ PRODUKT ODPOWIEDZIALNIE

Vibe coding w jednym zdaniu (i czym nie jest)

Najprościej mówiąc: vibe coding to programowanie oparte na intencji, a nie na składni. Zamiast ślęczeć nad każdą linią kodu i sprawdzać, czy średnik jest na swoim miejscu, opisujesz AI, co chcesz osiągnąć, a potem po prostu „łapiesz vibe” – sprawdzasz, czy to, co wypluł LLM, działa tak, jak sobie wymarzyłeś.

Andrej Karpathy, legenda AI, ujął to genialnie:

„There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. ”

Vibe coding vs AI-assisted coding

Warto tu postawić wyraźną kreskę. Vibe coding to skrajna forma programowania z AI: iterujesz po efekcie („działa/nie działa”) zamiast rozumieć i recenzować kod. AI-assisted coding zaczyna się tam, gdzie nadal masz kontrolę: czytasz diff, weryfikujesz założenia, dopisujesz testy i dbasz o bezpieczeństwo.

Wg Simona Willisona:

„When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes. ”

To kuszące, prawda? Ale pamiętajcie: vibe coding nie zwalnia z odpowiedzialności. Jeśli nie umiesz wytłumaczyć, dlaczego kod działa — to najpewniej nie „przyspieszasz”, tylko przesuwasz koszt na przyszłość. To, że kod ma „dobry vibe” i działa na Twoim komputerze, nie znaczy, że jest gotowy na spotkanie z tysiącem użytkowników na produkcji. W świecie agentycznego AI rola programisty przesuwa się z „pisarza” na „audytora”. Jak zauważa Wiktor Żołnowski w artykule Is Clean Code Dead?, zdejmujemy z siebie ciężar pisania, ale stukrotnie zwiększamy wagę czytania i weryfikacji kodu. Bez Clean Code auditowanie tysięcy linii wyplutych przez AI staje się niemożliwe.

Kiedy vibe coding ma sens (realne use-case’y)

W Pragmatic Coders uwielbiamy wydajność, więc nie będziemy udawać, że vibe coding jest zły. Ma swoje miejsce w szeregu – zwłaszcza tam, gdzie liczy się szybkość, a nie wieczna trwałość.

• Prototyp UX: 2–3 warianty ekranu i flow w 1 dzień, żeby coś pokazać użytkownikom.
• Spike technologiczny: „Czy da się w ogóle zintegrować X z Y?”. Szybki test hipotezy.
• Automatyzacje wewnętrzne: Jednorazowe skrypty, raporty, tzw. glue-code, gdzie ryzyko jest małe, a oszczędność czasu ogromna.
• Bootstrap MVP: Ale tylko jeśli od początku zakładasz, że to nie jest jeszcze produkt, tylko „demo do walidacji”.
  

  Przykład z życia: Zastosowaliśmy to podejście, by przepisać całą aplikację Health Folder niemal bez budżetu. Dzięki iteracyjnemu workflow i AI zredukowaliśmy 2,000 godzin pracy dewelopera do zaledwie 73 godzin efektywnego wdrożenia. To pokazuje potęgę AI, gdy proces jest pod kontrolą.

Kiedy vibe coding staje się problemem: 10 czerwonych flag

Vibe coding to świetne narzędzie do prototypowania, ale fatalny proces dowożenia produktu. Jeśli masz 3+ z tych objawów, vibe coding najpewniej weszło na produkcję i zaczęło generować dług:

1. Każdy release kończy się regresjami („coś się zawsze wysypie”) – Poprawiasz jeden błąd, a wylatują trzy inne w zupełnie niepowiązanych miejscach. To znak, że AI wygenerowało kod o wysokim stopniu splątania, którego nikt nie ogarnia.
2. Brak testów albo testy „na oko” – „Kliknąłem dwa razy i działa” to nie jest test. Prawdziwy problem zaczyna się, gdy AI generuje kod, którego nie potrafisz przetestować automatycznie, bo nie ma on przejrzystych interfejsów (tzw. testability).
3. Tylko jedna osoba umie wdrażać (bus factor = 1) – Jeśli tylko autor promptów wie, jak „nakłonić” system do działania, Twoja firma jest zakładnikiem jednego „vibe’u”. Gdy ta osoba pójdzie na urlop albo. co gorsza, opuści projekt, ten staje w miejscu.
4. „Nie dotykaj tego pliku, bo się zepsuje” – Kod staje się czarną skrzynką. Deweloperzy boją się robić refaktoryzację, bo nie rozumieją logiki zaszytej w 500-liniowej funkcji wyplutej przez LLM-a.
5. Poprawka, która miała trwać 2h, trwa 2 dni – Proste zmiany (np. dodanie pola w formularzu) wymagają przebijania się przez setki linii nadmiarowego kodu (tzw. boilerplate), który AI dołożyło „na wszelki wypadek”.
6. Dużo kodu, mało przewidywalności – Projekt rośnie błyskawicznie (liczba linii kodu idzie w tysiące), ale każda nowa funkcja to rzut kostką: zadziała albo położy cały serwer. Brak tu stabilnych fundamentów architektonicznych.
7. Nikt nie potrafi opisać architektury na jednej kartce – Skoro kod powstawał przez iteracyjne „dolewanie” kolejnych promptów, nie ma w nim spójnej myśli technicznej. To zlepek mikro-decyzji AI, a nie zaplanowany system.
8. Brak obserwowalności – Nie masz pojęcia, co się dzieje pod maską. AI rzadko samo z siebie dba o poprawne logowanie, obsługę błędów czy tracing. W efekcie, gdy system „klęka”, Twój zespół patrzy w pustą konsolę.
9. Pojawiają się incydenty po godzinach – System nie jest odporny na błędy (resilient). „Vibe” trzymał go przy życiu na Twoim laptopie, ale w starciu z realnym ruchem i edge-case’ami na produkcji, sypie się jak domek z kart.
10. Zmiany bezpieczeństwa i uprawnień robi się „na czuja” – To najgroźniejszy punkt. AI potrafi „wyvibe’ować” funkcjonalność, zapominając o walidacji danych wejściowych czy autoryzacji. Luka w kodzie generowanym przez AI to otwarta brama dla hakerów.

Kodowanie z AI jest świetne. Większość developerów w Pragmatic Coders używa narzędzi AI (zwłaszcza Cursora) do kodowania. Co istotne jednak, nie poświęcamy jakości w imię ilości. AI służy nam do pracowania lepiej, nie “bezsensownie” szybciej. To ważne: kod, jeśli nie sprawdzany i pisany nieodpowiedzialnie, wygeneruje tylko więcej problemów w przyszłości.

Co robić w 7 dni (mini-plan dla CEO/COO)

Załóżmy, że twój projekt rzeczywiście się pali. Co robisz? W pierwszym tygodniu nie próbuj “naprawić wszystkiego”. Celem jest odzyskać kontrolę i przewidywalność, żeby firma przestała płacić za pożary.

1. Dzień 1–2: zamroź duże zmiany (żadnych “nowych ficzerów”), spisz 3–5 krytycznych procesów biznesowych, które muszą działać (np. płatność, zamówienie, wysyłka) i ustal jedną osobę odpowiedzialną za decyzje “co wchodzi na produkcję”.
2. Dzień 3–4: zrób szybki przegląd ryzyk: kto ma dostęp, gdzie są największe awarie, co powoduje nocne eskalacje – i postaw minimalny monitoring/alerty, żebyście szybko wiedzieli o problemie.
3. Dzień 5–7: wybierz 1–2 najbardziej bolesne obszary i dowieź “stabilizację”, nie “idealny kod”: testy automatyczne dla krytycznej ścieżki, prosty rollback/release plan oraz listę decyzji: co refaktorujemy, co zostawiamy, a co trzeba wymienić. Po tygodniu powinniście mieć jasność: czy to jest do uratowania iteracyjnie, czy wymaga większego rescue — i ile kosztuje dalsze trwanie w obecnym stanie.

Jak vibe-codować mądrze

Żeby nie zrobić sobie (i firmie) krzywdy, wprowadźcie minimalny zestaw barier bezpieczeństwa dla każdego AI-generowanego kawałka kodu:

• Szczegółowo definiuj oczekiwania – Wszystkie niedomówienia Twój agent AI obsłuży (lub nie) po swojemu. Aby funkcjonalność została zaimplementowana poprawnie potrzebny jest dokładny plan lub chociaż dokładny opis. Pracę nad funkjonalnością rozpocznij od sesji planowania oraz Q/A aby wyklarować wszystkie przypadki użycia.
• Testy automatyczne – Przynajmniej 3-5 scenariuszy “happy path” (np. “użytkownik dodaje produkt do koszyka i przechodzi do kasy”). Jeśli AI zepsuje coś “pod maską”, testy automatyczne wyłapią to zanim Ty to klikniesz.
• Code review (nawet szybkie): Człowiek musi przeczytać diff – Nie akceptuj zmian w ciemno. Przejrzyj diff w poszukiwaniu dziwnych pętli, nadmiarowych bibliotek czy twardo zakodowanych (hardcoded) wartości. AI to asystent, a Ty jesteś architektem.
• Skan zależności (Dependency Check) – AI często sugeruje biblioteki, które są przestarzałe albo mają luki bezpieczeństwa. Używaj narzędzi typu Snyk lub npm audit, żeby mieć pewność, że to, co dołożyło AI, nie jest “koniem trojańskim”.
• Security: Zero sekretów w repo – To klasyk vibe codingu: AI wypluwa kod z Twoim kluczem API. Używaj pre-commit hooków i narzędzi typu trufflehog, które zablokują commit, jeśli znajdą tam jakiekolwiek hasła czy tokeny.
• Observability: Minimum logi + alerty – Bez tego debugowanie kodu AI to loteria. Każda kluczowa funkcja wygenerowana przez LLM musi mieć poprawną obsługę błędów (try-catch) i logowanie. Musisz wiedzieć o awarii jak najszybciej.
• Definition of Done: “Działa u mnie” nie wystarczy – Kod jest gotowy tylko wtedy, gdy: przeszły testy, kod został zmergowany, a monitoring nie krzyczy. Dodatkowo nie może wystąpić regresja – musimy mieć pewność, że istniejące funkcjonalności dalej działają poprawnie.

Bonus: Prompt template (do skopiowania)

To szkielet, który pomoże Ci wyciągnąć z AI coś więcej niż tylko „vibe”:

Zadanie: Zbuduj [funkcję/moduł] do [cel].
Kontekst: System to [stack], dane w [źródło], ograniczenia [np. compliance/PII].
Kryteria akceptacji:
- [Kryterium 1]
- [Kryterium 2]
Bezpieczeństwo: nie loguj PII, waliduj input, obsłuż błędy.
Testy: napisz testy dla 5 scenariuszy (happy + edge).
Output: kod + instrukcja uruchomienia + ryzyka i trade-offy.

Co dalej?

Vibe coding to potężna broń w rękach lidera, ale tylko wtedy, gdy wiesz, kiedy odpuścić „vibe” na rzecz solidnej inżynierii. Wybierz scenariusz, który najlepiej opisuje Twoją sytuację:

1. Scenariusz A: Produkcja już płonie (lub zaraz zacznie) Jeśli Twój system generuje więcej błędów niż leadów, a deweloperzy boją się dotknąć kodu „bo się zepsuje”, sprawdź nasze usługi ratowania projektów IT. Pomożemy Ci przejść od beztroskiego prototypowania do stabilnego produktu, który naprawdę zarabia pieniądze. Bo w końcu o to w tym wszystkim chodzi, prawda?
2. Scenariusz B: Masz MVP i chcesz bezpiecznie skalować Vibe coding świetnie skrócił Twój „time-to-demo”, ale teraz czas na prawdziwy wzrost. Najważniejsze nie jest „przepisać wszystko”, tylko odzyskać kontrolę: ustabilizować architekturę i zbudować zabezpieczenia. Pomożemy ci w tym.
3. Scenariusz C: Chcesz budować kulturę AI-first, ale bez chaosu Jeśli dopiero planujesz wdrożenie narzędzi AI, zacznij od fundamentów. W świecie agentycznym rola programisty przesuwa się na „audytora”, a to wymaga nowych standardów jakości. Porozmawiajmy o tym, jak wdrożyć AI tak, by przyspieszało Twój biznes, a nie tylko generowało linie kodu.

Czytaj więcej

Jeśli ten temat Cię zainteresował, sprawdź nasze inne artykuły o zarządzaniu projektami IT, długu technicznym i ratowaniu produktów:

• Wszystko pod kontrolą? Jak rozpoznać Efekt Arbuza w IT – Dlaczego projekty, które wyglądają na „zielone” w raportach, nagle wybuchają na czerwono (częsty skutek zbyt optymistycznego vibe codingu).
• Od MVP do Scale-Up: który dług techniczny warto zatrzymać? – Jak odróżnić dług, który pomaga szybciej walidować produkt, od tego, który zabije Twój system.
• Audyt Projektu IT – Kiedy projekt płonie i jak go uratować? – Praktyczny przewodnik dla liderów, którzy czują, że ich technologia staje się kotwicą, a nie silnikiem.
• Webinar: AI Command Center dla PMa: Jak pracować z Gemini CLI – Zobacz w praktyce, jak zarządzamy procesem z pomocą AI, zachowując przy tym pełną inżynierską kontrolę.
• 6 zasad rozmowy z zarządem, gdy twój projekt IT jest zagrożony – Jak przekazać trudne informacje o długu technicznym i przekonać decydentów do planu naprawczego.

FAQ