Prompt engineering — jak wyciągnąć maksimum z AI

Różnica między osobą, która "czasem pyta AI", a osobą, która realnie przyspiesza sobie pracę modelem, rzadko wynika z samej subskrypcji. Zwykle wynika z jakości wejścia: jak opisujesz problem, jakie dajesz ograniczenia, jakiego formatu oczekujesz i czy dostarczasz materiał źródłowy. Jeśli nie wiesz jeszcze, którego AI użyć — sprawdź nasze porównanie.

Nie chodzi o magiczne zaklęcia ani tajne słowa-klucze. Dobre promptowanie jest bliższe pisaniu sensownej specyfikacji niż "hackowaniu modelu". Te same umiejętności przydają się przy ticketach, code review, ADR-ach czy opisie buga.

Krótka odpowiedź: Dobry prompt zawiera: kontekst (stack, poziom wiedzy, cel projektu), cel (co dokładnie ma powstać), ograniczenia (czego nie używać, co uwzględnić) i format odpowiedzi (kod, tabela, lista kroków). Reszta to iteracja.

Kluczowe techniki — szybki przegląd

Fundamenty: dlaczego prompt ma znaczenie

Model AI nie czyta w myślach. Odpowiada na to, co napisałeś — nie na to, co miałeś na myśli. Jeśli Twój prompt jest niejasny, zbyt ogólny lub pozbawiony kontekstu, odpowiedź będzie generyczna i mało przydatna.

Porównaj dwa podejścia do tego samego zadania:

Słaby prompt: „Napisz komponent formularza w React."

Lepszy prompt: „Napisz komponent formularza rejestracji w React z TypeScript. Formularz ma pola: email, hasło, potwierdzenie hasła. Użyj react-hook-form z walidacją zod. Pokaż błędy inline pod każdym polem. Styl z Tailwind CSS. Komponent ma być eksportowany jako default export bez wymaganych propsów."

Pierwszy prompt da Ci jakiś formularz. Drugi da Ci formularz, który możesz wrzucić do projektu z minimalnymi zmianami. Różnica w jakości wejścia niemal zawsze przekłada się na jakość wyjścia.

W praktyce dobry prompt prawie zawsze zawiera cztery rzeczy:

• kontekst — nad czym pracujesz i w jakim stacku
• cel — co dokładnie ma powstać albo zostać przeanalizowane
• ograniczenia — czego nie wolno użyć lub co trzeba uwzględnić
• format odpowiedzi — jak ma wyglądać wynik

Techniki, które działają

1. Podawaj kontekst

Kontekst to najważniejszy element dobrego prompta. Model nie wie, nad czym pracujesz, jaki masz stack technologiczny, jakie masz ograniczenia ani jaki jest Twój poziom wiedzy.

Bez kontekstu: „Jak zoptymalizować wydajność strony?"

Z kontekstem: „Mam aplikację Next.js 14 (App Router) z SSRSSR, czyli Server-Side Rendering, oznacza generowanie HTML na serwerze przy każdym żądaniu.. Lighthouse pokazuje LCPLCP, czyli Largest Contentful Paint, mierzy czas wyrenderowania największego widocznego elementu na ekranie. 4.2s na mobile. Główny problem to duży bundleBundle to paczka JavaScriptu lub innych zasobów wysyłana do przeglądarki jako część aplikacji. JS (380KB gzipped) i wolne ładowanie obrazów hero. Jakie konkretne kroki powinienem podjąć, żeby zejść poniżej 2.5s LCP?"

Kontekst zawęża przestrzeń odpowiedzi i eliminuje generyczne porady typu „użyj lazy loadingLazy loading oznacza ładowanie zasobów dopiero wtedy, gdy są potrzebne, na przykład po przewinięciu strony." na rzecz konkretnych rozwiązań dopasowanych do Twojej sytuacji.

2. Definiuj format wyjścia

Jeśli nie powiesz modelowi, w jakim formacie chcesz odpowiedź, wybierze sam — i może nie być to format, którego potrzebujesz.

Przydatne instrukcje formatowania to np. „Odpowiedz jako lista kroków z kodem", „Daj mi tylko kod, bez wyjaśnień", „Porównaj w tabeli: kolumny to [X], [Y], [Z]", „Napisz to jako komentarz do PR na GitHubie" albo „Sformatuj jako plik MDX z frontmatter".

3. Dawaj przykłady (few-shot prompting)

Zamiast opisywać pożądane wyjście, pokaż przykład. Modele AI są bardzo dobre w rozpoznawaniu wzorców.

Przekształć następujące opisy w formaty eventów GA4:

Przykład:
Opis: "Użytkownik kliknął przycisk 'Kup teraz' na stronie produktu"
Event: gtag('event', 'select_item', { item_id: 'SKU_001', item_name: 'Produkt', content_type: 'product' });

