Rok temu mój prompt do AI wyglądał tak: “napisz mi funkcję, która pobierze dane z API i wrzuci do tabeli”. Dostawałem coś, co kompilowało się, ale nie działało, jak chciałem. Potem 30 minut iteracji “nie, nie tak, jeszcze inaczej”. Frustracja, koniec końców pisałem sam.

Dziś moje prompty mają 200 słów, kontekst projektu, przykład wejścia, oczekiwane wyjście, ograniczenia. Odpowiedź jest poprawna w 80% przypadków za pierwszym razem. Te 20%, które nie są, naprawiam jednym followupem.

Różnica nie jest w modelu (Claude i ChatGPT są obie potężne). Różnica jest w tym, jak się je pyta. Promptowanie to nie sztuka. To technika, której można się nauczyć w popołudnie.

Co to promptowanie naprawdę znaczy

Promptowanie to projektowanie zapytania do AI, żeby dostać użyteczną odpowiedź. Brzmi banalnie, ale ludzie traktują AI jak Google’a (“powiedz mi X”) albo jak juniora (“zrób mi to”). Oba podejścia działają słabo.

AI nie jest Google’em (nie odpowiada faktem, generuje tekst). AI nie jest juniorem (nie ma kontekstu Twojego projektu, dopóki mu go nie dasz). AI jest jak nowy konsultant, który wszedł do projektu pierwszego dnia. Świetnie zna technologie, kompletnie nie zna Twojej firmy.

Promptowanie to akt dawania kontekstu, którego konsultantowi by się dało, plus konkretnego zadania.

Dlaczego standardowy prompt nie działa

“Napisz mi funkcję, która pobierze dane z API”. Co jest nie tak?

  • Brak języka (TS? JS? Python?)
  • Brak frameworka (Next.js, Express, czysty Node?)
  • Brak struktury API (REST? GraphQL? Jakie pola?)
  • Brak obsługi błędów (co jak API nie odpowie?)
  • Brak typu zwracanego (Promise? Synchroniczne? Stream?)
  • Brak konwencji projektu (async/await? then/catch? Twoja kapitalizacja?)

AI musi zgadnąć każde z tych 6 rzeczy. Najczęściej zgadnie inaczej, niż chciałeś. Stąd “nie, nie tak”.

Lepszy prompt:

“Napisz funkcję w TypeScript dla Next.js 15 App Router, która pobiera listę produktów z REST API pod /api/products. API zwraca { id: string, name: string, price: number }[]. Funkcja ma być Server Action, zwracać Promise<Product[]>, obsługiwać błąd 500 jako rzucony Error z czytelnym message. Używamy async/await. Nazwa: getProducts.”

Dwie minuty pisania promptu, jedna iteracja zamiast pięciu. Net plus 10 minut na każdej takiej operacji.

Anatomia dobrego promptu dla kodu

Mój standardowy szablon ma 5 części.

1. Kontekst projektu (1-2 zdania). “Pracuję w monorepo Next.js 15 + Strapi v5. Frontend w TypeScript, używamy Server Components.”

2. Konkretne zadanie (1 zdanie). “Potrzebuję funkcji X, która robi Y.”

3. Wejście i wyjście. “Wejście: typ A z polami a, b, c. Wyjście: typ B z polami d, e.”

4. Ograniczenia i konwencje. “Async/await, nie then/catch. Funkcje strzałkowe. Bez external deps poza tymi, co już mamy w package.json.”

5. Format odpowiedzi. “Pokaż tylko kod, bez wyjaśnień. Komentarze tylko tam, gdzie logika nieoczywista.”

Jak Ci się chce, dodaj jeszcze przykład wywołania (“await getProducts({ category: 'shoes' })” zwraca [{...}]”). To zwykle eliminuje całą klasę nieporozumień.

Mój prompt do code review

Drugi typ promptu, którego używam codziennie:

“Zrób code review tego pliku. Skup się na: edge cases, których nie obsłużyłem; potencjalnych race conditions; miejscach, gdzie typ jest za luźny (any, unknown bez powodu); naruszeniach SOLID. Nie komentuj stylu kodu (mamy linter). Nie sugeruj refaktoru, jeśli nie ma realnego problemu. Dla każdego znaleziska: nr linii, problem, sugestia.”

Klucz: powiedz, czego NIE komentować. Inaczej AI dorzuci 30 sugestii kosmetycznych, w których utopisz 3 realne problemy.

Mój prompt do debugowania

“Mam ten błąd: [paste stack trace]. Kod wygląda tak: [paste]. To się dzieje w środowisku [dev/prod]. Wczoraj działało, dziś nie, jedyna zmiana to [opis]. Zaproponuj 3 możliwe przyczyny w kolejności prawdopodobieństwa, plus jak każdą zweryfikować.”

