Czy AI zastąpi programistów .NET? Co potrafi Claude Code, gdzie się wykłada i kto powinien się bać

Przez ostatni rok Claude Code napisał za mnie tysiące linii kodu C#. Migracje, testy, całe API. I powiem szczerze: część rzeczy, za które jeszcze 2 lata temu firmy płaciły juniorom 8 tysięcy zł na rękę, dziś robi się jednym promptem. Nic dziwnego, że coraz więcej programistów zadaje sobie pytanie: czy AI zastąpi programistów i czy za kilka lat w ogóle będzie dla nas praca?

Krótka odpowiedź brzmi: nie, .NET developer to nie jest zawód na wymarciu. Ale nie jest też tak, że nic się nie zmienia - są osoby, które powinny zacząć się martwić, i w tym artykule powiem wprost, kto to jest. Programuję w .NET od ponad 15 lat, a od roku praktycznie codziennie pracuję z Claude Code, czyli agentem AI, który działa w terminalu, sam edytuje pliki, uruchamia testy i robi commity. Dlatego zamiast kolejnego "AI zmieni wszystko" albo "AI to bańka" dostaniesz konkrety z prawdziwych projektów.

Zobaczysz, co agent AI naprawdę potrafi w projekcie ASP.NET Core na 3 konkretnych zadaniach, gdzie regularnie się wykłada (z prawdziwym przykładem z EF Core, który na produkcji wciągnął do pamięci 400 MB danych) oraz które stanowiska są realnie zagrożone, a które wręcz zyskają. Na koniec dostaniesz konkretny plan: 5 rzeczy, dzięki którym AI będzie pracować dla Ciebie, a nie zamiast Ciebie.

Słowo o narzędziach: wszystkie przykłady pochodzą z mojej pracy z Claude Code, ale wnioski dotyczą każdego agenta AI do kodu, np. GitHub Copilota w trybie agenta. Konkretne narzędzia zmieniają się co kilka miesięcy - zasady, o których tu piszę, zmieniają się dużo wolniej.

Co się zmieniło przez rok: od autocomplete do agenta AI

Najważniejsza zmiana ostatniego roku to nie "mądrzejszy model". To zmiana sposobu pracy.

Rok temu: AI jako lepszy autocomplete. Copilot podpowiadał linijkę, czasem całą metodę. Ty akceptowałeś te podpowiedzi linijka po linijce i to Ty składałeś z nich rozwiązanie. AI było szybszą klawiaturą, ale cała praca koncepcyjna i "sklejanie" kawałków zostawały po Twojej stronie.

Dziś: AI jako agent. Agent dostaje zadanie, sam czyta projekt, edytuje wiele plików, uruchamia dotnet test i poprawia błędy, które sam wywołał. Ty nie akceptujesz już pojedynczych linijek - opisujesz zadanie i oceniasz wynik. Agent pracuje trochę jak junior, który nigdy się nie męczy i nie scrolluje TikToka.

Co Claude Code zrobił za mnie w ciągu roku. To nie jest teoria, tylko lista z moich prawdziwych projektów:

• migracja projektu z .NET 6 na .NET 8 - 2 godziny zamiast 2 dni,
• ok. 70% testów jednostkowych w nowych projektach,
• CRUD-owe endpointy i DTO - praktycznie w całości,
• refaktoryzacje typu "rozbij ten serwis na mniejsze",
• dokumentacja, README i komentarze XML.

Wspólny mianownik. Zwróć uwagę, co łączy wszystkie te zadania. Każde z nich jest powtarzalne i dobrze zdefiniowane. Migracja ma jasny cel: projekt ma się kompilować i działać na nowej wersji. CRUD to schemat powtarzany setki razy. Testy jednostkowe mają wyraźne kryterium sukcesu. To klucz do zrozumienia, gdzie AI jest mocne, a gdzie nie, więc zapisz sobie tę regułę:

AI miażdży zadania, które są powtarzalne, dobrze opisane i łatwe do zweryfikowania.

Ostatni warunek jest najważniejszy. AI jest świetne tam, gdzie łatwo sprawdzić, czy wynik jest dobry. Testy są zielone? Działa. Kompiluje się? Ok. Agent może wtedy sam sprawdzać swoją pracę i poprawiać się w pętli, aż osiągnie cel. Im trudniej zweryfikować wynik, tym większa część tej pracy spada na Ciebie.

