Jak zacząć pracę z agentem AI w projekcie .NET? Plan na 30 dni: Claude Code, CLAUDE.md, testy, legacy i pomiar

Otwierasz czat w przeglądarce, wklejasz kawałek kodu i kopiujesz odpowiedź do Visual Studio. Nie kompiluje się, bo AI nie ma pojęcia, że w projekcie używasz MediatR i własnego typu Result. Poprawiasz, wklejasz jeszcze raz, znowu poprawiasz. Po godzinie dochodzisz do wniosku: "no... AI czasem pomaga".

Jeśli to brzmi znajomo, nie jesteś wyjątkiem. Większość z nas utknęła dokładnie w tym miejscu. I to nie jest wina AI. Po prostu nikt nie ma planu, jak z tego wyjść - a bez planu każdy kolejny tydzień wygląda tak samo: trochę czatu, trochę kopiowania, dużo poprawiania i ogólne wrażenie, że "chyba jest szybciej".

W tym artykule dostajesz taki plan. 30 dni, 4 tygodnie, 1 cel na tydzień - od czatu w przeglądarce do agenta, który pracuje w Twoim repozytorium, a Ty decydujesz i sprawdzasz wynik. Możesz go zrobić sam, od poniedziałku, na zadaniach, które i tak masz w pracy. Na koniec dostaniesz arkusz, który po 30 dniach powie Ci czarno na białym, czy jesteś szybszy. I pokaże, gdzie te 3× naprawdę się pojawia, a gdzie nie - bo nie pojawia się wszędzie.

Przykłady konfiguracji (uprawnienia, CLAUDE.md, skille) pokazuję na Claude Code, bo tego narzędzia używam na co dzień. Sam plan przełożysz jednak na każdego agenta AI, który potrafi pracować w Twoim repozytorium.

Pętla kopiuj-wklej: dlaczego AI "czasem pomaga"

Zacznijmy od tego, jak wygląda praca na poziomie czatu. Pytasz w czacie. Kopiujesz odpowiedź. Wklejasz do Visual Studio. Błąd kompilacji. Wracasz do czatu - i tak w kółko. Zauważ, kto w tej pętli wykonuje najwięcej roboty. Ty. Jesteś kablem między AI a swoim kodem.

3 powody, dla których to się nie skaluje. Taki sposób pracy ma 3 wbudowane ograniczenia:

• AI widzi wycinek. Dostaje kawałek kodu, który wkleiłeś, ale nie zna Twojej architektury ani konwencji. Stąd kod, który "prawie" pasuje do projektu.

• Każdy prompt zaczynasz od zera. Kontekst przenosisz ręcznie, za każdym razem od nowa.

• Nic nie mierzysz. Masz wrażenie, że pomaga. Ale czy zyskałeś godzinę, czy ją straciłeś - nie wiesz.

3 poziomy pracy z AI. Żeby zobaczyć, dokąd zmierzamy, rozróżnijmy 3 poziomy:

1. Czat w przeglądarce. Pytasz, kopiujesz.
2. Podpowiedzi w IDE, np. Copilot, który dopowiada Ci kolejną linijkę.
3. Agent w repozytorium. Czyta cały projekt, zmienia pliki, odpala build i testy. Ty mówisz, co ma zrobić, i sprawdzasz wynik. Ja używam do tego Claude Code.

Ten plan to droga z poziomu 1 na poziom 3.

3 zasady planu i mapa 30 dni

Zanim wejdziemy w kolejne tygodnie, 3 zasady. Bez nich plan nie działa:

1. Jeden tydzień = jeden cel. Nie robisz wszystkiego naraz.
2. Mierzysz od pierwszego dnia. Bez liczb to są tylko wrażenia.
3. Ty decydujesz, AI wykonuje. Ty jesteś tech leadem, AI jest juniorem. Nigdy odwrotnie.

A tak wygląda cały plan:

