Przejdź do treści
Czym są prompty i dlaczego to najważniejsza umiejętność AI-era developera
··5 min czytania·Zaktualizowano:

Czym są prompty i dlaczego to najważniejsza umiejętność AI-era developera

Prompt to nie pytanie - to instrukcja sterująca

Większość developerów traktuje prompt jak wyszukiwarkę Google: wpisują „zrób mi endpoint“ i czekają na cud. Tymczasem prompt to coś fundamentalnie innego - to instrukcja sterująca, która determinuje jakość, styl i poprawność wygenerowanego kodu.

Pomyśl o tym tak: prompt jest dla modelu AI tym, czym brief jest dla freelancera. Im lepiej opiszesz, czego oczekujesz, tym mniej iteracji będziesz potrzebować.

Co oznacza nadanie AI roli w prompcie?

Nadanie AI roli oznacza wskazanie perspektywy, priorytetów i sposobu oceny odpowiedzi, na przykład: „jesteś reviewerem bezpieczeństwa” albo „działasz jako architekt systemów rozproszonych”. Rola pomaga modelowi dobrać słownictwo, checklistę i poziom szczegółowości.

Nie daje mu jednak nowych faktów ani magicznie nie zmienia modelu w seniora. Samo „jesteś ekspertem” jest słabe, jeśli nie podasz zadania, kontekstu i kryteriów wyniku.

Słaby wariant:

Jesteś senior developerem. Zrób review tego kodu.

Lepszy wariant:

Działasz jako reviewer bezpieczeństwa aplikacji ASP.NET Core.
Sprawdź wyłącznie autoryzację, walidację wejścia i ekspozycję danych.
Dla każdego problemu podaj plik, ryzyko i najmniejszą poprawkę.
Nie przepisuj kodu, którego problem nie dotyczy.

Rola ustawia filtr. Kontekst i ograniczenia wykonują większość pracy. Więcej gotowych wariantów znajdziesz w tutorialu typowe role agentów AI oraz w lekcji Anatomia dobrego promptu w GitHub Copilot.

Anatomia dobrego promptu

Każdy skuteczny prompt do kodowania składa się z kilku warstw:

1. Kontekst (Context)

Co model powinien wiedzieć zanim zacznie działać:

Pracuję w projekcie ASP.NET Core 9 z Entity Framework Core.
Architektura: Clean Architecture z CQRS.
Baza danych: PostgreSQL.

Bez kontekstu model zgaduje. Z kontekstem - wie.

2. Zadanie (Task)

Konkretne polecenie - co ma powstać:

Stwórz endpoint POST /api/orders, który przyjmuje CreateOrderCommand
i zapisuje zamówienie w bazie.

3. Ograniczenia (Constraints)

Reguły, których model ma przestrzegać:

Użyj MediatR do obsługi command.
Walidacja przez FluentValidation.
Nie używaj AutoMappera - mapuj ręcznie.

4. Format wyjścia (Output format)

Jak ma wyglądać odpowiedź:

Zwróć tylko kod C#, bez wyjaśnień.
Każdy plik osobno z nagłówkiem // FileName.cs

Typy promptów w narzędziach AI do kodowania

W praktyce używasz promptów na kilku poziomach, często tego nie zauważając:

Inline prompts (komentarze w kodzie)

Najprostszy typ - piszesz komentarz, a Copilot generuje implementację:

// Funkcja walidująca PESEL - sprawdza sumę kontrolną i datę urodzenia
function validatePesel(pesel: string): boolean {
// Copilot dokończy...
}

Kiedy działają dobrze? Gdy kontekst z otaczającego kodu jest wystarczający.

Chat prompts (Copilot Chat, Claude)

Interaktywne prompty w oknie czatu - pozwalają na dialog:

Przeanalizuj ten kontroler i zaproponuj refaktoryzację.
Obecne problemy:
- Za dużo logiki w akcjach
- Brak walidacji
- Powtarzający się kod obsługi błędów

Kiedy działają dobrze? Gdy potrzebujesz analizy, wyjaśnienia lub wieloetapowej zmiany.

System prompts (instrukcje globalne)

Trwałe instrukcje, które kształtują zachowanie modelu przez cały czas:

  • .github/copilot-instructions.md w GitHub Copilot
  • CLAUDE.md w Claude Code
  • Custom instructions w ChatGPT

To fundament - o tym więcej w osobnym artykule o instrukcjach.

5 wzorców promptów, które działają w kodowaniu

Wzorzec 1: „Rola + Zadanie“

Jesteś senior .NET developerem specjalizującym się w performance.
Przeanalizuj ten query EF Core i zaproponuj optymalizację:
[kod]

Rola zawęża perspektywę odpowiedzi. Największą różnicę robi dopiero wtedy, gdy łączysz ją z konkretnym zakresem i kryteriami wyniku.

