Subiektywnie o vibe codingu - tipy i narzędzia

Tytułem wstępu: uprawiałem vibe-coding, zanim ktoś wpadł na pomysł, żeby nazwać to vibe codingiem. Pierwsza vibe’owa aplikacja webowa, którą stworzyłem - tools.mpress.cc - powstała w święta 2022 roku z rozmów i eksperymentów przeklejanych z przeglądarkowej wersji ChatGPT. Od tamtej pory stale wspieram się w kodowaniu różnymi modelami LLM, a sporo wypracowanego w ten sposób kodu pracuje na serwerach produkcyjnych, a nie tylko zalega w folderach hobbystycznych.

Dostępne narzędzia zmieniają się w tak błyskawicznym tempie, że pewnie już za miesiąc część tego artykułu będzie nieaktualna, ale postaram się w subiektywny sposób przekazać kilka tipów, które być może przydadzą Ci się w pracy z kodem oraz subiektywnie opowiem o kilku dostępnych narzędziach.

Spis treści

Jak vibe kodować, żeby nie zwariować

Jeśli śledzisz na bieżąco komentarze w internecie o AI, to doskonale wiesz, że na temat kodowania z wykorzystaniem LLMów jest pełne spektrum opinii. Jedni twierdzą, że kod z LLM nadaje się wyłącznie na śmietnik, a inni wprost przeciwnie zapowiadają, że już wkrótce zastąpią one wszystkich programistów. Moim zdaniem prawda jest gdzieś po środku i tylko odpowiednie wykorzystanie tych narzędzi da Ci realne wyniki.

W zasadzie co tydzień pojawiają się nowe narzędzia i metody, ale jest kilka uniwersalnych zasad, które prawdopodobnie przetrwają nawet największe rewolucje w tym temacie.

GIT - czyli kontrola nad historią zmian

Pierwszą rzeczą, która musi wejść Ci w nawyk, jest praca z systemem kontroli wersji - najlepiej GIT-em.

Podczas kodowania z LLM-ami (np. ChatGPT) bardzo łatwo coś „skaskować” - model potrafi przypadkiem usunąć fragment kodu, zmienić składnię albo wprowadzić subtelny błąd, którego nie zauważysz od razu.

Dlatego każda zmiana w Twoim powinna być wersjonowana. Commituj często, opisuj co zrobiłeś i nie bój się tworzyć osobnych branchy do eksperymentów. Dzięki temu zawsze możesz wrócić do działającej wersji projektu — nawet po najbardziej kreatywnej sesji z AI.

Praca z GIT-em pozwoli Ci też w efektywny sposób przenosić zmiany w Twoich aplikacjach na środowiska testowe i produkcyjne.

Popularna technologia

Wybierając stack technologiczny swojego projektu celuj raczej w popularne, sprawdzone technologie. Nowy framework, który wyszedł dopiero przed tygodniem? Raczej nie licz, że popularne modele już na nim wytrenowane. Wybieraj popularne języki programowania i frameworki, które są używane przez programistów na całym świecie.

Dokumentacja dostępna dla modelu

Jeśli to tylko możliwe, to podłącz przez MCP bieżącą dokumentację za pomocą np. Context7. Znacząco poprawisz tym skuteczność generowanego kodu oraz zmniejszysz liczbę halucynacji modeli. Jeśli nie masz takiej możliwości - wklejaj przykłady z oficjalnej dokumentacji lub podobne rozwiązania.

Nie od razu Rzym zbudowano

Jednym z najczęściej popełnianym błędów przy kodowaniu z AI to wrzucenie całej listy wymagań w jeden prompt. Liczysz, że LLM wpadnie na genialny pomysł i napisze wszystko od razu?

W rzeczywistości zwiększasz tym tylko szanse, że model naprodukuje setki linii bezużytecznego kodu.

Takie podejście może się sprawdzić przy prostym pluginie czy prostej stronie, jednak przy większych lub bardziej skomplikowanych tematach jest bardzo ryzykowne.