Claude Code w akcji: 3 zadania w prawdziwym projekcie .NET

Teoria teorią, ale najlepiej widać to na konkretnym kodzie. Do testu wziąłem prosty, ale realistyczny Web API "OrderService": ASP.NET Core, EF Core, kilka encji (Order, Customer, Product), parę kontrolerów, ok. 30 plików. Nie hello world, ale też nie korporacyjny moloch. Agent dostał 3 zadania - 2 typowe dla codziennej pracy i 1 podchwytliwe.

Zadanie 1: nowy feature jednym promptem. Pierwszy prompt wyglądał tak:

"Dodaj endpoint POST /api/orders/{id}/cancel.
Zasady: można anulować tylko zamówienie w statusie Pending lub Confirmed, anulowanie ustawia status Cancelled i zapisuje CancelledAt.
Dodaj testy jednostkowe dla wszystkich przypadków.
Trzymaj się konwencji z istniejących kontrolerów."

Zwróć uwagę, że to nie jest jednozdaniowe "dodaj anulowanie zamówień". Prompt zawiera regułę biznesową (które statusy można anulować), oczekiwany efekt (status i data anulowania), wymaganie testów i wskazówkę co do stylu. Im precyzyjniej opiszesz zadanie, tym mniej agent musi zgadywać.

Co dzieje się dalej? Najpierw agent czyta projekt: sprawdza, jak wyglądają istniejące kontrolery, jak nazwane są testy, jakiej wersji EF Core używa projekt. Dopiero potem edytuje pliki. Na koniec sam odpala dotnet test. Jeśli któryś test jest czerwony, agent czyta komunikat błędu, poprawia kod i uruchamia testy ponownie, aż wszystko będzie zielone.

Ręcznie zajęłoby mi to 30-40 minut, a tu moja rola sprowadziła się do napisania promptu i przejrzenia wyniku. Efekt: kod, który normalnie zaakceptowałbym na code review. Prawie. Za chwilę wyjaśnię, czemu "prawie".

Zadanie 2: testy do istniejącego kodu. Drugie zadanie to robota, której większość programistów szczerze nie znosi - testy do istniejącej logiki liczenia zamówień:

"Wygeneruj testy jednostkowe dla OrderCalculationService. Pokryj rabaty, zaokrąglenia i przypadki brzegowe."

Agent przeanalizował serwis i wygenerował zestaw testów razem z przypadkami brzegowymi, o których sam bym nie pomyślał - na przykład zaokrąglanie przy rabacie 33%.

Dlaczego akurat 33% to dobry przypadek brzegowy? Bo przy takim rabacie łatwo trafić na wynik z połówką grosza, a wtedy wszystko zależy od sposobu zaokrąglania. W .NET Math.Round dla typu decimal domyślnie stosuje tzw. zaokrąglanie bankierskie (do najbliższej parzystej cyfry), a nie "szkolne":

var rabat = 12.50m * 0.33m;                           /* 4.1250 */

Math.Round(rabat, 2);                                 /* 4.12 - domyślnie MidpointRounding.ToEven */
Math.Round(rabat, 2, MidpointRounding.AwayFromZero);  /* 4.13 - zaokrąglenie "szkolne" */

Różnica to 1 grosz, ale pomnóż go przez tysiące zamówień i masz rozjazd między systemem a fakturami. Takie testy pisze się bardzo nudno, więc w praktyce często nikt ich nie pisze. Agent nie ma z tym problemu.

Zadanie 3: tu zaczyna się problem. Trzecie zadanie było celowo podchwytliwe - niejasne, dokładnie takie, jakie często przychodzą od biznesu:

"Zoptymalizuj wydajność pobierania zamówień, użytkownicy skarżą się, że lista długo się ładuje."

I zobacz, co zrobiło AI. Rzuciło się na endpoint z listą zamówień, który na pierwszy rzut oka wygląda "ciężko", bo ładuje zamówienia razem z pozycjami i produktami (Include/ThenInclude). Dorzuciło AsNoTracking, dodało indeks, włączyło cache. Wygląda mądrze, prawda?

Tylko że ten endpoint był w porządku: eager loading, żadnego N+1. Prawdziwy problem siedział w zupełnie innym miejscu - w endpoincie GET /api/customers/summary, który miał klasyczny problem N+1. Agent o nim nie wiedział, bo taki problem widać dopiero na produkcyjnych danych, a nie w kodzie, który "wygląda na wolny".

