W poprzednich wpisach budowaliśmy infrastrukturę – instrukcje, skills, agenci, MCP, hooks, agentic workflows. Teraz skupiamy się na narzędziu które to wszystko spina w jeden autonomiczny przepływ pracy: Copilot Coding Agent. Nie mylić z "agent mode" w VS Code – to dwa różne produkty.

Coding Agent to asynchroniczny developer działający na GitHubie. Przypisujesz mu issue, wychodzisz na kawę, a gdy wracasz – masz gotowego draft PR z implementacją, testami i opisem zmian. Wszystko zalogowane krok po kroku w GitHub Actions. Ty tylko reviewujesz i kierujesz.

W tym wpisie pokazuję jak go uruchomić, jak pisać issues które dają dobre wyniki i – co najważniejsze – gdzie agent się myli i jak go prowadzić żeby nie robił głupot w PR-ach. Ta ostatnia sekcja to mój główny dodatek, oparty na doświadczeniu z produkcyjnymi projektami .NET.

Dokumentacja źródłowa: About GitHub Copilot Coding Agent – GitHub Docs. Praktyczny przewodnik: Coding Agent 101 – GitHub Blog.

Zanim cokolwiek, trzeba to rozróżnienie powiedzieć głośno i wyraźnie, bo dokumentacja i artykuły często je mieszają:

Zrozumienie kolejności kroków jest kluczem do skutecznego współdziałania z agentem. Wiedząc co robi w każdej fazie, wiesz kiedy warto interweniować i jak.

Coding Agent świetnie radzi sobie z zadaniami o małej do średniej złożoności i jasno zdefiniowanym wyniku. Gorzej z zadaniami które wymagają głębokiej znajomości domeny, subtelnych decyzji architektonicznych lub kreatywności. Poniższa tabela pomaga podjąć decyzję:

Jakość PR-a jest wprost proporcjonalna do jakości issue. Agent nie odgaduje intencji – czyta to co napisałeś. Trzy minuty więcej na opis issue to godzina mniej na poprawki w review.

Tytuł: Dodaj testy do OrderService

Opis:
Potrzebujemy więcej testów.
OrderService nie ma wystarczającego pokrycia.

Tytuł: Dodaj testy jednostkowe do OrderService

Opis:
## Co zrobić
Napisz testy jednostkowe dla klasy
`Application/Orders/OrderService.cs`.

## Stack testowy
- xUnit 2, FluentAssertions, NSubstitute
- Wzorzec AAA z komentarzami
- Plik testowy: `Tests/Application/Orders/
  OrderServiceTests.cs`

## Scenariusze do pokrycia
- CancelOrder: sukces, już anulowane, nie istnieje
- GetPendingOrders: lista, pusta lista
- UpdateStatus: prawidłowy status, nieprawidłowy status

## Przykład istniejącego testu
Zobacz: `Tests/Application/Products/
ProductServiceTests.cs`

## Czego NIE robić
- Nie pisz testów integracyjnych
- Nie modyfikuj kodu OrderService

Anatomia dobrego issue dla Coding Agenta

Optional prompt – niedoceniane pole

Gdy przypisujesz issue do Copilota, pojawia się pole Optional prompt. To jest miejsce na instrukcje które nie powinny być w opisie issue (bo są specyficzne dla tej konkretnej sesji agenta), a które chcesz przekazać bezpośrednio. Użyj go do:

Zacznij od przeczytania pliku ARCHITECTURE.md żeby zrozumieć
nasze konwencje. Użyj NSubstitute (nie Moq) – mamy je ustandaryzowane
od Q3 2025. Jeśli testy nie przejdą za pierwszym razem, debuguj
przez dotnet test --verbosity detailed zanim zmienisz implementację.

To jest sekcja której nie ma w dokumentacji – zebrałem ją z własnego doświadczenia i obserwacji jak Coding Agent zachowuje się na projektach .NET z Clean Architecture. Agent jest potężny, ale ma systematyczne błędy. Wiedząc o nich możesz im zapobiegać w opisie issue, albo wyłapywać je szybciej w review.

PR od agenta to nie kod kolegi – wymaga innego podejścia do review. Agent jest szybki i pewny siebie, ale nie rozumie kontekstu tak jak człowiek. Poniższy checklist pomaga wyłapać systematyczne błędy zanim trafią na main.

Checklist review dla PR-ów od Coding Agenta

