7 wzorców promptów do generowania kodu

Jakość kodu z modelu nie jest funkcją tego, jak dobry jest model. Jest funkcją tego, jak dobrze postawisz problem. Ten sam Claude, GPT czy Cursor wypluje przeciętny boilerplate albo dokładnie to, czego potrzebujesz — różnica leży w trzech–czterech zdaniach na początku. Prompt to nie zaklęcie, tylko specyfikacja kontraktu. Im więcej niedopowiedzeń zostawisz, tym więcej model dopowie sobie sam, a dopowiada zawsze w stronę „najbardziej typowego” rozwiązania z treningu, nie w stronę twojego repozytorium.

Poniżej siedem wzorców, których używam codziennie. Każdy ma uzasadnienie (dlaczego działa) i krótki przykład promptu. Nie są wzajemnie wykluczające — najlepsze rezultaty daje ich łączenie. Pisane z perspektywy dewelopera, który traktuje model jak bardzo szybkiego, bardzo dosłownego juniora.

Wzorzec 1: spec-first — najpierw specyfikacja, potem kod

Zanim poprosisz o implementację, poproś o plan. Każ modelowi opisać sygnatury funkcji, przypadki brzegowe, kontrakt wejścia/wyjścia i dopiero po twojej akceptacji napisać kod. Działa, bo model planujący osobno nie miesza decyzji projektowych z detalami składni — a to właśnie na tym styku rodzi się najwięcej błędów. Dostajesz też punkt kontrolny: tani do poprawienia plan zamiast drogiego do przepisania kodu.

Przykład: Zanim napiszesz kod, opisz w punktach: sygnaturę funkcji, typy wejścia i wyjścia, 3 przypadki brzegowe i sposób obsługi błędów. Zatrzymaj się i poczekaj na moje OK.

W praktyce najczęstszy błąd to pominięcie sekcji „czego NIE robimy”. Dopisz explicite zakres negatywny — bez niego model dorzuca cache'owanie, retry i logowanie, o które nie prosiłeś.

Wzorzec 2: few-shot na konwencjach twojego repo

Model nie zna twojego stylu, dopóki mu go nie pokażesz. Wklej 1–2 istniejące funkcje z kodu i napisz: „trzymaj się dokładnie tej konwencji”. Działa, bo model jest świetny w naśladowaniu wzorca z kontekstu — lepszy w „rób jak to” niż w „rób zgodnie z naszym opisanym gdzieś indziej styleguide”. Nazewnictwo, sposób zwracania błędów, układ importów, testy — wszystko to przejmie z przykładu.

Przykład: Oto jak piszemy handlery w tym projekcie [wklejasz przykładowy handler]. Napisz handler createInvoice w identycznym stylu: ten sam wzorzec walidacji Zod, ta sama struktura Result, te same konwencje nazw.

Dwa dobre przykłady biją dziesięć zdań opisu. Jeśli masz w repo plik, który jest wzorcowy — to jest twój najlepszy prompt.

Wzorzec 3: test-first — najpierw testy, które nie przechodzą

Odwróć kolejność: poproś najpierw o testy opisujące pożądane zachowanie, a dopiero potem o implementację, która je spełni. Działa, bo testy są jednoznacznym kontraktem — model nie może „prawie” spełnić asercji. Dodatkowo dostajesz weryfikowalność: po wygenerowaniu kodu po prostu uruchamiasz testy zamiast czytać go wiersz po wierszu.

Przykład: Napisz najpierw zestaw testów dla funkcji parsePolishDate, włącznie z błędnymi formatami i latami przestępnymi. Testy mają na starcie czerwone. Pokaż mi je, a po akceptacji napisz implementację, która przechodzi wszystkie.

Pułapka: model lubi „naprawić” test zamiast kod, gdy implementacja nie przechodzi. Dopisz: „nie zmieniaj testów bez mojej zgody”.

Wzorzec 4: jawne ograniczenia — stack, zero nowych zależności, zakres plików

Powiedz wprost, czego model NIE może zrobić. Wersja języka, framework, „bez nowych paczek z npm”, „edytuj tylko te dwa pliki”. Działa, bo domyślnie model sięga po najpopularniejsze biblioteki ze swojego treningu — doda lodash,axios albo moment, choć masz natywne fetch i własne utilsy. Ograniczenia zawężają przestrzeń rozwiązań do tej, która pasuje do twojego repo.