Opis: "Użytkownik dodał produkt do koszyka z cennika"
Event: gtag('event', 'add_to_cart', { item_id: 'SKU_002', item_name: 'Produkt', price: 99.99, currency: 'PLN' });

Teraz przekształć:
Opis: "Użytkownik zapisał się na newsletter po przeczytaniu artykułu na blogu"

Model widzi wzorzec i kontynuuje go — forma, konwencja nazewnictwa, struktura parametrów — wszystko jest spójne z przykładami.

4. Rozbij problem na kroki i wymuś strukturę odpowiedzi

Przy złożonych problemach nie chodzi o to, żeby model "ujawnił tajne myśli". Chodzi o to, żeby nie przeskakiwał od razu do rozwiązania bez rozłożenia problemu na części. Najlepiej działa prośba o ustrukturyzowaną analizę: problem, hipoteza, ryzyko, rekomendacja, plan działania.

Przeanalizuj ten kod i znajdź potencjalne problemy z wydajnością.
Dla każdego problemu:
1. Opisz, co konkretnie jest nie tak
2. Wyjaśnij, jaki ma wpływ na wydajność
3. Zaproponuj rozwiązanie z kodem
4. Oceń trudność implementacji (łatwa/średnia/trudna)

[wklej kod]

To daje podobny efekt jak "myślenie krok po kroku", ale w formie dużo bardziej praktycznej i kontrolowalnej.

5. Przypisz rolę (persona)

Definiowanie roli pomaga modelowi dobrać odpowiedni poziom szczegółowości i perspektywę.

„Jesteś seniorem frontend developerem robiącym code review. Przejrzyj ten komponent React i wskaż problemy z wydajnością, dostępnością i utrzymywalnością kodu."

Albo: „Jesteś technical writerem dokumentującym APIAPI, czyli Application Programming Interface, definiuje sposób komunikacji między aplikacjami lub modułami.. Napisz dokumentację dla tego endpointu, uwzględniając przykłady request/response, kody błędów i edge case'y."

Rola nie "zamienia" modelu w seniora czy technical writera. Po prostu sygnalizuje perspektywę i kryteria oceny, których oczekujesz.

6. Definiuj ograniczenia (constraints)

Ograniczenia pomagają uniknąć odpowiedzi, których nie chcesz.

Napisz funkcję do walidacji adresu email.

Ograniczenia:
- Czysty TypeScript, zero zewnętrznych bibliotek
- Użyj regex, nie sprawdzania po znakach
- Obsłuż edge case'y: plus addressing (user+tag@domain.com),
  subdomeny (user@mail.company.com), TLD dłuższe niż 3 znaki
- Zwróć obiekt { valid: boolean, error?: string }
- Maksymalnie 30 linii kodu

7. Iteruj i doprecyzowuj

Prompt engineering to nie jednorazowy strzał. Traktuj rozmowę z AI jak iteracyjny proces.

Pierwszy prompt: „Napisz komponent tabeli danych." Odpowiedź jest OK, ale brak sortowania. Drugi prompt: „Dodaj sortowanie po kliknięciu w nagłówek kolumny. Pokaż strzałkę wskazującą kierunek sortowania." Odpowiedź jest lepsza, ale sortowanie nie obsługuje dat. Trzeci prompt: „Sortowanie dat powinno porównywać obiekty Date, nie stringi. Dodaj typ kolumny ('text' | 'number' | 'date') i sortuj odpowiednio."

Każda iteracja buduje na poprzedniej. To ważne szczególnie przy kodzie: rzadko najlepszy wynik powstaje z jednego prompta. Dużo częściej z dwóch albo trzech sensownych iteracji.

Techniki zaawansowane

Prompt chaining

Rozbij złożone zadanie na sekwencję prostszych promptów, gdzie wyjście jednego staje się wejściem następnego.

Zamiast jednego mega-promptu: „Zaprojektuj i zaimplementuj system autentykacji z JWTJWT, czyli JSON Web Token, to podpisany token używany często do autoryzacji i przekazywania tożsamości użytkownika. w Next.js", rozłóż to na kroki. Najpierw: „Opisz architekturę systemu autentykacji z JWT w Next.js App Router. Jakie endpointy, middleware i utilities będę potrzebował?" Potem: „Na podstawie tej architektury napisz middleware do weryfikacji JWT." Następnie: „Teraz napisz endpoint /api/auth/login." I dalej.

Każdy krok jest prostszy, a odpowiedzi są bardziej precyzyjne.

Negative prompting

Mów modelowi, czego NIE chcesz. To zaskakująco skuteczna technika.

Napisz komponent React do wyświetlania listy użytkowników.