Dla przypomnienia: N+1 to sytuacja, w której zamiast 1 zapytania do bazy wykonujesz 1 zapytanie o listę, a potem N kolejnych - po jednym dla każdego elementu. W EF Core wygląda to zwykle mniej więcej tak:

/* 1 zapytanie o listę klientów... */
var customers = await _context.Customers.ToListAsync();

var summary = new List<CustomerSummaryDto>();
foreach (var customer in customers)
{
    /* ...i osobne zapytanie dla KAŻDEGO klienta */
    var ordersCount = await _context.Orders.CountAsync(o => o.CustomerId == customer.Id);
    summary.Add(new CustomerSummaryDto(customer.Id, customer.Name, ordersCount));
}

Przy kilku klientach w lokalnej bazie nikt tego nie zauważy. Przy tysiącach klientów na produkcji to tysiące zapytań przy każdym wejściu na stronę. Poprawka to zwykle 1 zapytanie z projekcją, w którym liczenie robi baza danych:

var summary = await _context.Customers
    .Select(c => new CustomerSummaryDto(c.Id, c.Name, c.Orders.Count()))
    .ToListAsync();

Puenta tego zadania jest bolesna: AI zoptymalizowało coś, co nie było problemem. Kod się kompiluje, testy są zielone, a użytkownik dalej czeka. Agent zrobił dokładnie to, o co go poproszono - tyle że nikt mu nie powiedział, co naprawdę jest wolne. A on nie zapytał.

Gdzie AI wymięka: 4 miejsca, w których agent regularnie się wykłada

To, co stało się w zadaniu 3, nie jest wyjątkiem. Po roku pracy z agentem widzę 4 obszary, w których AI regularnie się wykłada:

1. Niejasne wymagania - "zrób, żeby było szybciej".
2. Kontekst biznesowy - czemu ten kod wygląda tak, a nie inaczej.
3. Duże, stare codebase'y - legacy z 2012 roku z WebFormsami.
4. Konsekwencje decyzji - architektura, bezpieczeństwo, koszty.

Niejasne wymagania. Ten punkt widziałeś przed chwilą. AI nie zada Ci pytania "a co dokładnie jest wolne i dla kogo?", które dobry programista zadałby w pierwszej minucie. Zamiast tego po prostu coś wyprodukuje - i to coś będzie wyglądać przekonująco.

Kontekst biznesowy. AI nie wie, że ten dziwny if w kodzie płatności istnieje, bo 3 lata temu była przez to awaria na milion złotych. Usunie go z uśmiechem, bo "kod będzie czystszy". Takiej wiedzy zwykle nie ma w repozytorium - jest w głowach ludzi i w historii zgłoszeń. Agent jej nie zobaczy, dopóki ktoś mu jej nie poda.

Duże, stare codebase'y. Legacy z 2012 roku z WebFormsami to dla agenta trudny teren. Taki kod często nie ma testów, więc agent nie ma jak sprawdzić, czy czegoś nie zepsuł - a pamiętasz regułę "łatwe do zweryfikowania"? Do tego dochodzą nieudokumentowane zależności i konwencje, które zmieniały się przez lata. Im większy i starszy projekt, tym trudniej agentowi zrozumieć, co z czym się łączy.

Konsekwencje decyzji. AI napisze Ci kod, ale nie poniesie konsekwencji decyzji architektonicznych, luk bezpieczeństwa ani rachunku za chmurę. Wybierze rozwiązanie, które działa teraz i przechodzi testy. Czy będzie się skalować za rok, czy nie otwiera dziury w bezpieczeństwie i ile będzie kosztować - za odpowiedzi na te pytania odpowiadasz Ty.

Prawdziwy przykład z mojego projektu. Żeby nie było, że to teoria - oto kod, który AI zaproponowało mi jako "czystszy":

/* AI zaproponowało "czystszy" kod: */
var orders = await _context.Orders
    .Include(o => o.Items)
        .ThenInclude(i => i.Product)
    .ToListAsync();

/* Wygląda dobrze. Na dev działa. */
/* Na produkcji: 400 MB danych w pamięci. Boom. */

Na pierwszy rzut oka to podręcznikowy EF Core: eager loading, żadnego N+1, czytelnie. Problem? Na produkcji ta tabela ma 2 miliony rekordów, a ten kod ładuje je wszystkie do pamięci - razem z pozycjami i produktami. AI tego nie wie. Ty wiesz.