Krok po kroku

Zamiast tego rozbij swoje zadanie na małe, testowalne części. Najpierw napisz podstawową funkcję, przetestuj ją. Potem dodaj kolejną funkcję. Utrzymuj dialog z modelem - pokazuj mu wyniki testów, mów, co Ci nie pasuje, iteruj.

Zacznij tak:

1. Prompt 1: “Napisz funkcję, która pobiera dane z API”
2. Przetestuj - czy działa?
3. Prompt 2: “Jak mamy parsować JSON z tego API?”
4. Przetestuj - czy formatowanie OK?
5. Prompt 3: “Jak dodać obsługę błędów?”

Ta strategia “pojedynczych kroków” powoduje, że:

• Wychwytujesz błędy wcześnie
• Masz pełną kontrolę nad kierunkiem kodu
• Będziesz lepiej rozumieć całość projektu

Instrukcje w plikach

Jeśli pracujesz nad większym projektem (aplikacją, pluginem), zapisz sobie instrukcje w osobnym pliku - np. DEVELOPMENT_GUIDELINES.md lub CODING_STYLE.txt. W tym pliku spisz:

• Jak ma wyglądać struktura kodu
• Jakie standardy formatowania obowiązują
• Jakie biblioteki/frameworki planujesz używać
• Jakie konwencje nazewnictwa
• Specyficzne wymogi bezpieczeństwa

Każdy prompt do LLM-u zaczynasz od: “Oto instrukcje dla naszego projektu: [zawartość DEVELOPMENT_GUIDELINES.md]. Teraz napiszemy nową funkcję …”

Część asystentów będzie automatycznie czytała takie pliki - na przykład do kodowania z Claude Code wystarczy Wam plik claude.md w głównym folderze.

Model będzie się stosował do Twoich reguł. Oznacza to dużo więcej spójnego kodu.

Planowanie przed kodowaniem

Ale zaczekaj - zanim znów w ogóle rzucisz prompt z kodem, najpierw zaplanuj architekturę. Na serio. Weź kartkę (lub notatnik) i napisz:

## Architektura projektu

### Cele

- Co ma robić aplikacja?
- Dla kogo jest?

### Struktura

- Główne moduły
- Przepływ danych między modułami
- Zewnętrzne API/bazy danych

### Technologia

- Framework
- Baza danych
- Narzędzia

### Lista zadań

- [ ] Task 1 - Opisanie zadania
- [ ] Task 2 - Opisanie zadania
- [ ] ...

Dopiero gdy masz jasny plan, zaczynasz pisać pierwszy prompt. I piszesz go dla pierwszego zadania z listy, nie dla całego projektu.

Dla większych projektów - dokumentacja przed kodem

Jeśli to coś bardziej zaawansowanego, zanim poprosisz LLM, aby napisał chocby linię kodu:

1. Napisz plan - opisz, jak mają wyglądać klasy, funkcje, przepływ danych
2. Pokazywanie LLM-owi plan - mów do niego: “Oto architektura. Czy masz jakieś uwagi?”
3. Uzgodnij - spytaj czy się nie mylisz, zapytaj co warto dodać i czy czegoś nie brakuje - porozmawiajcie
4. Zapisz plan w pliku .md - możesz później testować różne podejścia, ale wartościowy plan warto mieć w formie pliku, a nie tylko w jednej historii chatu
5. Dopiero wtedy - kod - teraz możesz prosic o implementację

Ta faza planowania zaoszczędzi Ci wiele godzin refaktoringu później.

Pro tip: do fazy planowania i spisywania architektury używaj najlepszych modeli jak GPT-5 high reasoning czy Sonnet 4.5 Thinking.

Odpowiedni tryb pracy