Trzy hipotezy zamiast jednej. AI często ma rację za drugim albo trzecim razem, ale pierwsze rozwiązanie testujesz krócej, niż zakopałbyś się w pierwszym wadliwym wyjaśnieniu.

Mój prompt do nauki nowego API

“Chcę zrozumieć, jak działa [biblioteka X], konkretnie [funkcja Y]. Wyjaśnij mi to w 3 punktach: 1) co to robi, 2) typowy use case, 3) najczęstsza pomyłka. Potem pokaż minimalny przykład w TS. Bez wstępu typu ‘X is a powerful library’.”

To zastępuje mi przewijanie dokumentacji do działającego przykładu. 30 sekund zamiast 20 minut.

Promptowanie vs agent mode

Dwa różne tryby pracy z AI.

Promptowanie klasyczne. Ty pytasz, AI odpowiada, Ty kopiujesz odpowiedź. Najlepsze do dyskretnych zadań: napisz funkcję, wyjaśnij koncept, zaproponuj rozwiązanie.

Agent mode (Claude Code, Cursor Agent). AI ma narzędzia, sam czyta pliki, sam edytuje, sam uruchamia komendy. Najlepsze do zadań wymagających kontekstu wielu plików: refaktor, migracja, dopisanie testów do modułu.

Pisałem o tym szerzej w poprzednim poście o AI tooling.

Reguła kciuka: jeśli zadanie mieści się w jednym pliku, klasyczny prompt. Jeśli wymaga zmiany 5 plików, agent.

W agent mode prompt jest bardziej ogólny i strategiczny: “Zmień to API z REST na GraphQL we wszystkich miejscach, gdzie jest używane. Zacznij od plików w src/api/, potem zaktualizuj komponenty, które je konsumują. Pokaż mi plan przed zmianami.”

Najczęstsze błędy w promptowaniu

Brak kontekstu projektu. AI nie zna Twojej struktury folderów, używanych bibliotek, konwencji. Daj mu te informacje jednym zdaniem na początku.

Pytanie o “najlepsze rozwiązanie”. Nie ma najlepszego rozwiązania w oderwaniu od kontekstu. Pytaj: “Najlepsze rozwiązanie dla projektu, w którym X jest priorytetem, a Y nas nie obchodzi”.

Akceptacja pierwszej odpowiedzi. AI często daje rozwiązanie, które działa, ale nie jest optymalne. Pytaj “co byś zmienił w tym kodzie po code review” albo “jakie są wady tego podejścia”.

Brak ograniczeń. “Napisz to bez używania biblioteki X” albo “rozwiązanie musi mieścić się w 30 linijkach” daje znacząco lepsze odpowiedzi niż otwarte pytanie.

Mieszanie kontekstów. Jedno pytanie = jeden temat. Jeśli rozmowa o React-cie zaczyna się wkręcać w typy, otwórz nowy czat dla typów.

Brak roli. “Działaj jak senior TypeScript engineer, który optymalizuje pod performance” zmienia ton i jakość odpowiedzi. Trochę szarlataneria, ale działa.

Promptowanie do innych zadań niż kod

AI nie służy tylko do kodu. Inne sposoby, których używam:

Pisanie postów na bloga. Daję AI swój wcześniejszy post jako wzorzec, mówię “napisz w tym samym tonie i strukturze post o X, ale tylko outline, ja wypełnię treścią”. 5 minut zamiast 30.

Maile do klienta. Daję kontekst sytuacji (“klient zwleka z płatnością 3 tygodnie, do tej pory dobre relacje”), proszę o draft. Edytuję pod siebie. Oszczędzam emocje, bo nie zaczynam od zera.

Brainstorm. “Wymyśl 20 nazw dla produktu X, użyj różnych mechanik (anagramy, polskie słowa, angielskie portmanteau)”. Dostaję 20 opcji, 18 odrzucam, 2 zostają jako kandydaci.

Tłumaczenia. Mój angielski jest OK, ale AI łapie niuanse (“formalny, ale nie sztywny”), których nie złapię sam.

Od czego zacząć

Jeśli dziś promptujesz po staremu (“napisz mi X”):

  1. Wybierz jedno powtarzalne zadanie (pisanie nowych endpointów, code review, debugowanie).
  2. Napisz szablon promptu z 5 części opisanych wyżej.
  3. Używaj go przez tydzień, modyfikując po każdej iteracji, która nie zadziałała.
  4. Po tygodniu masz osobisty szablon, który działa dla Twojego stacka i konwencji.
  5. Powtórz dla drugiego typu zadania.

Promptowanie to umiejętność, która zwraca się natychmiast i rośnie z każdym dniem. Programiści, którzy się jej nie nauczą, będą walczyć ze swoim AI i narzekać, że “te modele są głupie”. Programiści, którzy się nauczą, dostaną kod gotowy do mergeu na pierwszą próbę.

Pisałem już, że AI nie zastąpi programistów. Zastąpi tych, którzy nie potrafią z nim rozmawiać.