Czego się uczyć jako programista .NET? 5 umiejętności na 2028 i plan na 30 dni

Wyobraź sobie taksówkarza, który chwali się, że zna miasto na pamięć. Fajna umiejętność... tylko że GPS robi to samo - szybciej i za darmo. W 2028 roku programista .NET, który potrafi tylko pisać kod, będzie w bardzo podobnej sytuacji. Kod powstaje dziś szybciej i taniej niż kiedykolwiek, a za 2 lata ta różnica będzie jeszcze większa.

Spokojnie, to nie jest kolejny tekst w stylu "AI zabierze Ci pracę". Jest dokładnie odwrotnie: praca będzie. Ale będzie wyglądać inaczej, a firmy będą płacić za inne rzeczy niż jeszcze kilka lat temu. To nie są wróżby z fusów, tylko trendy, które już się dzieją. Na co dzień buduję komercyjne aplikacje w C#/.NET, prowadzę szkolenia, z których skorzystało blisko 1000 programistów, i rozmawiam z tysiącami osób z mojej społeczności - widzę, o co pytają rekruterzy i co ląduje w wymaganiach ogłoszeń. Tutaj składam to w całość.

W tym artykule dostaniesz 5 umiejętności, za które firmy będą naprawdę płacić za 2 lata: sterowanie agentami AI, AI wbudowane w Twoje aplikacje, architekturę systemów, cloud-native z observability oraz wydajność i bezpieczeństwo. Przy każdej znajdziesz 3 rzeczy: co konkretnie umieć, dlaczego akurat to i jaki zrobić pierwszy krok jeszcze w tym tygodniu. Na koniec dostaniesz gotowy plan na 30 dni i listę rzeczy, których nie musisz się uczyć - bo w tej branży umiejętność odpuszczania jest równie ważna jak nauka.

Co się właściwie zmieniło? Kod stał się tani

Zanim przejdziemy do listy, jedna rzecz musi wybrzmieć. Szefowie Microsoftu i Google'a otwarcie mówią, że dużą część nowego kodu w ich firmach pisze już AI. Satya Nadella szacował w 2025 roku, że to 20-30% kodu w repozytoriach Microsoftu, a Sundar Pichai mówił o ponad 30% nowego kodu w Google'u. Firmy nie zdradzają dokładnie, jak to liczą, więc traktuj te liczby jako rząd wielkości. Ale ten rząd wielkości mówi sam za siebie: mniej więcej 1/3 kodu. Nie w 2028. Już dziś.

Co z tego wynika? Samo klepanie kodu przestaje być umiejętnością premium, bo kod stał się tani. Ale ktoś nadal musi wiedzieć, jaki kod napisać, sprawdzić, czy jest dobry, i dowieźć z niego działający system. Wartość przesuwa się z pisania linijek na dostarczanie systemów. I właśnie za to firmy będą płacić.

To dokładnie ta sama historia, co z IDE, Stack Overflow czy chmurą: narzędzie zmienia zawód, a nie go kasuje. Programiści nie zniknęli, kiedy pojawił się IntelliSense, ani kiedy serwerownie przeniosły się do chmury. Zmieniło się to, co robią na co dzień. Wygrywają ci, którzy przesiadają się pierwsi.

Poniższe 5 umiejętności układa się w logiczną ścieżkę: od pracy z AI, przez architekturę, po rzeczy, które odróżniają seniora od wiecznego mida.

Umiejętność #1: sterowanie agentami AI

Pierwsza umiejętność to sterowanie agentami AI. I od razu uwaga: to nie jest "umiem używać Copilota do podpowiadania składni". To potrafi dziś każdy.

W 2028 roku standardem będzie praca, w której Ty opisujesz zadanie, agent (GitHub Copilot, Claude Code czy cokolwiek będzie wtedy modne) pisze kod, a Ty decydujesz, co z nim dalej. Przestajesz pisać każdą linijkę, a zaczynasz zarządzać. Różnica między programistą, który dowozi 3 razy więcej, a takim, który wrzuca bugi na produkcję, to nie model AI. To umiejętność zlecania i weryfikowania.