Skoro już doszliśmy do tematu środowiska pracy, to absolutnie niezbędnym krokiem jest przestawienie się na pracę na dedykowanych do tego środowiskach. Nigdy, ale to nigdy nie edytujemy plików na serwerze produkcyjnym - czyli tym, który zarezerwowany jest dla prawidłowego funkcjonowania dla nas lub naszych klientów. Przykład? Sklep internetowy na naszej głównej domenie.

Zawsze pracuj lokalnie lub na środowisku deweloperskim. Tam testujesz, poprawiasz błędy, eksperymentujesz z AI. Dopiero gdy wszystko działa - wrzucasz zmiany na produkcję przez GIT. To nie tylko kwestia bezpieczeństwa, ale po prostu zdrowia psychicznego. Jeden błąd wprowadzony bezpośrednio na produkcji i możesz stracić godziny na naprawę tego, co zepsułeś - plus wyjaśnienia zdenerwowanemu klientowi, dlaczego jego sklep nagle przestał działać.

Jeśli pracujesz np. z WordPressem, rozwiń projekt lokalnie za pomocą Local by Flywheel czy WordPress Studio. W przypadku aplikacji - użyj serwera deweloperskiego (np. npm run dev). Środowisko testowe to Twój plac zabaw - tutaj możesz sobie pozwolić na wszystko.

Po testach zmiany przenieś na środowisko deweloperskie lub stagingowe - sprawdź jeszcze raz i dopiero, gdy się upewnisz, że przy okazji nic się nie zepsuło - przenieś zmiany na produkcję.

Do testowania zmian polecam budowę pipeline’u z testami przy wykorzystaniu Buddy.works. Możesz tam dodać unit testy, ale też np. porównać wygląd aplikacji testami wizualnymi.

Trzymanie standardów

Kod wygenerowany przez AI w zależności od narzędzia (lub jego humoru) może używać zupełnie innego formatowania składni. Może i działa, ale wrzucenie aktualizacji do repozytorium może wskazać nam setki zmian, gdy w rzeczywistości zmieniliśmy tylko 3 linijki. Dlatego musisz trzymać standardy - zarówno te związane z formatowaniem kodu, a jeszcze lepiej z jego jakością.

Tutaj z pomocą przychodzą narzędzia typu lintery i formattery. W PHP to na przykład PHP CodeSniffer (phpcs) i PHP CS Fixer. Te narzędzia automatycznie sprawdzają Twój kod pod kątem błędów i niespójności, a niektóre potrafią nawet automatycznie je naprawić.

Standardy w WordPressie

Jeśli pracujesz z WordPressem, obowiązuje tam WordPress Coding Standards. To znaczy: wcięcia to tabulatory (nie spacje!), nazwy zmiennych i funkcji w snake_case, nawiasy klamrowe w linii z warunkami. Brzmi dziwnie? No, taka jest tradycja WordPressa. Ale zaskoczenie - AI o tym bardzo często zapomina.

Żeby egzekwować te standardy, ustawisz phpcs z preset standardów WordPressa:

phpcs --standard=WordPress ./wp-content/plugins/moj-plugin/

Albo automatycznie naprawić błędy formatowania:

phpcbf --standard=WordPress ./wp-content/plugins/moj-plugin/

Nowoczesne PHP - PSR-12

Jeśli pracujesz nad aplikacją w czystym PHP (nie WordPress), powinieneś stosować PSR-12. To bardziej liberalny standard niż WordPress - spacje zamiast tabulatorów, camelCase dla nazw zmiennych, bardziej elastyczne formatowanie. Większość nowoczesnych PHP frameworków (Laravel, Symfony) się na tym opiera.

phpcs --standard=PSR12 ./src/
php-cs-fixer fix ./src/

Statyczne analizatory kodu

Ale czekaj - lintery tylko sprawdzają formatowanie. Coś lepszego to statyczne analizatory, które wychodzą Tobie naprzeciw błędy logiki, zagrożenia bezpieczeństwa czy problemy z typami. W PHP to PHPStan albo Psalm.

phpstan analyse ./src/
psalm ./src/

