Typowe role agentów AI

Agent AI to nie jednowymiarowe narzędzie do „pisania kodu”. W zależności od tego, jak go użyjesz, może pełnić fundamentalnie różne role w Twoim workflow. Każda rola wymaga innego podejścia, innych promptów i innej relacji: zaufania vs. weryfikacji.

Rola 1: Koder

Kiedy: Piszesz nowy kod - endpoint, serwis, komponent, migrację.

Relacja: Agent pisze, Ty prowadzisz i weryfikujesz.

Jak używać agenta jako kodera

User: Stwórz serwis ProductService implementujący IProductService.

      Wzorce - patrz OrderService w tym samym folderze.
      Metody: GetByIdAsync, GetAllAsync, CreateAsync, UpdateAsync.

      Wymagania:
      - Result pattern (nie rzucaj wyjątków)
      - CancellationToken w każdej async metodzie
      - Logowanie przez ILogger
      - Walidacja inputu w CreateAsync i UpdateAsync

Kluczowe zasady

Daj wzorzec - pokaż istniejący kod, nie opisuj konwencji słownie
Definiuj scope - wylistuj metody, nie mów „stwórz CRUD”
Ogranicz - powiedz czego NIE używać
Iteruj - lepiej 3 małe prompty niż jeden mega-prompt

Kiedy agent sprawdza się jako koder

Boilerplate code (CRUD, DTO, mapowania)
Implementacja znanych wzorców (Repository, Mediator, Observer)
Kod według istniejącego szablonu
Prototypowanie i proof of concept

Kiedy uważać

Algorytmy biznesowe z wieloma edge case’ami
Kod wymagający głębokiej znajomości domeny
Optymalizacja wydajności (agent może wybrać czytelność nad performance)

Rola 2: Code Reviewer

Kiedy: Masz gotowy kod (swój lub agenta) i chcesz go zweryfikować.

Relacja: Agent ocenia, Ty decydujesz.

Jak używać agenta jako reviewera

User: Przeanalizuj ten Pull Request pod kątem:

      1. Bezpieczeństwo (OWASP Top 10)
      2. Wydajność (N+1 queries, niepotrzebne alokacje)
      3. Spójność z konwencjami projektu (patrz .github/copilot-instructions.md)
      4. Czytelność i utrzymywalność
      5. Brakujące testy

      Dla każdego problemu podaj:
      - Plik i linię
      - Opis problemu
      - Severity: critical / warning / suggestion
      - Propozycję poprawki

      Nie sugeruj zmian stylistycznych (formatowanie, sortowanie importów).

Template do code review

User: Review ten kod:

      [wklej kod lub wskaż pliki]

      Konwencje projektu:
      - Clean Architecture
      - CQRS z MediatR
      - Result pattern zamiast wyjątków
      - FluentValidation

      Focus: bezpieczeństwo i wydajność.
      Ignoruj: nazewnictwo, formatowanie.

Kluczowe zasady

Określ focus - „bezpieczeństwo i wydajność” zamiast „sprawdź wszystko”
Podaj konwencje - agent nie zna Twoich reguł, jeśli mu ich nie dasz
Filtruj szum - powiedz co ignorować (formatowanie, sortowanie importów)
Wymagaj severity - nie każdy problem jest critical

Rola 3: Tester

Kiedy: Potrzebujesz testów jednostkowych, integracyjnych lub E2E.

Relacja: Agent generuje testy, Ty weryfikujesz ich jakość i pokrycie.

Jak używać agenta jako testera

User: Wygeneruj testy jednostkowe dla OrderService.

      Framework: xUnit + FluentAssertions + NSubstitute
      Pattern: Arrange-Act-Assert
      Naming: MethodName_Scenario_ExpectedResult

      Przetestuj:
      - Happy path (poprawne dane)
      - Edge cases (null, empty, boundary values)
      - Error paths (not found, validation failure)

      Nie mockuj metod prywatnych.
      Nie testuj implementacji - testuj zachowanie.

Template do generowania testów

User: Oto klasa do przetestowania:

      [wklej kod klasy]

      Oto jej zależności (interfejsy):

      [wklej interfejsy]

      Wygeneruj testy:
      1. Happy path dla każdej publicznej metody
      2. Walidacja inputu (null, empty string, negative values)
      3. Obsługa błędów (not found, conflict, unauthorized)
      4. Edge cases specyficzne dla logiki biznesowej