Wzorzec 2: „Pokaż mi wzorzec, dopasuj resztę“

Mam taki wzorzec serwisu:
public class OrderService : IOrderService
{
private readonly IOrderRepository _repo;
public OrderService(IOrderRepository repo) => _repo = repo;
public async Task<Order> GetByIdAsync(int id) =>
await _repo.GetByIdAsync(id)
?? throw new NotFoundException(nameof(Order), id);
}
Stwórz analogiczny ProductService z metodami:
GetByIdAsync, GetAllAsync, CreateAsync

Model widzi wzorzec i replikuje styl. To dużo skuteczniejsze niż opisywanie konwencji słownie.

Wzorzec 3: „Kontekst negatywny“

Stwórz middleware do obsługi wyjątków w ASP.NET Core.
NIE UŻYWAJ:
- try-catch w kontrolerach
- IExceptionFilter
- UseExceptionHandler z lambda
UŻYJ: custom middleware z ILogger i ProblemDetails.

Mówienie modelowi czego nie robić jest równie ważne jak mówienie, co robić. Eliminuje najczęstsze „halucynacje stylistyczne“.

Wzorzec 4: „Krok po kroku“

Chcę dodać paginację do endpointu GET /api/products.
Krok 1: Stwórz klasę PaginationParams (PageNumber, PageSize)
Krok 2: Stwórz generyczny PagedResult<T>
Krok 3: Dodaj metodę rozszerzającą ToPagedResult() na IQueryable
Krok 4: Zaktualizuj kontroler i repozytorium

Rozbijesz złożone zadanie na kroki - model nie będzie próbował robić wszystkiego naraz (i nie pogubi się po drodze).

Wzorzec 5: „Przeanalizuj, potem działaj“

Zanim cokolwiek zmienisz, przeanalizuj ten kod i wypisz:
1. Co ten kod robi
2. Jakie ma problemy
3. Co proponujesz zmienić i dlaczego
Dopiero po mojej akceptacji wprowadź zmiany.

Ten wzorzec wymusza fazę „myślenia“ przed działaniem. Kluczowy przy refaktoryzacjach i zmianach w krytycznym kodzie.

Czego unikać w promptach

❌ Zbyt ogólne polecenia

Zrób mi API

Model nie wie: jakie API, w jakim frameworku, z jaką bazą, jakie endpointy. Wynik będzie generyczny i bezużyteczny.

❌ Za dużo naraz

Stwórz kompletny system e-commerce z koszykiem, płatnościami,
zarządzaniem produktami, systemem uprawnień, logowaniem,
raportami i integracją z kurierami.

Jedno zapytanie = jedno zadanie. Złożone systemy budujesz iteracyjnie.

❌ Sprzeczne instrukcje

Użyj Repository Pattern, ale nie twórz interfejsów.
Kod ma być testowalny, ale bez dependency injection.

Model próbuje spełnić wszystkie warunki jednocześnie - efekt jest chaotyczny.

Prompt engineering to nie buzzword - to rzemiosło

Nie musisz uczyć się „magicznych zaklęć“. Musisz nauczyć się precyzyjnie komunikować intencje - tak jak uczysz się pisać dobre user stories, PR descriptions czy commit messages.

Dobry prompt to:

  • Konkretny - jedno jasne zadanie
  • Kontekstowy - model wie, w jakim środowisku pracujesz
  • Ograniczony - wie, czego nie robić
  • Weryfikowalny - łatwo sprawdzisz, czy wynik jest poprawny

Co dalej?

Prompty to pierwszy poziom. Kolejny to instrukcje - trwałe reguły, które kształtują zachowanie AI w całym projekcie bez powtarzania się w każdym prompcie. Przeczytaj o nich w artykule: Instrukcje w GitHub Copilot - scope, foldery, typy plików.

Nowe materiały prosto na maila

Publikuję nowy artykuł albo lekcję kursu — dostajesz jednego maila. Nic poza tym.

Bez cyklu wydawniczego i newsów o każdej premierze modelu

Zapisy do newslettera otwieram partiami, żeby nie zamieniać go w kolejny kanał ze spamem i recyklingiem linków.

Jeśli chcesz dostać informację przy następnym otwarciu zapisów, napisz na kontakt@efektywnydev.pl.

UdostępnijX / TwitterLinkedIn
Marcin Szymański

O autorze

Marcin Szymański

Od kilkunastu lat buduję systemy w .NET i Azure — obecnie rozproszony monitoring PingView. Piszę tu o pracy człowiek + agenci AI na realnych workflow, nie na demach. Zawodowo prowadzę audyty, rescue projektów i wdrożenia AI-assisted delivery w zespołach.