Te narzędzia wykryją rzeczy takie jak:

• Brakujące sprawdzenia null
• Zły typ zmiennej
• Potencjalne SQL injection
• Nieużywane zmienne

A to właśnie miejsce, gdzie kod z AI najczęściej się myli.

Podpięcie wszystkiego pod GIT

Najlepsze w tym wszystkim? Możesz to wszystko podpiąć pod Husky i lint-staged (choć to narzędzia JavaScript, ale możesz je użyć do PHP):

"lint-staged": {
  "*.php": [
    "vendor/bin/phpcs --standard=WordPress --report=full",
    "vendor/bin/phpcbf --standard=WordPress"
  ]
}

Dzięki temu kod nie trafi do repozytorium bez sprawdzenia. A jeśli Ty zapomnisz, to Husky na to pozwoli i będzie czekać, aż naprawisz błędy.

Dzięki temu kod AI nie będzie wyglądał jak ktoś go pisał nogami, tylko będzie spójny z resztą projektu. I co najważniejsze - będzie czytelny dla Ciebie, Twoich kolegów i mniej podatny na błędy.

Czym kodować, żeby nie zbankrutować

Aktualizacja 23.11.2025: Od czasu kiedy zaplanowałem napisanie tego artykułu, w ciągu niecałego miesiąca nastąpiło tak duzo zmian w świecie AI, że zanim podałem swoje pierwsze propozycje narzędzie - nastopiły w nich radykalne zmiany. Postaram się aktualizować ten artykuł, ale nie mogę się gwarantować, że będzie zawsze aktualny i być moze ju niedługo będziesz go czytać z lekkim rozczarowaniem ;)

Nie przywiązuj się do jednego narzędzia

Rynek AI zmienia się szybciej niż zdążymy rozpocząć pracę z nowym projektem. To, co dziś wydaje się najlepszym narzędziem, jutro może zostać przebudowane, zamknięte, przejęte, albo po prostu przestać być opłacalne. Dlatego nie warto zakopywać się w jednym ekosystemie — lepiej traktować te narzędzia jako wymienne moduły. Dziś korzystasz z jednego, jutro możesz przejść na inne bez większej straty. Elastyczność pozwoli Ci wycisnąć najwięcej z pracy z AI.

Google Antigravity - łap, dopóki darmowe!

Google Antigravity to zdecydowanie jedno z tych narzędzi, które wywracają stół — nie dlatego, że robi wszystko najlepiej, ale dlatego, że nagle daje bardzo dużo… kompletnie za darmo. Oparty na niezawodnym VS Code, ale wzbogacony o tryb pracy z Agentami. Zaloguj się z konta Google i już możesz rozpocząć pracę.

Ale bądźmy szczerzy: jeśli jest darmowe, to ten stan nie potrwa długo. Warto korzystać szybko, póki Google testuje rynek i zbiera dane. Do pracy z kodem masz nie tylko najnowszy model Google - Gemini 3 Pro, ale chociażby rewelacyjny Sonnet 4.5. W pięciogodzinnych oknach jesteś w stanie zrobić naprawdę dużo.

W trybie planowania zobaczysz plan, jego realizację oraz otrzymasz wytyczne do testów. Działa to świetnie! Dodatkowo świetny tryb pracy z przeglądarką - rewelacyjny do debugowania czy poprawiania frontendów. A może potrzebujesz grafiki? Wygeneruj bezpośrednio z czatu i wstaw do projektu.

Roo Code — solidne rozwiązanie w dobrej cenie

Roo Code to prekursor kodowania z wyspecjalizowanymi agentami i rozbijania złożonych zadań na mniejsze. To wtyczka do VS Code, do której podpinamy nasze klucze do dostawców modeli - np. Claude z Anthropic czy Codex od OpenAI. Możesz też wpiąć np. Jeden klucz z Openrouter i korzystać z gigantycznej liczby modeli - w tym darmowych!

