Tytułem wstępu: robiłem to, 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 w okienku ChatGPT. Od tamtej pory stale wspieram się w kodowaniu różnymi modelami LLM, a duża 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
Rozwiń spis treści
Jak vibe kodować, żeby nie zwariować
Jeśli czytacie śledisz 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 na 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 pozowli Ci też w efektywny sposób przenosić zmiany w Twoich aplikacjach na środowiska testowe i prodykcyjne.
Nie strzelaj z armaty
Jedna z najczęściej popętnianym błędów przy kodowaniu z AI to wrzucenie całej listy wymagań w jeden prompt. Liczysz, że LLM wpadnie na genialny pomysł i napiszesz wszystko od razu. W rzeczywistości zwiększasz tym tylko szanse, że model naprodukuje setki linii bezużytecznego kodu.
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 dialg z modelem - pokazuj mu wyniki testów, mów, co Ci nie pasuje, iteruj.
Zacznij tak:
- Prompt 1: “Napisz funkcję, która pobiera dane z API”
- Przetestuj - czy działa?
- Prompt 2: “Jak mamy parsować JSON z tego API?”
- Przetestuj - czy formatowanie OK?
- 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 zaczyńasz od: “Oto instrukcje dla naszego projektu: [zawartość DEVELOPMENT_GUIDELINES.md]. Teraz napiszemy nową funkcję …”
Część asytentów bedzie 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 stosować się 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:
- Napisz plan - opisz, jak mają wyglądać klasy, funkcje, przepływ danych
- Pokazywanie LLM-owi plan - mów do niego: “Oto architektura. Czy masz jakieś uwagi?”
- Uzgodnij - spytaj czy się nie mylisz, zapytaj co warto dodać i czy czegoś nie brakuje - porozmawiajcie
- 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
- 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 deweloperski 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.
Zeby 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ć cdn.
Wkrótce też dopiszę moje subiektywne oceny dostępnych narzędzi wraz z komentarzem. Zostaw komentarz jeśli chcesz dostać informację o aktualizacji!
