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ć.

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]

Nadanie roli zmienia „osobowość” odpowiedzi - model generuje kod na poziomie seniora, a nie generyczny snippet.

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.