Co konkretnie ćwiczyć?

Rozbijanie zadań. Agent świetnie radzi sobie z małymi, dobrze opisanymi zadaniami, a gubi się w poleceniu "zrób mi moduł płatności". Zanim cokolwiek zlecisz, podziel pracę na kawałki, które łatwo zrobić i łatwo sprawdzić: osobno model danych, osobno walidacja, osobno endpoint, osobno testy. Każdy kawałek to osobne zlecenie i osobny review.

Pisanie specyfikacji. Dobre zlecenie dla agenta ma 3 elementy: kontekst (gdzie jesteśmy w kodzie i jakie są zasady projektu), kryteria akceptacji (kiedy zadanie jest skończone) i przykłady wejścia i wyjścia. Brzmi jak praca analityka? Bo trochę jest. Przykładowe zlecenie może wyglądać tak:

"Kontekst: ASP.NET Core Web API, EF Core, logika w warstwie serwisów (folder Services), walidacja przez FluentValidation. Zadanie: dodaj endpoint POST /api/zamowienia/{id}/anuluj. Kryteria akceptacji: anulować można tylko zamówienie w statusie Nowe albo Opłacone; dla pozostałych statusów zwróć 409 z komunikatem; anulowanie zapisuje datę anulowania. Przykłady: zamówienie Nowe → 204, zamówienie Wysłane → 409. Dopisz testy jednostkowe serwisu dla obu przypadków. Nie zmieniaj istniejących migracji."

Takie zlecenie agent zrobi dobrze za pierwszym razem zdecydowanie częściej niż jednozdaniowe "dodaj anulowanie zamówień". A Ty od razu wiesz, po czym poznać, że zadanie jest skończone.

Bezlitosny code review. Kod od AI wygląda pewnie siebie nawet wtedy, gdy jest błędny. Kompiluje się, ma ładne nazwy i komentarze - a potrafi wywołać metodę, która nie istnieje, albo pominąć przypadek brzegowy, o którym nikt mu nie powiedział. Musisz wyłapywać halucynacje i pominięte edge case'y. Czytaj kod od AI tak, jak czytasz pull request od nowej osoby w zespole: życzliwie, ale bez taryfy ulgowej.

Testy jako siatka bezpieczeństwa. Skoro AI pisze kod, to testy są Twoją siatką bezpieczeństwa. Dobre testy to przy okazji najlepsza specyfikacja dla agenta: możesz poprosić o implementację, która ma przejść konkretne testy, i od razu wiesz, czy zadanie jest zrobione.

Pierwszy krok. Jest banalnie prosty: przez najbliższe 7 dni każde zadanie zrób z agentem. Każdą linijkę przeczytaj. I załóż sobie plik ai-fails.md, w którym zapiszesz każdy błąd AI, który wyłapiesz. Wystarczy krótki wpis:

• jakie było zadanie,
• co AI zrobiło źle,
• jak udało się to wyłapać (review, test, błąd w runtime),
• jak można było lepiej sformułować zlecenie.

Po tygodniu będziesz dokładnie wiedzieć, gdzie AI można ufać, a gdzie nie. Tego nie da się przeczytać w żadnym artykule - to trzeba wyrobić.

Umiejętność #2: AI w Twoich aplikacjach

Druga umiejętność to druga strona medalu. Jedno to używać AI do pisania kodu. Drugie - wbudować AI w aplikację, którą tworzysz: chatbota odpowiadającego na pytania z dokumentów firmy, inteligentne wyszukiwanie, automatyczne przetwarzanie i kategoryzowanie zgłoszeń.

Każda firma tego chce, bo każdy produkt prędzej czy później dostaje funkcje AI. A ktoś musi je napisać w .NET. Programistów .NET, którzy potrafią to dowieźć porządnie - czyli z kontrolą kosztów i jakości - jest wciąż garstka. To luka, w którą możesz wejść.