Programista, który zna dane, napisałby to raczej tak: z paginacją i projekcją tylko tych kolumn, które są potrzebne na liście.

/* Tylko 1 strona wyników i tylko potrzebne kolumny */
var orders = await _context.Orders
    .OrderByDescending(o => o.CreatedAt)
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .Select(o => new OrderListItemDto(o.Id, o.CreatedAt, o.Status, o.Items.Count()))
    .ToListAsync();

Przy projekcji przez Select Include nie jest potrzebne, a zwracanych DTO EF Core i tak nie śledzi, więc nawet AsNoTracking nie jest tu konieczne. Nie ma w tym żadnej magii, to podstawy pracy z EF Core. Ale żeby po nie sięgnąć, trzeba wiedzieć, ile danych jest w tabeli i jak ten endpoint jest używany. I dokładnie za tę wiedzę firmy będą Ci płacić.

Nowy podział pracy. I to jest sedno całej dyskusji o AI. Praca programisty się nie kończy - ona się przesuwa:

• AI robi: pisanie kodu, testy, boilerplate, refaktoryzacje, dokumentację.
• Ty robisz: decyzje, weryfikację, kontekst biznesowy, architekturę - i bierzesz odpowiedzialność.

Krótko: AI pisze. Ty odpowiadasz za to, co trafi na produkcję.

Mniej klepania, więcej myślenia i weryfikowania. Pisanie kodu przestaje być wąskim gardłem. Wąskim gardłem staje się wiedza, co napisać, i ocena, czy to, co powstało, jest poprawne i bezpieczne.

Kto realnie powinien się bać, a kto zyska na AI

Zagrożeni. Powiem to wprost, bo mało kto mówi o tym głośno. Najbardziej zagrożone są 3 grupy:

• "Klepacze ticketów". Biorą task z Jiry, klepią, oddają. Zero pytań.

• Programiści, którzy znają tylko składnię. Bez zrozumienia systemu, w którym pracują.

• Osoby, które odmawiają używania AI. W stylu "za moich czasów...".

Jeśli Twoja praca polega na braniu dobrze opisanego ticketa i przekuwaniu go w kod bez zadawania pytań, to robisz dokładnie to, w czym AI jest najlepsze. Przypomnij sobie regułę z początku: powtarzalne, dobrze opisane, łatwe do zweryfikowania. Dobrze opisany ticket spełnia ją idealnie. To nie jest hejt, tylko ostrzeżenie od kolegi z branży.

Bezpieczni (a nawet zyskają). Po drugiej stronie są ludzie, dla których AI to dźwignia:

• ci, którzy rozumieją biznes i domenę,
• ci, którzy umieją robić code review i wyłapywać problemy,
• ci, którzy znają system end-to-end: od bazy po deploy,
• ci, którzy używają AI jako dźwigni i dzięki temu robią 3 razy więcej.

Mój znajomy, senior .NET, mówi wprost: "czuję się, jakbym miał 3 juniorów na pełen etat, za darmo". On nie boi się AI. On dzięki AI dowozi tyle, co kiedyś cały zespół.

Zauważ, że każda z tych cech to dokładnie to, czego brakuje agentowi z poprzedniej sekcji: kontekst biznesowy, weryfikacja, rozumienie całego systemu i konsekwencji decyzji.

A co z juniorami? Najczęstsze pytanie, jakie dostaję: "czy w ogóle warto teraz wchodzić w programowanie?". Szczera odpowiedź: wejście do branży jest trudniejsze - to prawda. Proste zadania, na których juniorzy się uczyli, dziś robi AI.

Ale jednocześnie nigdy w historii nie było łatwiej się uczyć. Masz nauczyciela dostępnego 24/7, który wytłumaczy Ci każdą linijkę kodu - cierpliwie i tyle razy, ile potrzebujesz. Junior z AI uczy się 3 razy szybciej niż junior bez AI. A firmy nie potrzebują już "rąk do klepania", tylko ludzi, którzy szybko zaczną myśleć jak mid.

Poprzeczka poszła w górę, ale drabina też jest lepsza.

Plan działania: 5 rzeczy, które warto robić już teraz

Dość diagnozy, czas na konkrety. Oto 5 rzeczy, które sprawią, że będziesz po właściwej stronie tej zmiany:

1. Pracuj z agentem codziennie. Nie z chatem, tylko z agentem (np. Claude Code albo GitHub Copilot w trybie agenta). "Czasem zapytać ChatGPT" to za mało. Pracuj z agentem na prawdziwym kodzie, codziennie, bo to umiejętność jak każda inna - trzeba ją wytrenować. Minimum na start: testy i refaktoryzacje.

2. Trenuj code review. Czytanie cudzego kodu to teraz Twoja supermoc, bo kod AI = cudzy kod. Skoro AI pisze, Twoją robotą jest weryfikować, a tego nie nauczysz się bez praktyki.

3. Idź w głąb .NET. Wydajność, async, EF Core pod maską, garbage collector. Tam AI błądzi, a Ty możesz błyszczeć. Im głębiej rozumiesz platformę, tym łatwiej wyłapujesz bzdury AI - jak ten Include, który na produkcji wciągnął do pamięci 400 MB.

4. Ucz się domeny. Poznaj biznes, dla którego pracujesz, bo tego AI nie zna. Programista, który rozumie biznes, jest nie do zastąpienia.

5. Naucz się pisać specyfikacje. Dobry prompt to dobra specka. Kto umie precyzyjnie opisać problem, ten rządzi agentami. Porównaj prompt z zadania 1 (konkretne statusy, efekt, testy, konwencje) z promptem z zadania 3 ("zoptymalizuj, bo wolno") - różnica w wynikach mówi sama za siebie. W świecie agentów wygrywa ten, kto najlepiej definiuje problem.

Jedno zdanie do zapamiętania. Jeśli masz zapamiętać z tego artykułu tylko jedno zdanie, niech to będzie to:

AI nie zabierze Ci pracy. Zabierze ją programista, który używa AI lepiej niż Ty.

Ściąga: co oddać AI, a czego pilnować samemu

Na koniec cała reguła "powtarzalne + dobrze opisane + łatwe do zweryfikowania" w jednej tabeli:

Podsumowanie

Czy AI zastąpi programistów .NET? Klepanie kodu - tak, to już się dzieje. Zawód programisty - nie. Zmienia się natomiast jego istota: z "piszę kod" na "odpowiadam za system". Zbierzmy najważniejsze wnioski:

• AI to dziś agent, nie autocomplete: sam czyta projekt, edytuje pliki, uruchamia testy i poprawia błędy.

• AI miażdży zadania powtarzalne, dobrze opisane i łatwe do zweryfikowania: CRUD-y, testy, migracje, dokumentację.

• AI wykłada się na niejasnych wymaganiach, kontekście biznesowym, dużym legacy i konsekwencjach decyzji.

• Zagrożeni są klepacze ticketów, znawcy samej składni i ci, którzy odmawiają AI. Zyskają ci, którzy rozumieją biznes, robią dobre code review i znają system end-to-end.

• Plan: agent codziennie, code review, głębokie .NET, znajomość domeny i precyzyjne specyfikacje.

Masz 2 wyjścia: albo będziesz tą zmianą zaskoczony, albo będziesz na nią gotowy.

Jeśli chcesz być gotowy, mam coś na dobry początek. Przygotowałem darmowy PDF: 25 promptów AI dla programistów C#/.NET do Claude Code i Copilota. Refaktoryzacja, testy jednostkowe, debugowanie, code review i legacy. Każdy prompt przetestowałem na prawdziwym kodzie, więc wystarczy skopiować, wkleić i zobaczyć różnicę. To najprostszy sposób, żeby od razu ruszyć z punktem 1 i 5 z planu: codzienną pracą z agentem i pisaniem precyzyjnych poleceń.

Odbierzesz go tutaj: modestprogrammer.pl/25-promptow. Zostawiasz maila i PDF przychodzi od razu. Przy okazji dołączasz do mojej społeczności .NET - jest nas tam już ponad 10 000 programistów. Raz w tygodniu wysyłam maila z najważniejszymi newsami ze świata .NET i AI, takimi, które realnie wpływają na Twoją pracę, bez spamu i lania wody. Członkowie społeczności jako pierwsi dostają też rabaty na moje kursy, zanim ogłoszę je publicznie. Dołączenie zajmuje 10 sekund, a wypisać się możesz jednym kliknięciem - choć z tego, co widzę, mało kto się wypisuje :)