Przykład: Ograniczenia: TypeScript strict, React Server Components, bez nowych zależności (używaj natywnego fetch), zmieniasz wyłącznie plik api/users.ts. Nie dotykaj konfiguracji.

Zakres plików to nie drobiazg. Bez niego model „poprawia przy okazji” sąsiednie moduły i dostajesz diff na pół ekranu zamiast na pięć linii.

Wzorzec 5: rola + format wyjścia — „zwróć sam unified diff”

Określ rolę i wymuś dokładny format odpowiedzi. „Jesteś recenzentem”, „zwróć tylko diff”, „żadnego komentarza poza kodem”. Działa dwojako: rola ustawia perspektywę (recenzent szuka błędów, architekt myśli o granicach), a sztywny format wyjścia eliminuje ścianę prozy, przez którą musiałbyś się przekopywać. Diff wkleisz wprost przez git apply; pełny plik musiałbyś diffować ręcznie.

Przykład: Działasz jako senior reviewer. Zwróć WYŁĄCZNIE unified diff (format git), bez wyjaśnień, bez bloku w cudzysłowie. Jeśli zmiana nie jest potrzebna, zwróć pusty diff.

„Tylko diff” ma jeszcze jeden efekt uboczny: model rzadziej przepisuje cały plik, bo musi pokazać minimalną zmianę. Dostajesz mniejsze, łatwiejsze do przejrzenia PR-y.

Wzorzec 6: chain-of-thought przy trudnej logice — „najpierw rozumuj, potem koduj”

Przy nietrywialnym algorytmie (współbieżność, strefy czasowe, niestandardowe parsowanie) każ modelowi rozpisać rozumowanie krok po kroku, zanim napisze kod. Działa, bo model generuje token po tokenie — jeśli najpierw „przemyśli” problem w prozie, kolejne tokeny kodu opierają się na poprawnym rozumowaniu, a nie na pierwszym skojarzeniu. Przy prostym CRUD-zie to zbędne, przy logice obarczonej przypadkami brzegowymi robi realną różnicę.

Przykład: To jest podchwytliwe. Najpierw rozpisz krok po kroku jak obsłużyć zmianę czasu letni/zimowy i strefy bez DST, wypisz pułapki, a DOPIERO POTEM napisz implementację.

Bonus: gdy rozumowanie jest jawne, łatwo wskazać palcem błędny krok i poprawić go, zamiast debugować gotowy, milczący kod.

Wzorzec 7: iteracyjna poprawa — „skrytykuj własny kod”

Po pierwszej wersji nie pisz „popraw to”. Napisz: „przejrzyj własny kod jak surowy reviewer, wypisz 3 najsłabsze miejsca, potem je napraw”. Działa, bo model w trybie krytyka ocenia inaczej niż w trybie generowania — widzi brak obsługi błędów, wyciek zasobu, race condition, których nie zauważył, gdy „po prostu pisał”. To tani drugi przebieg na tym samym kontekście.

Przykład: Wciel się w wymagającego reviewera i znajdź problemy we własnym kodzie: bezpieczeństwo, przypadki brzegowe, wydajność. Wypisz je jako listę, a następnie zwróć poprawioną wersję.

Warto ograniczyć liczbę iteracji do dwóch–trzech. Po trzeciej rundzie model częściej kręci się w miejscu niż realnie poprawia — wtedy lepiej wrócić do wzorca 1 i przepisać spec.

Antywzorce, których unikaj

Trzy najczęstsze grzechy. Po pierwsze: „napisz mi apkę” bez kontekstu — dostaniesz najbardziej generyczny szkielet, jaki istnieje. Po drugie:wklejanie całego repo do kontekstu w nadziei, że „model sobie poradzi” — istotny sygnał ginie w szumie, jakość spada. Po trzecie:akceptowanie kodu, którego nie rozumiesz — jeśli nie umiesz zrecenzować wyniku, żaden prompt cię nie uratuje. Prompt przyspiesza pisanie, nie zwalnia z myślenia.

TL;DR

Siedem wzorców: spec-first (najpierw plan), few-shot na twoich konwencjach, test-first (czerwone testy, potem kod), jawne ograniczenia (stack, zero nowych zależności, zakres plików), rola + format wyjścia (sam diff), chain-of-thought przy trudnej logice, iteracyjna krytyka własnego kodu. Łącz je. Jakość promptu dominuje nad jakością modelu — ten sam Claude czy GPT da ci boilerplate albo dokładnie twój kod, zależnie od tego, jak postawisz kontrakt.