• Tydzień 1: setup i bezpieczeństwo,
• Tydzień 2: jeden typ zadań w całości z AI i mierzenie czasu,
• Tydzień 3: testy i code review,
• Tydzień 4: legacy i pierwsza automatyzacja,
• Dni 29-30: wnioski z arkusza.

I ważne: robisz to na prawdziwych zadaniach, które i tak masz w pracy. Nie na projekcie demo i nie po godzinach.

Tydzień 1: setup, bezpieczeństwo, CLAUDE.md i pierwszy commit

Cel pierwszego tygodnia jest prosty: AI pracuje w Twoim repo, a Ty śpisz spokojnie.

Dzień 1-2: setup. Instalujesz narzędzie agentowe (np. Claude Code) i od razu otwierasz je na swoim projekcie. Nie na demo, nie na kolejnej aplikacji typu todo - na kodzie, z którym naprawdę pracujesz. Zanim AI cokolwiek ruszy, przygotuj grunt: nowy branch, czysty git status i sprawdzenie, że build i testy przechodzą przed zmianami AI:

git checkout -b ai-pierwszy-tydzien
git status
dotnet build
dotnet test

Po co? Żebyś miał punkt, do którego zawsze możesz wrócić. Jeśli coś pójdzie nie tak, wiesz na pewno, że problem nie siedział w projekcie od początku.

Bezpieczeństwo: 3 pytania. Zanim wpuścisz AI do firmowego kodu, odpowiedz sobie na 3 pytania:

• Czy firma na to pozwala? Jeśli nie wiesz, zapytaj przed startem. To 1 wiadomość do szefa, a oszczędza dużo nerwów.

• Gdzie są sekrety? Connection stringi i klucze nie powinny leżeć w repozytorium. Ich miejsce to user secrets albo zmienne środowiskowe.

• Co AI może uruchomić bez pytania? To ustawiasz wprost, zamiast liczyć na to, że agent "się domyśli".

Pozwól, pytaj, zabroń. Najprościej podzielić działania agenta na 3 grupy:

• Pozwól (bez pytania): dotnet build, dotnet test, czytanie kodu.
• Pytaj (za każdym razem): edycja plików, git commit, nowa paczka NuGet.
• Zabroń (zawsze): git push, migracje na bazie innej niż lokalna, pliki z sekretami.

W Claude Code ustawiasz to w pliku .claude/settings.json, w sekcji permissions, np. tak:

{
  "permissions": {
    "allow": [
      "Bash(dotnet build:*)",
      "Bash(dotnet test:*)"
    ],
    "ask": [
      "Edit",
      "Bash(git commit:*)",
      "Bash(dotnet add package:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Read(./.env)",
      "Read(./**/appsettings.Production.json)"
    ]
  }
}

Czytanie kodu agent ma dozwolone domyślnie, więc nie trzeba go dopisywać. Migracji na bazie innej niż lokalna nie opiszesz jedną regułą - najpewniejsza blokada to taka, w której agent w ogóle nie ma w zasięgu connection stringa do takiej bazy. I tu wracamy do pytania o sekrety.

Dzień 3-4: CLAUDE.md, czyli onboarding dla AI. Nowej osobie w zespole mówisz na start: tu jest stack, tak odpalasz testy, tak nazywamy rzeczy, tego nie ruszaj. Dokładnie to samo zapisujesz w jednym pliku w repozytorium - CLAUDE.md. Agent czyta go na starcie każdej sesji, więc kontekst przestajesz przenosić ręcznie (pamiętasz drugi powód z pętli kopiuj-wklej?).

Tak może wyglądać taki plik dla projektu .NET:

# Faktury API

## Stack
- .NET 10, Minimal API
- EF Core + SQL Server
- xUnit + NSubstitute

## Komendy
- dotnet build
- dotnet test

## Konwencje
- Vertical slices: Features/<Nazwa>/
- Walidacja: tylko FluentValidation
- Async + CancellationToken wszędzie
- Błędy biznesowe: Result<T>