• Opis PR opisuje dokładnie to co chciałem – nie ma rozbieżności z intencją issue
• Zakres zmian jest ograniczony do plików które powinny być zmienione
• Brak nowych zależności NuGet których nie zatwierdziłem
• Brak hardcoded connection strings, sekretów ani API keys
• Architektura respektowana – zależności idą we właściwym kierunku
• Testy testują zachowanie a nie wywołania wewnętrzne (brak nadużycia .Received())
• Nazwy klas i metod są zgodne z konwencjami i językiem domenowym projektu
• Nowe publiczne metody mają XML doc comments
• Kod jest asynchroniczny gdzie powinien być – brak .Result i .Wait()
• Zmiany są zrozumiałe dla mnie jako reviewera – jeśli nie, proszę agenta o wyjaśnienie

Jak iterować z agentem po review

Gdy widzisz problem w PR – nie poprawiaj ręcznie (chyba że to drobiazg). Skomentuj z @copilot i opisz co poprawić. Agent odpowie na komentarz, wprowadzi zmiany i zaktualizuje PR. Ten feedback loop jest jedną z najsilniejszych stron Coding Agenta.

@copilot W pliku OrderServiceTests.cs, linia 47:
test `CancelOrder_WhenOrderExists_ShouldChangeStatus` weryfikuje
wywołanie `_repository.Received(1).UpdateAsync()` zamiast sprawdzać
czy status zamówienia zmienił się na Cancelled.

Proszę przepisz asercję żeby testowała wynik operacji:
result.Status.Should().Be(OrderStatus.Cancelled)

Coding Agent działa lepiej gdy repozytorium jest dobrze przygotowane. Trzy pliki które warto mieć zanim zaczniesz delegować zadania:

1. Custom instructions (.github/copilot-instructions.md)

Najważniejszy plik. Agent czyta go przed każdym zadaniem. Powinien zawierać: stack technologiczny, konwencje kodowania, nazewnictwo, wzorce które stosujesz i czego nigdy nie robicie. Opisany szczegółowo w wpisie 4 i 5 tego cyklu.

2. Setup steps (.github/copilot-setup-steps.yml)

Plik który definiuje jak przygotować środowisko przed startem sesji agenta. Agent uruchamia go jako pierwsze zadanie. Dla projektu .NET:

# .github/copilot-setup-steps.yml
steps:
  - name: Setup .NET
    uses: actions/setup-dotnet@v4
    with:
      dotnet-version: '9.0.x'

  - name: Restore dependencies
    run: dotnet restore

  - name: Build solution
    run: dotnet build --no-restore

  - name: Run tests to establish baseline
    run: dotnet test --no-build --verbosity normal

Bez tego pliku agent startuje "na zimno" i może tracić czas na diagnostykę środowiska zamiast pisać kod. Z plikiem – od razu wie że build przechodzi i ma baseline testów.

3. Hooks (.github/hooks/)

Hooks z wpisu 9 działają też dla Coding Agenta. Quality gate agentStop sprawdza formatowanie i build po każdej sesji. Security gate preToolUse blokuje niebezpieczne operacje. To jest Twoja siatka bezpieczeństwa dla autonomicznego agenta.

Copilot Coding Agent to nie "zrób za mnie" – to "zrób w tle, a ja sprawdzę". Zmienia rolę developera z pisania kodu na definiowanie wymagań, review i kierowanie. Im lepiej opisujesz zadania i im lepiej przygotowane repozytorium, tym mniej poprawek w review.

• ✅ Agent mode ≠ Coding Agent: agent mode to synchroniczny asystent w IDE, Coding Agent to asynchroniczny developer na GitHubie. Dwa różne produkty, dwa różne zastosowania.
• ✅ Sześciofazowy cykl: przypisanie → analiza → draft PR → implementacja → review request → iteracja. Agent nie widzi komentarzy do issue dodanych po przypisaniu.
• ✅ Złota reguła zadań: deleguj to co junior developer zrobiłby w 30–60 minut przy dobrym opisie. Unikaj zadań wymagających głębokiej znajomości domeny, optymalizacji bez profilu i zmian w wielu repozytoriach.
• ✅ Siedem systematycznych błędów (mój dodatek): testy implementacji nie zachowania, naruszenia architektury przez najkrótszą drogę, niezatwierdzone zależności NuGet, zbyt szeroki scope, mieszanie języków, pętla przy failing tests, hardcoded secrets.
• ✅ Checklist review: dziesięć punktów które wyłapują systematyczne błędy agenta zanim trafią na main.
• ✅ Trzy pliki konfiguracyjne: custom instructions, copilot-setup-steps.yml i hooks – przygotuj je zanim zaczniesz delegować zadania.

W kolejnym wpisie: Instalacja i używanie Plugins – jak rozszerzać Copilota o zewnętrzne narzędzia i integracje przez oficjalny marketplace.