NIE używaj:
- Class components
- Redux ani żadnego globalnego state management
- Inline styles
- any type w TypeScript
- console.log do debugowania
- TODO komentarzy

Rubber duck debugging z AI

Zamiast prosić AI o rozwiązanie buga, opisz mu problem krok po kroku — tak, jakbyś tłumaczył go gumowej kaczce. Często sam proces opisywania problemu naprowadzi Cię na rozwiązanie, a AI może pomóc zweryfikować Twoje rozumowanie.

Debuguję problem z infinite re-renders w komponencie React.

Co robię:
1. Mam komponent ProductList, który pobiera dane z API w useEffect
2. Dane zapisuję w useState
3. Komponent renderuje listę z każdego elementu danych
4. Każdy element listy ma przycisk "Dodaj do koszyka"
5. Kliknięcie przycisku aktualizuje stan koszyka (useContext)
6. Po aktualizacji koszyka komponent ProductList renderuje się ponownie
7. Re-render triggeruje useEffect ponownie
8. useEffect pobiera dane ponownie i aktualizuje stan
9. Aktualizacja stanu triggeruje re-render → pętla

Czy moje rozumowanie jest poprawne? Jeśli tak, jakie rozwiązanie
proponujesz?

System prompts i custom instructions

Jeśli regularnie pracujesz z AI nad tym samym typem zadań, stwórz sobie „bazowy prompt", który ustawiasz jako system instructions lub custom instructions.

Przykład custom instructions dla frontend developera:

Jestem frontend developerem pracującym z Next.js 14 (App Router),
TypeScript, Tailwind CSS i React Query.

Kiedy piszesz kod:
- Zawsze TypeScript ze ścisłym typowaniem (no any)
- Komponenty jako function components z hooks
- Tailwind do stylowania, nie CSS modules
- Nazwy zmiennych i funkcji po angielsku
- Komentarze tylko gdy logika jest nietrywialna

Kiedy wyjaśniasz:
- Zakładaj, że znam podstawy React i JS
- Skup się na "dlaczego", nie "jak" (chyba że pytam o implementację)
- Podawaj linki do dokumentacji gdy to pomocne

To działa najlepiej jako stały "baseline", a nie jako substytut dobrych promptów do konkretnych zadań. Custom instructions ustawiają domyślne oczekiwania, ale nadal musisz dostarczyć kontekst zadania.

Prompt engineering w kontekście kodu

Code review

Zrób code review tego komponentu React.

Oceń:
1. Poprawność logiki
2. Wydajność (niepotrzebne re-rendery, brak memoizacji)
3. Dostępność (a11y)
4. Obsługę błędów i edge case'ów
5. Czytelność i utrzymywalność

Dla każdego problemu zaproponuj fix z kodem.
Oceń severity: critical / warning / suggestion.

[kod]

Generowanie testów

Napisz testy jednostkowe dla tej funkcji.

Użyj: vitest + @testing-library/react
Pokryj scenariusze:
- Happy path
- Puste dane wejściowe
- Nieprawidłowe dane (edge cases)
- Boundary conditions

Format: describe/it z czytelnymi nazwami testów po angielsku.

[kod funkcji]

Migracja kodu

Zmigruj ten komponent z React class component na function component
z hooks.

Wymagania:
- Zachowaj identyczne zachowanie
- Zamień this.state na useState
- Zamień lifecycle methods na useEffect
- Zachowaj prop types (zamień na TypeScript interface)
- Wyodrębnij logikę do custom hooka jeśli ma sens

Pokaż kod przed i po, oznaczając co się zmieniło.

[kod class component]

Czego unikać

Zbyt ogólne prompty — „Napisz mi aplikację" to jak powiedzieć architektowi „zbuduj dom". Bez specyfikacji dostaniesz coś generycznego.

Zbyt długie prompty — paradoksalnie, mega-prompty z 20 wymaganiami na raz często dają gorsze wyniki niż seria krótszych, precyzyjnych zapytań. Model gubi się w natłoku instrukcji.

Brak materiału źródłowego — jeśli pytasz o bug, ale nie dajesz stacktrace'u, kawałka kodu, oczekiwanego zachowania i tego, co już sprawdziłeś, model będzie zgadywał. A zgadywanie wygląda przekonująco, ale rzadko prowadzi do najlepszej odpowiedzi.

Bezrefleksyjne kopiowanie kodu — AI generuje kod, który wygląda poprawnie, ale może mieć subtelne bugi, problemy z bezpieczeństwem albo antypatterns. Zawsze czytaj wygenerowany kod ze zrozumieniem. Traktuj AI jak juniora, który pisze szybko, ale potrzebuje review.

Zakładanie, że AI zawsze ma rację — modele mogą konfabulować (wymyślać API, które nie istnieje, metody, które nie działają w danej wersji biblioteki). Weryfikuj krytyczny kod w dokumentacji.