## Nie rób
- Nie zmieniaj migracji już wypchniętych na main
- Nie dodawaj paczek NuGet bez pytania
- Nie ruszaj Legacy/Billing bez testów

Stack, komendy, konwencje (np. walidacja tylko przez FluentValidation, async wszędzie z CancellationToken) i sekcja "Nie rób". To właśnie ta ostatnia sekcja oszczędza najwięcej czasu, bo zatrzymuje AI, zanim zrobi coś, co potem musiałbyś znaleźć i odkręcić.

Ten sam błąd 2 razy = nowa linijka w CLAUDE.md. Jedna zasada, która zrobi z tego pliku złoto. Jeśli AI popełni ten sam błąd 2 razy, dopisujesz linijkę do CLAUDE.md. Nie poprawiasz w kółko tego samego w czacie - poprawiasz raz, w pliku. Po miesiącu ten plik zna Twój projekt lepiej niż niejedna nowa osoba w zespole.

Dzień 5: pierwszy commit. Weź coś małego: ostrzeżenie kompilatora, brakujący test, walidację w jednym DTO. I przejdź pełną ścieżkę, krok po kroku:

1. Prosisz AI o plan.
2. Czytasz go i akceptujesz.
3. AI wprowadza zmianę.
4. Czytasz diff linijka po linijce.
5. Build i testy.
6. Commit.

Chodzi o to, żeby raz przejść całą drogę na czymś, co nie może wybuchnąć.

Checkpoint tygodnia 1. Na koniec tygodnia sprawdź 4 rzeczy:

• agent działa na moim projekcie,
• sekrety są poza zasięgiem AI,
• CLAUDE.md jest w repo,
• pierwszy commit z AI przeszedł moje review.

Brakuje któregoś? Nie idź dalej. Dokończ.

Tydzień 2: jeden typ zadań w całości z AI

Tu zaczyna się prawdziwa zmiana. Przez cały tydzień robisz jeden typ zadań w całości z AI i mierzysz czas. Cel tygodnia: zmierzyć, a nie zgadywać.

Dlaczego jeden typ, a nie wszystko po trochu? Bo wtedy porównujesz jabłka z jabłkami. Po 5 takich samych zadaniach, np. 5 endpointach, wiesz, gdzie AI się myli i jak to wyłapać. Po 5 różnych zadaniach wiesz tylko tyle, że było różnie.

Co wybrać na start. Coś powtarzalnego:

• nowy endpoint CRUD (encja, DTO, walidacja, endpoint),
• testy jednostkowe dla serwisu,
• migracja EF Core,
• zapytania i raporty.

Czego nie brać na start? Architektury, autoryzacji, wydajności i legacy. Do legacy dojdziemy w tygodniu 4.

Brief w 4 częściach. Każde zadanie zaczynasz od briefu. 4 części: kontekst, cel, ograniczenia i Definition of Done. Czyli dokładnie to, co dałbyś juniorowi.

Porównaj. Słaby brief: "Dodaj endpoint do faktur." Dostaniesz coś. Pewnie nie to, co chciałeś. A teraz dobry brief:

"Kontekst: Features/Invoices. Wzoruj się na Customers.
Cel: GET /invoices/{id} zwraca InvoiceDto.
Ograniczenia: bez nowych paczek. Result<T> zamiast wyjątków. CancellationToken.
Definition of Done: 404, gdy faktury nie ma. 403, gdy jest cudza. Testy zielone, build bez ostrzeżeń."

Napisanie takiego briefu zajmuje 2 minuty. Oszczędza pół godziny poprawek.

Proces na każde zadanie. Każde zadanie z tego tygodnia przechodzi przez te same 5 kroków:

1. Estymacja bez AI. Ile by Ci to zajęło bez AI? Zapisujesz przed startem, nie po.
2. Plan od AI, który Ty akceptujesz.
3. Małe kroki, commit po każdym.
4. Review i poprawki.
5. Stop zegara.