Dobra wiadomość: ekosystem .NET jest tu naprawdę mocny.

Microsoft.Extensions.AI. To standardowe abstrakcje do pracy z modelami językowymi. Myśl o tym jak o ILoggerze, tylko dla AI: Twój kod zależy od interfejsu IChatClient, a konkretnego dostawcę modelu (OpenAI, Azure OpenAI, model lokalny) wybierasz w jednym miejscu, przy rejestracji:

/* Program.cs - dostawcę modelu wybierasz w jednym miejscu (tu: OpenAI) */
builder.Services.AddChatClient(
    new OpenAIClient(builder.Configuration["OpenAI:ApiKey"])
        .GetChatClient(builder.Configuration["OpenAI:Model"])
        .AsIChatClient());

a w serwisie korzystasz już tylko z interfejsu:

public class AsystentZgloszen(IChatClient chatClient)
{
    public async Task<string> KategoriaAsync(string tresc)
    {
        var odpowiedz = await chatClient.GetResponseAsync(
            $"Przypisz zgłoszenie do jednej kategorii: Faktury, Reklamacje, Inne. Zwróć tylko nazwę kategorii.\n\n{tresc}");

        return odpowiedz.Text;
    }
}

Piszesz raz, a dostawcę podmieniasz bez przepisywania aplikacji. Jeśli jutro firma zdecyduje, że przechodzicie z OpenAI na Azure OpenAI albo na model lokalny, zmieniasz rejestrację, a AsystentZgloszen zostaje bez zmian.

Semantic Kernel i Agent Framework. Piętro wyżej są biblioteki do budowania agentów: function calling (model sam decyduje, którą Twoją metodę wywołać), orkiestracja wielu kroków, pamięć. Semantic Kernel był tu przez długi czas podstawowym wyborem, a w kwietniu 2026 Microsoft wydał jego następcę - Microsoft Agent Framework 1.0, w którym rozwijane są teraz nowe funkcje. Do nowego projektu sięgnij raczej po Agent Framework, ale znajomość Semantic Kernel też się przyda, bo stoi na nim mnóstwo istniejących projektów.

RAG, czyli embeddingi i baza wektorowa. Absolutna podstawa. RAG (Retrieval-Augmented Generation) to wzorzec "czatu z własnymi danymi": dokumenty dzielisz na fragmenty, każdy fragment zamieniasz na embedding (wektor liczb opisujący jego znaczenie) i zapisujesz w bazie wektorowej. Kiedy użytkownik zadaje pytanie, wyszukujesz fragmenty najbliższe mu znaczeniowo i dokładasz je do promptu, a model odpowiada na ich podstawie, zamiast zgadywać. Szczerze? Z tego, co widzę, ok. 80% biznesowych zastosowań AI to właśnie to.

Koszty i jakość. Czwarta rzecz, o której wszyscy zapominają. Każde wywołanie modelu kosztuje - płacisz za tokeny na wejściu i na wyjściu, a w RAG-u do każdego pytania dokładasz jeszcze fragmenty dokumentów. Umiejętność policzenia, ile kosztuje dana funkcja przy realnym ruchu, i zmierzenia, czy odpowiedzi w ogóle są dobre (ewaluacja na zestawie testowych pytań), odróżnia zabawkę od produktu.

Pierwszy krok. Zbuduj mini-RAG: konsolówkę w .NET, która odpowiada na pytania z Twoich własnych PDF-ów. Plan jest prosty:

1. Wczytaj kilka PDF-ów i potnij tekst na fragmenty.
2. Wygeneruj embeddingi (w Microsoft.Extensions.AI służy do tego IEmbeddingGenerator).
3. Zapisz je w bazie wektorowej - na start wystarczy nawet lista w pamięci.
4. Dla pytania znajdź najbliższe fragmenty i przekaż je modelowi razem z pytaniem.