Jest stabilny, przewidywalny i robi to, czego od niego oczekujesz: dobrze tłumaczy kod, proponuje sensowne poprawki, pomaga w debugowaniu. Łatwo dostępne rozszerzenia MCP instalowane z panely Roo.

Jeśli chcesz vibe-kodować tylko od czasu do czasu, to płacisz tylko za wykorzystanie modeli w danym momencie. Proste rzeczy kodowane np. Z Claude Haiku będą Cię kosztowały grosze. Jeśli jednak zamierzasz urządzać długogodzinne sesje - być może abonament u większego dostawcy będzie dla Ciebie lepszy finansowo.

Claude Code — super jakość, niekoniecznie w parze z ceną

Claude Code to klasa premium. Jak dla mnie Sonnet 4.5 od momentu premiery jest moim ulubionym modelem. Rozumienie kontekstu i umiejętność pisania czystego, zrozumiałego kodu to absolutna czołówka.

Problem? Cena. Muszę przyznać, że gdy korzystałem z Claude na co dzień, to plan Pro (20$) blokował mnie limitami non stop. Dopiero przejście na plan Max (100$) rozwiązało ten problem - chociaż z tego czytam na Reddicie - to problem niskich limitów powraca cały czas.

Codex — warto, jeśli i tak używasz ChatGPT w płatnym planie

Nowy Codex to ciekawa pozycja dla osób, które i tak płacą za ChatGPT. Integracja np. W VS Code jest prosta i dopracowana. Jakość pracy modeli? Bardzo dobra.

Limity? Jeśli nie przesadzasz z pracą w trybie High - to można wycisnąć z tego podstawowego planu bardzo dużo. W tym trybie model jest bardzo dobry w projektowaniu architektury czy debugowaniu dziwnych problemów. Często zamiast pracy z Codexem pisałem plan w aplikacji desktopowej, zapisywałem jako plik tekstowy i dopiero na tej podstawie prosiłem o pisanie kodu już w samym VS Code.

Wady? Potrafi być potwornie wolny, przez co mnie wytrącał notorycznie z trybu pracy, bo przeskakiwałem do innych zadań.

Warp — zejście na ziemię

Warp obiecywał rewolucję w terminalu i całkiem sporo dowiózł - tu cały czas jest aplikacją najwyższej jakości. Jeśli pracujesz bardzo dużo z terminala, to warto zwrócić uwagę na to narzędzie.

Jeszcze do niedawna był dla mnie wyborem numer jeden, bo w rewelacyjnej cenie oferował dostęp do wszystkich czołowych modeli. Do tego z rewelacyjnym zarządzaniem MCP oraz indeksowaniem projektów.

Niestety ostatnia aktualizacja cennika nie spotkała się z entuzjazmem użytkowników, ani moim. Efektywnie kilkukrotna podwyżka ceny sprawiła, że przerzuciłem się z powrotem do Roo Code, a obecne Antigravity.

Podsumowanie: testuj, bądź elastyczny i trzymaj rękę na pulsie

Świat code assistantów zmienia się dziś tak szybko, że trzymanie się jednego narzędzia na siłę zwyczajnie nie ma sensu. To, co działa świetnie w tym miesiącu, za chwilę może być płatne, limitowane albo wyparte przez lepszą alternatywę. Dlatego kluczowe jest jedno: bądź elastyczny. Testuj nowe rozwiązania, porównuj modele, sprawdzaj aktualizacje, czytaj changelogi i opinie użytkowników.

Nie chodzi o znalezienie „tego jedynego” asystenta — chodzi o to, żeby wiedzieć, z czego korzystać tu i teraz, w zależności od zadania i sytuacji. Im więcej narzędzi poznasz, tym łatwiej będzie Ci wybierać te, które przyspieszą Twoją pracę, zamiast ją komplikować.

W świecie AI wygrywają nie ci, którzy są przywiązani do jednej aplikacji, tylko ci, którzy potrafią szybko adaptować się do zmian.