FAQ

Co to jest prompt engineering?

Prompt engineering to praktyka formułowania zapytań do modeli AI w sposób, który prowadzi do użytecznych, precyzyjnych odpowiedzi. Nie chodzi o "magiczne słowa" ani manipulację modelem — chodzi o jasne opisanie kontekstu, celu, ograniczeń i oczekiwanego formatu. Te same umiejętności, które pomagają pisać dobre tickety i specyfikacje techniczne, działają przy promptowaniu.

Jakie są najważniejsze techniki prompt engineeringu dla developerów?

Najskuteczniejsze techniki: (1) Kontekst — podaj stack, framework, poziom wiedzy; (2) Format wyjścia — określ czy chcesz kod, listę kroków, tabelę; (3) Few-shot — pokaż przykład pożądanego wyniku; (4) Ustrukturyzowana analiza — poproś o odpowiedź według schematu (problem → hipoteza → fix); (5) Ograniczenia — powiedz czego NIE robić; (6) Iteracja — nie oczekuj perfekcji w pierwszym promptcie.

Jak pisać lepsze prompty do generowania kodu?

Minimum dobrego promptu do kodu: technologia i wersja (React 18, Next.js 15, TypeScript), co ma robić (nie "komponent tabeli" ale "komponent tabeli z sortowaniem po nagłówku, paginacją i filtrami"), czego nie używać (no any, no inline styles, bez Redux), format (default export, custom hook jeśli logika jest złożona). Opcjonalnie: kontekst (gdzie to trafi, jak się integruje z resztą aplikacji).

Co to jest few-shot prompting?

Few-shot prompting to technika pokazywania modelowi 1-3 przykładów wejście → wyjście przed właściwym zapytaniem. Model rozpoznaje wzorzec i stosuje go do nowego przypadku. Skuteczne przy generowaniu kodu z konkretną konwencją, transformacji danych, formatowaniu dokumentacji lub tworzeniu testów według określonego schematu nazewnictwa.

Jak unikać hallucynacji AI przy pracy z kodem?

Hallucynacje (wymyślone API, nieistniejące metody, błędne wersje) są częstsze przy pytaniach o nowe biblioteki i niszowe frameworki. Strategie: weryfikuj wygenerowany kod w oficjalnej dokumentacji zanim go uruchomisz, pytaj model "skąd wiesz, że ta metoda istnieje?", podawaj fragment dokumentacji lub typów jako kontekst, używaj modeli z dostępem do internetu dla aktualnych informacji.

Czy prompt engineering działa tak samo w Claude, ChatGPT i Gemini?

Fundamenty są takie same — kontekst, cel, format, ograniczenia. Różnice są w szczegółach: Claude radzi sobie szczególnie dobrze z długimi, wielostopniowymi analizami i code review. ChatGPT lepiej wykonuje zadania łączące różne narzędzia (pisanie + wyszukiwanie + kod). Gemini ma przewagę przy promptach, które korzystają z kontekstu z dokumentów Google lub bardzo dużych fragmentów kodu. Więcej w porównaniu Claude vs ChatGPT vs Gemini.

Jak używać custom instructions / system prompts w codziennej pracy?

Custom instructions to "stały kontekst", który jest wysyłany z każdym promptem — możesz tam wpisać swój stack (Next.js, TypeScript, Tailwind), preferencje (no class components, strict TypeScript), poziom wiedzy i format odpowiedzi. Oszczędza pisania tych samych informacji przy każdym zapytaniu. Traktuj je jako baseline — konkretne zadania nadal wymagają dokładnego opisu.

Podsumowanie

Prompt engineering to nie osobna dyscyplina — to rozszerzenie umiejętności, które już masz jako developer. Jasne definiowanie wymagań, rozkładanie problemów na części, iteracyjne podejście, precyzja w komunikacji — to samo, co robisz pisząc user stories, ticket-y czy specyfikacje techniczne.

Najlepszy sposób na naukę to praktyka. Zacznij od świadomego formułowania promptów w codziennej pracy. Kiedy dostaniesz słabą odpowiedź, nie pytaj od razu "który model jest lepszy?", tylko najpierw sprawdź, czy dobrze opisałeś zadanie, kontekst i format wyniku.

Najkrótsza definicja prompt engineeringu, którą warto zapamiętać, brzmi: pisz do modelu tak, jak pisałbyś dobry brief do innego developera. Im mniej miejsca zostawiasz na zgadywanie, tym lepszy dostajesz wynik.

Chcesz wiedzieć, który model AI wybrać? Sprawdź Claude vs ChatGPT vs Gemini — porównanie dla developerów i porównaj, który najlepiej pasuje do Twojego workflow.