To jeden weekend roboty, a na rozmowie rekrutacyjnej robi więcej niż 3 certyfikaty.

Umiejętność #3: architektura systemów

Trzecia umiejętność to architektura. I tu jest ciekawy paradoks: skoro AI pisze kod coraz szybciej, to w projektach przybywa kodu szybciej niż kiedykolwiek. A razem z kodem przybywa bałaganu.

Ktoś musi decydować o granicach, przepływie danych, o tym, co jest modułem, a co osobnym serwisem. AI Ci w tym pomoże - podsunie warianty, wypisze plusy i minusy - ale decyzji za Ciebie nie podejmie, bo nie zna Twojego biznesu, budżetu ani zespołu. Dlatego to najlepiej płatna i najtrudniejsza do zautomatyzowania umiejętność na tej liście.

Od czego zacząć? Nie od wykuwania wzorców projektowych na pamięć.

Modular monolith jako domyślny wybór. Jedna aplikacja, jeden deployment, ale podzielona na wyraźnie oddzielone moduły (np. Zamówienia, Płatności, Magazyn), z których każdy ma własną logikę i własne dane. Mikroserwisy dopiero wtedy, gdy masz twardy powód - np. moduł, który musi się skalować zupełnie inaczej niż reszta, albo osobny zespół z osobnym cyklem wdrożeń - a nie dlatego, że Netflix tak ma. Dobrze podzielony monolit łatwo później rozciąć na serwisy. Źle podzielone mikroserwisy to rozproszony monolit, czyli najgorsze z obu światów.

Granice i kontrakty. Który moduł co wystawia na zewnątrz i kto z kim rozmawia. Moduł Zamówień nie powinien grzebać w tabelach Płatności - powinien poprosić o to przez publiczny interfejs albo zareagować na zdarzenie. Jasne kontrakty to zresztą świetne środowisko dla agentów AI: mały, odizolowany moduł z dobrze opisanym API zleca się i weryfikuje dużo łatwiej niż kod, w którym wszystko zależy od wszystkiego.

Diagramy C4 i ADR-y. 2 proste techniki, które robią z Ciebie innego programistę. C4 pozwala narysować system na kilku poziomach szczegółowości: kontekst (system i jego otoczenie - użytkownicy, systemy zewnętrzne), kontenery (aplikacje, bazy, kolejki), komponenty i kod. ADR (Architecture Decision Record) to krótka notatka "dlaczego podjęliśmy taką decyzję": kontekst, decyzja, rozważane alternatywy i konsekwencje. Pół strony tekstu w repozytorium, które za 2 lata, kiedy nikt nie będzie pamiętał, czemu coś zrobiono tak, a nie inaczej, okaże się bezcenne. Przykładowy ADR może wyglądać tak:

"ADR-007: Kolejka zamiast synchronicznej wysyłki e-maili. Kontekst: wysyłka maila po złożeniu zamówienia wydłuża czas odpowiedzi API, a awaria serwera SMTP blokuje składanie zamówień. Decyzja: zamówienie publikuje zdarzenie na kolejkę, osobny worker wysyła maile. Rozważane alternatywy: wysyłka w tle w tym samym procesie (odrzucona - przy restarcie aplikacji tracimy maile). Konsekwencje: dochodzi kolejka do utrzymania, mail może przyjść z kilkusekundowym opóźnieniem."

Rozmowa o trade-offach. Koszt kontra złożoność kontra czas. Nie ma rozwiązań "najlepszych", są tylko rozwiązania dopasowane do sytuacji - a umiejętność wytłumaczenia tego biznesowi jest warta więcej niż znajomość kolejnego wzorca. Na rozmowach rekrutacyjnych na mida i seniora pytania projektowe już dziś wypierają pytania o składnię.