Kluczowe zasady

Podaj framework i konwencje - „xUnit + FluentAssertions” nie „napisz testy”
Pokaż zależności - agent musi wiedzieć co mockować
Definiuj scenariusze - happy path, edge cases, error paths
Weryfikuj pokrycie - agent często pomija edge cases, dodaj je ręcznie

Testy E2E z agentem

User: Napisz testy E2E dla procesu składania zamówienia:

      1. Zaloguj się jako user@test.com
      2. Dodaj 2 produkty do koszyka
      3. Przejdź do checkout
      4. Wypełnij dane dostawy
      5. Potwierdź zamówienie
      6. Sprawdź czy pojawia się potwierdzenie z numerem zamówienia

      Framework: Playwright
      Wzorzec: Page Object Model

Rola 4: Debugger / Troubleshooter

Kiedy: Masz błąd, wyjątek, nieoczekiwane zachowanie - i nie wiesz dlaczego.

Relacja: Agent diagnozuje, Ty dostarczasz dowody.

Jak używać agenta do debugowania

User: Mam problem z tym kodem. Oto kontekst:

      BŁĄD:
      System.InvalidOperationException:
      Sequence contains more than one matching element

      STACK TRACE:
      [wklej stack trace]

      KOD KTÓRY POWODUJE BŁĄD:
      [wklej fragment kodu]

      CO POWINNO SIĘ STAĆ:
      Pobranie jednego zamówienia po ID

      CO SIĘ DZIEJE:
      Wyjątek przy 3 na 10 requestów

      CO JUŻ SPRAWDZIŁEM:
      - Dane w bazie wyglądają OK
      - Działa na danych testowych, psuje się na produkcyjnych

Struktura promptu diagnostycznego

BŁĄD: [dokładny error message + stack trace]
KOD:  [fragment kodu z kontekstem]
OCZEKIWANIE: [co powinno się stać]
RZECZYWISTOŚĆ: [co się dzieje]
KONTEKST: [kiedy, jak często, jakie dane]
PRÓBY: [co już próbowałeś]

Kluczowe zasady

Daj pełny stack trace - nie sam error message
Pokaż kod - nie opisuj go słowami
Opisz okoliczności - „psuje się przy dużych zbiorach danych” to cenna informacja
Powiedz co próbowałeś - agent nie będzie powtarzał Twoich kroków

Typowe scenariusze troubleshootingu

Scenariusz	Co dać agentowi
Wyjątek runtime	Stack trace + kod + dane wejściowe
Performance issue	Profiler output + zapytanie SQL + execution plan
Flaky test	Kod testu + logi z 3 runów (pass + fail)
Memory leak	Memory dump summary + podejrzany kod
Deployment failure	Pipeline log + konfiguracja + env variables

Łączenie ról w workflow

W praktyce w jednej sesji pracy agent zmienia role wielokrotnie. Najważniejsze to świadomie przełączać kontekst:

Sesja 1 (Koder):
  "Stwórz NotificationService..." → Agent pisze kod

Sesja 2 (Reviewer):
  "Przejrzyj NotificationService pod kątem..." → Agent recenzuje

Sesja 3 (Tester):
  "Napisz testy dla NotificationService..." → Agent testuje

Sesja 4 (Debugger):
  "Test X failuje z błędem Y, oto logi..." → Agent diagnozuje

Każda rola = nowy czat (patrz Pro Tips #1: Jedno zadanie = Jeden czat).

Podsumowanie

Rola	Agent robi	Ty robisz
Koder	Pisze kod według wzorców	Definiujesz scope, weryfikujesz
Reviewer	Znajduje problemy	Decydujesz co naprawić
Tester	Generuje testy	Weryfikujesz pokrycie i edge cases
Debugger	Diagnozuje przyczynę	Dostarczasz kontekst i dowody

Najlepsza strategia: rotacja ról z osobnymi sesjami. Agent-koder, potem agent-reviewer na ten sam kod. Dwa spojrzenia, dwa konteksty, mniej błędów w produkcji.