Największa pułapka: "AI zrobiło to w 5 minut". Nie. AI wygenerowało kod w 5 minut. Potem było 15 minut review i 25 minut poprawek. Prawdziwy czas to 45 minut. Dlatego liczysz czas do merge, nie do pierwszej odpowiedzi. Inaczej oszukujesz sam siebie.

Checkpoint tygodnia 2:

• minimum 5 zadań jednego typu,
• każde z estymacją i prawdziwym czasem do merge,
• wiem, gdzie AI myli się najczęściej,
• mam szablon briefu dla tego typu zadań.

Ten szablon zostaje z Tobą na lata.

Tydzień 3: testy i code review z AI

Cel: szybciej, ale bez nowych bugów. Bo szybciej z bugami to tak naprawdę wolniej.

Test, który zawsze przechodzi. Zacznijmy od problemu. AI bardzo chętnie pisze testy, które zawsze przechodzą. Przykład z pliku InvoiceServiceTests.cs:

[Fact]
public async Task GetInvoice_ReturnsInvoice()
{
    /* Arrange */
    _repo.GetAsync(42).Returns(_invoice);

    /* Act */
    var result = await _sut.GetAsync(42);

    /* Assert */
    Assert.NotNull(result);
}

Mock zwraca fakturę, a test sprawdza tylko, że wynik nie jest nullem. I tyle. Taki test przejdzie, nawet jeśli metoda zwróci fakturę z zerową kwotą, dla złego klienta i ze złym statusem. Coverage rośnie. Pewność nie.

Najpierw CO, potem JAK. Rozwiązanie: odwracasz kolejność.

1. Ty wypisujesz przypadki: happy path, brzegi, błędy, uprawnienia.
2. AI pisze kod testów.
3. Ty sprawdzasz, czy każdy test weryfikuje zachowanie, a nie tylko to, że coś się wykonało.

Ty decydujesz, co testujemy. AI pisze, jak.

Zepsuj kod celowo. Prosty trik, który w kilka sekund łapie słabe testy: odwróć warunek albo usuń linijkę i odpal testy. Nic nie poczerwieniało? Ten test jest do kosza. Albo do poprawki. To nic innego jak ręczna wersja testów mutacyjnych - jeśli spodoba Ci się ten sposób myślenia, w .NET możesz go zautomatyzować narzędziem Stryker.NET.

AI jako pierwszy reviewer. Druga część tygodnia to code review. Zanim otworzysz pull request, dajesz AI diff i każesz mu go sprawdzić według checklisty. Dla .NET na start:

• blokowanie async: .Result, .Wait(), async void,
• N+1 w EF Core i zapytania w pętli,
• brak CancellationToken,
• puste catch, które połyka wyjątki,
• endpoint bez autoryzacji,
• dane wrażliwe w logach.

AI robi to szybko i nie męczy się po piątym pliku.

Nie rozumiesz linijki - nie merge'ujesz. Review od AI to jednak nie jest Twoje review. AI łapie wzorce. Ty łapiesz sens biznesowy: czy ten kod w ogóle robi to, czego chce biznes. Zasada jest jedna: nie rozumiesz linijki, nie merge'ujesz.

Checkpoint tygodnia 3:

• testy piszę z listy przypadków,
• każdy nowy test przeszedł "test zepsucia",
• każdy PR przeszedł review AI i moje,
• liczę bugi po merge.

Po co liczyć bugi? Zobaczysz za chwilę, przy arkuszu.

Tydzień 4: legacy i pierwsza automatyzacja

Cel ostatniego tygodnia: wyjść poza demo i przestać robić w kółko to samo.

Legacy w 3 krokach. Każde demo AI to świeży projekt. A Ty masz serwis na 500 linii, którego nikt nie ruszał od 2 lat. Tu działają 3 kroki:

1. Mapa zależności. AI czyta, niczego nie zmienia.
2. Testy charakteryzacyjne. Zamrażasz to, jak kod działa dziś. Nawet jeśli działa źle.
3. Małe kroki. 1 zmiana = 1 commit = zielone testy.

Pierwszy prompt do legacy. Tak może wyglądać pierwsze polecenie dla agenta:

"Przeczytaj OrderService.cs i wszystko, z czego korzysta. Niczego nie zmieniaj.
Wypisz:
1. Kto wywołuje ten serwis.
2. Z jakich zależności korzysta.
3. Efekty uboczne: baza, maile, cache.
4. Które metody są najbardziej ryzykowne i dlaczego."

Najważniejsze słowa to "Niczego nie zmieniaj". Najpierw chcesz wiedzieć, kto woła ten serwis (np. OrdersController i InvoiceJob), z czego korzysta i jakie ma efekty uboczne (DbContext, EmailSender, cache). I które metody są najbardziej ryzykowne. Dopiero z taką mapą planujesz zmiany.

Czego nie oddajesz AI w legacy:

• decyzji "to bug czy ktoś kiedyś zrobił to celowo?",
• zmian w wielu miejscach naraz,
• logiki pieniędzy i uprawnień, dopóki nie masz testów.

Pierwsza automatyzacja. Druga połowa tygodnia. Zadaj sobie pytanie: co robię co tydzień ręcznie? Na przykład:

• nowy endpoint według moich konwencji → własny skill,
• review przed PR według checklisty → skill z checklistą,
• testy po każdej zmianie → hook, który sam odpala dotnet test.

Zasada: automatyzujesz dopiero to, co zrobiłeś ręcznie przynajmniej 3 razy. Wtedy wiesz, co automatyzujesz.

Przykład skilla. Prosty skill w Claude Code to jeden plik: nazwa, opis i kroki. Tak wygląda plik .claude/skills/nowy-endpoint/SKILL.md:

---
name: nowy-endpoint
description: Nowy endpoint wg konwencji
---

1. Wzór: Features/Customers.
2. Utwórz: Request, Validator, Handler, Endpoint.
3. Dodaj testy integracyjne.
4. Uruchom dotnet build i test.
5. Pokaż diff. Nie commituj.

Piszesz go raz, tak jak instrukcję dla juniora. Tylko że ten ją zawsze przeczyta :) Potem każdy nowy endpoint zaczynasz od jednej komendy: /nowy-endpoint Invoices.

Checkpoint tygodnia 4:

• mam mapę zależności dla 1 modułu legacy,
• mam testy charakteryzacyjne przed pierwszą zmianą,
• zrobiłem min. 1 refaktor małymi krokami,
• mam 1 automatyzację, której naprawdę używam.

Arkusz, który mówi prawdę: estymacja kontra rzeczywisty czas

Obiecałem arkusz - oto on. To serce całego planu. Bez niego po 30 dniach masz tylko wrażenie.

8 kolumn. Wystarczy zwykły arkusz kalkulacyjny z 8 kolumnami:

• Dzień planu,
• Zadanie,
• Typ zadania (CRUD, testy, debug, legacy...),
• Estymacja bez AI - zapisana przed startem,
• Czas z AI - prawdziwy, liczony do merge,
• Mnożnik,
• Bugi po merge,
• Notatka - co poszło nie tak.

Załóż go jeszcze dziś, zanim zaczniesz tydzień 1.

Tak to wygląda po kilku tygodniach. Poniżej przykładowe dane. Twoje będą inne - i właśnie o to chodzi:

Endpoint GET: estymacja 4 godziny, z AI 1 godzina 20 minut - mnożnik 3. Testy do serwisu: 3 godziny kontra 1 - znowu 3. Bug w rabatach: 2 godziny kontra 1 - mnożnik 2. A pierwszy krok refaktoru legacy? 1,2. I 1 bug po merge.

Jak czytać arkusz. Mnożnik = estymacja ÷ czas do merge. Do tego 3 zasady:

• patrzysz na średnią dla typu zadania, nie na ogólną,
• jeśli po merge wyszedł bug, doliczasz czas jego naprawy do tego zadania - wtedy widać prawdę,
• szybciej z bugami = wolniej. Po prostu płacisz później.

3× nie jest na wszystko. I tu jest odpowiedź, którą obiecałem na początku. Średnie mnożniki dla poszczególnych typów zadań z przykładowego arkusza wyglądają tak:

• zapytania: 3,6×,
• CRUD: 3,2×,
• testy: 3,0×,
• debugowanie: 2,0×,
• legacy: 1,2× (w tym 1 bug po merge).

Na powtarzalnych zadaniach, takich jak CRUD, testy czy raporty, 3× i więcej jest realne. Na debugowaniu i legacy na starcie zwykle mniej, bo tam więcej myślisz Ty. I to jest najcenniejsza informacja z całego miesiąca: wiesz, gdzie AI daje Ci najwięcej, i tam kierujesz pracę. A te liczby możesz położyć na stole, kiedy rozmawiasz z szefem.

4 błędy, przez które plan umiera

Na koniec 4 błędy, przez które ten plan najczęściej się wykłada:

• Legacy w tygodniu 1. Zaczynasz od najtrudniejszego kodu w projekcie, efekty są słabe i się zniechęcasz. Legacy ma swoje miejsce w tygodniu 4, kiedy masz już CLAUDE.md, briefy i nawyk czytania diffów.

• Nowe narzędzie co tydzień. Zmieniasz narzędzie co tydzień, więc zawsze jesteś na starcie: znowu konfiguracja, znowu nauka, jak z nim pracować, i znowu brak porównywalnych danych w arkuszu.

• "Nie mierzę, bo wiem, że jest szybciej". Bez arkusza zostaje Ci wrażenie. A po 30 dniach chcesz mieć liczby, nie wrażenie.

• Oddajesz AI decyzje, a nie wykonanie. Wracamy do zasady 3: Ty jesteś tech leadem, AI jest juniorem.

Ściąga: 30 dni w 1 tabeli

Całość w jednym miejscu - warto ją sobie zapisać albo zrobić zrzut ekranu:

Podsumowanie

Z poziomu "AI czasem pomaga" nie wychodzi się przypadkiem. Wychodzi się planem:

• Przestań być kablem między czatem a kodem - agent pracuje w Twoim repo, Ty decydujesz i sprawdzasz wynik.
• Tydzień 1: setup, uprawnienia, CLAUDE.md i pierwszy bezpieczny commit.
• Tydzień 2: 1 typ zadań, brief w 4 częściach, czas liczony do merge.
• Tydzień 3: testy z listy przypadków, test zepsucia, review AI + Twoje.
• Tydzień 4: legacy małymi krokami i pierwsza automatyzacja.
• Arkusz od dnia 1: 3× jest realne na powtarzalnych zadaniach, ale nie na wszystkim - i właśnie ta wiedza jest najcenniejsza.

Ten plan możesz zrobić sam. Naprawdę. Wszystko, czego potrzebujesz, żeby zacząć w poniedziałek, masz w tym artykule.

Jeśli jednak chcesz przejść tę drogę szybciej - z gotowymi projektami, mentorem, który odpowie na Twoje pytania, i grupą ludzi, którzy robią to samo - zapraszam Cię do Szkoły 3x Dev. Ten plan to skrót ostatniego modułu. W kursie masz całe "jak": krok po kroku, na prawdziwym kodzie .NET. I masz 14 dni gwarancji: jeśli nie widzisz efektów, oddaję pieniądze.

Zapisy otwieram cyklicznie, więc wejdź na stronę i zostaw maila na liście oczekujących: modestprogrammer.pl/szkola-3x-dev.

A jeśli robisz to sam, zacznij od tygodnia 1. W poniedziałek. Trzymam kciuki.