Pierwszy krok. Weź swój obecny projekt i narysuj go jako diagram C4 na poziomie 1 i 2. Godzina roboty. Gwarantuję, że znajdziesz przynajmniej jedno miejsce, w którym granice modułów przeciekają. Typowe objawy: jeden moduł czyta bezpośrednio tabele innego, encje są współdzielone między modułami "bo tak było szybciej", projekty mają cykliczne zależności. Każde takie miejsce to gotowy temat na refaktoring - i na historię do CV.

Umiejętność #4: cloud-native i observability

Czwarta umiejętność. Czasy, w których programista kończył robotę po zmergowaniu pull requesta, właśnie się kończą. "U mnie działa" umarło - teraz odpowiadasz też za produkcję.

W 2028 roku baseline będzie taki: Twoja aplikacja żyje w kontenerze, w chmurze, a Ty umiesz odpowiedzieć na pytanie "dlaczego produkcja zwolniła o 13:00?" - bez wołania DevOpsa na ratunek. Składają się na to 4 klocki.

Docker bez magii. Co to jest obraz, co to jest rejestr, jak zbudować obraz swojej aplikacji i odpalić cały zestaw lokalnie przez docker compose. Nie musisz być ekspertem od Kubernetesa, ale musisz rozumieć, w czym uruchamia się Twój kod.

Aspire. Klocek bardzo .NET-owy, do niedawna znany jako ".NET Aspire". Daje lokalną orkiestrację całego systemu (API, frontend, baza, cache - wszystko startuje jednym poleceniem), dashboard z logami i trace'ami oraz service discovery, czyli serwisy znajdują się nawzajem bez wpisywania adresów na sztywno. Microsoft mocno w to inwestuje i naprawdę to widać. Cały system opisujesz w C#, w projekcie AppHost:

/* AppHost/Program.cs - cały system opisany w C# */
var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");                 /* kontener Redis startuje sam */

var api = builder.AddProject<Projects.Sklep_Api>("api")
                 .WithReference(cache);

builder.AddProject<Projects.Sklep_Web>("web")
       .WithReference(api);                            /* web znajdzie api przez service discovery */

builder.Build().Run();

a w każdym serwisie wystarczy jedna linijka, która dokłada wspólną konfigurację z projektu ServiceDefaults:

/* Program.cs w każdym serwisie */
builder.AddServiceDefaults();   /* OpenTelemetry, health checki, service discovery */

OpenTelemetry. Logi, metryki i trace'y jako standard w każdej Twojej aplikacji. Logi mówią, co się stało, metryki - jak system zachowuje się w czasie (liczba żądań, czasy odpowiedzi, zużycie pamięci), a trace'y pokazują drogę pojedynczego requestu przez wszystkie serwisy, bazę i zewnętrzne API. Konfigurujesz raz, a potem przez lata wiesz, co się dzieje na produkcji, zamiast zgadywać. A ponieważ to otwarty standard, te same dane obejrzysz lokalnie w dashboardzie Aspire, a na produkcji np. w Application Insights.

Jedna chmura, ale porządnie. Nie musisz znać 3 chmur po trochu. Lepiej znać jedną naprawdę dobrze - dla .NET najnaturalniej Azure. Deploy, zarządzanie sekretami i - bardzo niedoceniane - rozumienie rachunku za chmurę. Programista, który potrafi powiedzieć, dlaczego faktura wzrosła w tym miesiącu i jak ją obniżyć, jest dla firmy dużo cenniejszy niż ktoś, kto tylko "wrzuca na Azure'a".

Pierwszy krok. Dodaj Aspire do istniejącego projektu i pierwszy raz w życiu zobacz własne trace'y na dashboardzie. Serio - moment, w którym widzisz, jak request przechodzi przez Twój system (ile trwało zapytanie do bazy, ile wywołanie zewnętrznego API, gdzie wszystko stanęło), zmienia sposób myślenia o kodzie.

Umiejętność #5: wydajność i bezpieczeństwo

Piąta umiejętność to mój faworyt, bo mówi się o niej najmniej.

Pomyśl: modele AI uczą się na przeciętnym kodzie z internetu, więc generują kod... przeciętny. Średni z definicji. Zwykle działa. Ale często jest wolny, a czasem dziurawy. Programista, który umie zmierzyć, wskazać palcem "to jest wolne, bo..." i naprawić, będzie na wagę złota. Zwłaszcza że wolny kod w chmurze to nie problem estetyczny, tylko konkretna pozycja na fakturze.

Mierz, nie zgaduj. To zasada numer 1. Do mierzenia kawałków kodu służy BenchmarkDotNet, a do zaglądania w działającą aplikację dotnet-trace (co dokładnie robi aplikacja i gdzie traci czas) i dotnet-counters (CPU, pamięć, GC i liczba żądań na żywo). Prosty benchmark wygląda tak:

[MemoryDiagnoser]
public class SumaZamowienBenchmark
{
    private List<Zamowienie> _zamowienia = null!;

    [GlobalSetup]
    public void Setup() => _zamowienia = DaneTestowe.Zamowienia(10_000);

    [Benchmark(Baseline = true)]
    public decimal Linq() => _zamowienia.Where(z => z.Oplacone).Sum(z => z.Kwota);

    [Benchmark]
    public decimal Petla()
    {
        decimal suma = 0;
        foreach (var z in _zamowienia)
            if (z.Oplacone) suma += z.Kwota;
        return suma;
    }
}

/* Program.cs - uruchamiaj w konfiguracji Release */
BenchmarkRunner.Run<SumaZamowienBenchmark>();

Atrybut [MemoryDiagnoser] pokaże Ci nie tylko czas, ale też ile pamięci alokuje każdy wariant. Benchmarki zawsze uruchamiaj w konfiguracji Release - wyniki z Debuga nic nie znaczą.

Pamięć. Alokacje, Span<T> i z grubsza zasady działania GC. Bez doktoratu, ale na tyle, żeby rozumieć, czemu coś mieli pamięć: dlaczego sklejanie stringów w pętli jest drogie, dlaczego wczytanie całej tabeli do listy tylko po to, żeby ją potem przefiltrować, to proszenie się o kłopoty, i kiedy GC zaczyna realnie spowalniać aplikację.

Native AOT. Kompilacja aplikacji do kodu natywnego: szybki start i mniejsze kontenery. Świetne tam, gdzie to ma sens - np. w funkcjach serverless, narzędziach CLI czy małych serwisach. Nie wszędzie się da (refleksja i część bibliotek wciąż bywają problemem), więc to narzędzie do świadomego użycia, a nie domyślny przełącznik.

Bezpieczeństwo. OWASP Top 10 jako absolutne minimum - SQL injection, błędy kontroli dostępu czy źle skonfigurowane uwierzytelnianie to wciąż klasyka, a kod z AI potrafi je powielać. Sekrety poza repozytorium, zawsze: lokalnie User Secrets, na produkcji np. Azure Key Vault. I audyt paczek, bo Twoja aplikacja to też setki cudzych bibliotek, a każda z nich może mieć znaną podatność.

Pierwszy krok. A właściwie 2. Pierwszy: zbenchmarkuj jeden endpoint w swoim projekcie (albo metodę, która za nim stoi) i znajdź jeden problem - zapytanie N+1 albo zbędne alokacje. Prosty sposób na N+1: włącz w EF Core logowanie zapytań SQL i policz, ile zapytań leci do bazy przy jednym żądaniu. Jeśli ich liczba rośnie razem z liczbą rekordów na liście, masz winowajcę. Drugi: odpal w katalogu projektu:

dotnet list package --vulnerable --include-transitive

10 sekund. Polecenie sprawdzi Twoje paczki NuGet (także te dociągnięte jako zależności) pod kątem znanych podatności. A potrafi uratować projekt - i Twoją reputację.

Bonus: czego NIE musisz gonić

To, czego sobie odpuścić, jest równie ważne jak to, czego się uczyć. Oto moja prywatna lista:

• Każdy nowy model AI z osobna. Modele zmieniają się co kwartał, a abstrakcje i wzorce zostają. Ucz się wzorców (RAG, function calling, ewaluacja), a nie nazw modeli. Przy abstrakcjach takich jak Microsoft.Extensions.AI zmiana modelu to i tak kwestia konfiguracji.

• Każdy framework JavaScript. Chyba że świadomie idziesz w stronę frontendu. Jako backendowiec .NET potrzebujesz podstaw, a nie znajomości każdej nowości.

• Kolekcjonowanie certyfikatów. Jeden porządny projekt w portfolio bije 5 PDF-ów na LinkedInie.

• Panika, że "C# umiera". Umiera od 20 lat i z każdym rokiem ma się lepiej: nowa wersja .NET co roku, wersja LTS co 2 lata i ogromny rynek enterprise, który nigdzie się nie wybiera. Spokojna głowa.

Plan na pierwsze 30 dni

5 umiejętności naraz to dużo. Dlatego składamy je w plan na 30 dni, w którym co tydzień robisz jedną konkretną rzecz:

• Tydzień 1: AI workflow. Każde zadanie z agentem, każda linijka przeczytana, dziennik błędów AI w ai-fails.md.

• Tydzień 2: mini-RAG w .NET. Konsolówka na Microsoft.Extensions.AI, która odpowiada na pytania z Twoich PDF-ów.

• Tydzień 3: Aspire + OpenTelemetry. Dodajesz je do swojego projektu i oglądasz pierwsze trace'y.

• Tydzień 4: benchmark i audyt bezpieczeństwa. Jeden endpoint zmierzony i poprawiony, paczki sprawdzone pod kątem podatności.

Po 30 dniach masz 4 konkretne, pokazywalne rzeczy - do portfolio, do CV i na rozmowę rekrutacyjną. A architektura? Ta rośnie przy okazji każdego z tych kroków: projektując RAG, dokładając Aspire i szukając wąskich gardeł, cały czas podejmujesz decyzje o granicach i trade-offach. I ta umiejętność zostaje z Tobą na lata.

Ściąga: 5 umiejętności w pigułce

Wszystko z tego artykułu w jednej tabeli:

Podsumowanie

Zawód programisty .NET się zmienia, ale nie znika. Kod stał się tani, więc firmy płacą za to, co wokół kodu: za decyzje, weryfikację i dowiezienie działającego systemu. W skrócie:

• Sterowanie AI - zlecasz i weryfikujesz.
• AI w aplikacjach - RAG i agenci w .NET.
• Architektura - granice i trade-offy.
• Cloud-native - kontenery i telemetria.
• Fundamenty - wydajność i bezpieczeństwo.

I najważniejsze zdanie tego artykułu: nie musisz umieć wszystkiego od jutra. Wybierz jedną umiejętność i zrób pierwszy krok w tym tygodniu. Za 2 lata podziękujesz sobie za tę decyzję.

Jeśli chcesz zacząć od umiejętności numer 1, mam dla Ciebie skrót. Przygotowałem darmowy PDF: 25 promptów AI dla programistów C#/.NET - gotowe prompty do Claude Code i Copilota: refaktoryzacja, testy, debugowanie, code review i legacy. Kopiujesz, wklejasz i widzisz różnicę w 5 minut.

Odbierzesz go tutaj: modestprogrammer.pl/25-promptow. Zostawiasz maila i PDF przychodzi od razu. Przy okazji dołączasz do społeczności ponad 10 000 programistów .NET: raz w tygodniu jeden konkretny mail z najważniejszymi newsami ze świata .NET i AI - bez szumu, bez lania wody, do przeczytania przy kawie. Do tego rabaty na moje kursy, których nie znajdziesz nigdzie indziej. Zero spamu - wypisujesz się jednym kliknięciem.

Powodzenia - i do zobaczenia w 2028 :)