Jak zarabiać więcej dzięki AI w programowaniu? Ile oddajesz firmie, podwyżka, freelance i pułapka bugów

Endpoint, który kiedyś zajmował mi pół dnia, dziś robię w 45 minut. Kontroler, walidacja, serwis, EF Core, testy - kiedyś pół dnia, teraz 45 minut. Jeśli pracujesz z Claude Code, Copilotem albo innym narzędziem AI, pewnie znasz to uczucie. Tylko zadaj sobie jedno pytanie: gdzie idą te zaoszczędzone godziny? U większości programistów odpowiedź jest prosta: prosto do firmy. Za darmo.

Policzyłem to. Jeśli AI oszczędza Ci 1 godzinę dziennie, a Twoja godzina jest warta 100 zł, to oddajesz ponad 25 000 zł rocznie. I nie widzisz z tego ani złotówki. Samo ogarnianie AI jeszcze nic Ci nie daje. Liczy się to, co robisz z czasem, który dzięki niemu odzyskujesz.

W tym artykule policzymy, ile dokładnie oddajesz (prosty wzór i kalkulator), zobaczysz, co się dzieje, kiedy nic z tym nie robisz, i poznasz 2 drogi, żeby te pieniądze odzyskać: wyniki w firmie (podwyżka albo awans) oraz czas po etacie (freelance albo własny produkt). Na koniec omówię 1 pułapkę, przez którą możesz stracić wszystko, co AI Ci dało. Po drodze podpowiem też, jak pokazać swoje liczby szefowi, żeby rozmowa nie skończyła się na: "super, to weź jeszcze 5 ticketów".

Wszystkie kwoty poniżej to przykład na okrągłych liczbach: stawka 100 zł za godzinę i 1 godzina oszczędności dziennie. Twoje liczby będą inne - i właśnie o to chodzi, żeby je policzyć, a nie zgadywać.

Pół dnia → 45 minut: gdzie idą zaoszczędzone godziny?

Zacznijmy od konkretu, czyli od mojego endpointu.

Kiedyś: ok. 4 godziny. Kontroler, walidacja, serwis, zapytanie w EF Core, testy. Standardowa robota, którą każdy .NET-owiec zna na pamięć.

Dziś: 45 minut. AI pisze strukturę, a ja sprawdzam logikę.

Różnica: 3 godziny 15 minut. Na jednym zadaniu. A takich zadań mam kilka w tygodniu.

I tu pojawia się pytanie, od którego zależy cała reszta: gdzie idą te godziny? Są 3 możliwości:

• Do firmy. Dostajesz więcej ticketów, a wszystko inne zostaje po staremu.

• Do Ciebie. Zamieniasz je na podwyżkę, awans albo własne zlecenia.

• Nigdzie, czyli w bugi. Jesteś szybszy, ale przepalasz zaoszczędzony czas na poprawianie błędów.

Przejdziemy przez wszystkie 3. Ale najpierw policzmy, o jakie pieniądze w ogóle chodzi.

Ile oddajesz firmie za darmo? Prosty wzór i kalkulator

Wzór. Potrzebujesz tylko 1 działania:

Twoja stawka × zaoszczędzone godziny = ile oddajesz za darmo

Wynik to kwota, którą co miesiąc oddajesz firmie. Zwykle nawet o tym nie wiedząc.

Ile warta jest Twoja godzina? To zależy od formy zatrudnienia:

• Etat. Weź pensję brutto i podziel przez 168. Mniej więcej tyle godzin pracujesz w miesiącu (ok. 21 dni × 8 godzin).

• B2B. Masz stawkę godzinową albo dzielisz fakturę przez przepracowane godziny.

To wersja ostrożna. Firmę Twoja godzina kosztuje więcej, bo dochodzą składki, sprzęt i cała reszta. Czyli realna wartość tego, co oddajesz, jest jeszcze wyższa.

Kalkulator: miesiąc. Weźmy przykład. Stawka 100 zł za godzinę. AI oszczędza Ci tylko 1 godzinę dziennie - celowo biorę mało. Miesiąc ma ok. 21 dni roboczych:

100 zł/h × 1 h dziennie × 21 dni = 2 100 zł miesięcznie

Kalkulator: rok. Teraz razy 12 miesięcy:

2 100 zł × 12 miesięcy = 25 200 zł rocznie

A jeśli oszczędzasz 2 godziny dziennie - a przy dobrym workflow to wcale nie jest dużo - wychodzi już 50 400 zł rocznie. Ponad 50 tysięcy złotych.

Te godziny już istnieją. Zwróć uwagę, że to nie są wymyślone pieniądze ani obietnica na przyszłość. Te godziny już istnieją. Już je oszczędzasz. Pytanie tylko: kto na nich zarabia?

Nie zgaduj. Zmierz. I tu ważna uwaga. Większość z nas ma wrażenie, że AI oszczędza dużo czasu, ale mało kto to faktycznie liczy. Zrób prostą tabelkę. Przy każdym zadaniu zapisz 2 liczby: ile byś to kiedyś estymował i ile zajęło naprawdę. Przykład z 3 zadaniami:

9 godzin estymacji, 2 godziny 35 minut w praktyce, czyli ponad 6 godzin różnicy na 3 zadaniach. Tydzień takiego notowania i masz pierwszą twardą liczbę. Bez niej nie masz o czym rozmawiać. Ani ze sobą, ani z szefem.

Scenariusz domyślny: co się dzieje, kiedy nic z tym nie robisz

Zwykły wtorek. Task estymowany do 13:30 masz gotowy o 10:15. Co robisz? O 10:20 bierzesz kolejny ticket z boardu. Normalna, uczciwa reakcja - przecież nie będziesz siedzieć bezczynnie. W piątek okazuje się, że zamknąłeś 2 razy więcej niż zwykle.

Wypłata: bez zmian. A Twoja wypłata? Bez zmian. Firma dostała 2 razy więcej pracy za te same pieniądze.

Nowa norma. I tu jest najgorsza część. Po 2-3 sprintach Twoje nowe tempo przestaje być wyjątkowe:

• zespół zaczyna estymować pod Twoje tempo,
• to, co było Twoją przewagą, staje się oczekiwanym minimum,
• nikt już nie pamięta, że kiedyś to trwało pół dnia. Łącznie z Tobą.

Wariant B: cichy bufor. Jest też drugi wariant, trochę wstydliwy. Masz gotowe o 10:15, oddajesz o 13:30, a w międzyczasie... no wiesz. Każdy chociaż raz tak zrobił. Tylko zobacz, co z tego masz:

• trochę wolnego czasu - i to jedyny plus,
• zero pieniędzy,
• zero historii, którą możesz komuś pokazać,
• przewagę, która zniknie sama, gdy za rok cały zespół będzie pracował z AI.

Zasada: zysk z AI domyślnie trafia do firmy. To nie jest żaden spisek. Tak po prostu działa etat: płacą Ci za czas, nie za wynik. Jeśli chcesz, żeby część tego zysku trafiła do Ciebie, musisz coś z nim świadomie zrobić. Masz 2 drogi.

Droga #1: zamień godziny na wyniki, a wyniki na podwyżkę albo awans

Pierwsza droga to zamiana zaoszczędzonych godzin na wyniki w firmie, a wyników - na podwyżkę albo awans. Składa się z 3 kroków, w tej kolejności:

1. Zmierz.
2. Pokaż.
3. Porozmawiaj.

Większość ludzi zaczyna od kroku 3 i dziwi się, że nie działa. Idzie do szefa z "chcę podwyżkę", nie mając w ręku żadnych liczb.

Krok 1: zmierz. Przez 4-6 tygodni zbierasz 4 liczby:

• liczbę zadań zamkniętych w sprincie,
• estymację kontra rzeczywisty czas,
• liczbę bugów, które wracają po wdrożeniu,
• liczbę powrotów z code review.

Punkt startu, czyli jak było przed AI, weźmiesz z historii w Jirze albo Azure DevOps. To ważne, bo bez "przed" nie ma "po".

Krok 2: pokaż - językiem szefa. Tu większość się wykłada, bo mówi o narzędziu: "używam AI i jestem szybszy". A szefa nie obchodzi, jakiego narzędzia używasz. Obchodzi go, ile zespół dowozi, ile to kosztuje i czy coś się pali na produkcji. Porównaj 2 komunikaty:

• Zamiast: "Używam AI i jestem szybszy."

• Powiedz: "Przez ostatnie 6 tygodni zamknąłem 38 zadań, wcześniej średnio 24. Bugi po wdrożeniu: tyle samo co wcześniej. Czas review: bez zmian."

Liczby w drugim zdaniu to przykład - podstawiasz swoje. Ale zwróć uwagę na jego drugą część.

Szybciej = byle jak? Kiedy szef słyszy "szybciej", często myśli: "czyli byle jak". Dlatego zawsze podajesz tempo i jakość razem, w jednym zdaniu. Jedno bez drugiego nie działa. Sama liczba zamkniętych zadań budzi podejrzenia. Liczba zadań plus ta sama liczba bugów i bez zmian w review buduje zaufanie.

Najmocniejszy ruch: przyspiesz cały zespół. A teraz coś, o czym mało kto myśli. Jeśli tylko Ty jesteś szybszy - jesteś dobrym programistą. Jeśli dzięki Tobie cały zespół jest szybszy - to jest rozmowa o awansie.

Jak to zrobić w praktyce? 4 konkretne rzeczy:

• Plik CLAUDE.md w repozytorium z konwencjami projektu, żeby AI u każdego w zespole pisało kod według tych samych zasad.

• Gotowe instrukcje do typowych zadań, takich jak nowy endpoint, migracja czy testy.

• 30 minut demo dla zespołu na żywym kodzie, a nie na slajdach.

• Proste zasady review kodu napisanego przez AI.

To jest robota tech leada. I tak zwykle wyglądają awanse: najpierw robisz tę robotę, potem dostajesz tytuł.

Krok 3: porozmawiaj. Termin ma znaczenie. Najlepiej przed przeglądem rocznym albo zanim firma zamknie budżet na kolejny rok - wtedy jest jeszcze z czego dzielić. Nie w piątek o 16:55 na korytarzu. Sama rozmowa to 3 rzeczy:

1. Co dowiozłeś - z liczbami.
2. Za co chcesz odpowiadać dalej.
3. Konkret: kwota albo stanowisko.

Nie pytasz. Proponujesz. Zamiast pytać: "Czy mogę dostać podwyżkę?", mówisz:

"Oto co dowiozłem. Chcę odpowiadać za wdrożenie AI w zespole. Proponuję stawkę X."

To zupełnie inna rozmowa. W pierwszej prosisz o przysługę, w drugiej przedstawiasz propozycję popartą wynikami.

A jeśli usłyszysz "nie"? To też się zdarza. Ale pamiętaj: te liczby są Twoje, nie firmy. Wkładasz je do CV i opowiadasz o nich na rozmowie rekrutacyjnej. Porównaj 2 linijki w CV:

• "Znam AI" - to dziś pisze każdy.
• "Skróciłem czas dowiezienia funkcji o 40% bez wzrostu liczby bugów" - to pisze prawie nikt.

Tak czy inaczej zarabiasz. Najwyżej w innej firmie.

Droga #2: czas po etacie - freelance albo własny produkt

Wieczór z AI to nie ten sam wieczór co kiedyś. AI przyspiesza Cię nie tylko w pracy. 2 godziny wieczorem dziś to nie są te same 2 godziny co kiedyś - da się w nich zrobić kilka razy więcej. Wymówka "nie mam czasu na własny projekt" właśnie mocno się skurczyła.

Opcja A: freelance. Szukaj małych, konkretnych zleceń, które znasz z codziennej pracy:

• API dla aplikacji mobilnej,
• integracja z płatnościami albo zewnętrznym systemem,
• panel admina,
• migracja starego projektu na nowy .NET.

To zadania, w których czujesz się pewnie, bo robisz je na etacie. Z AI zrobisz je szybciej, a klient i tak płaci przede wszystkim za Twoje doświadczenie i działający wynik.

Za godzinę czy za projekt? I tu jest najważniejsza rzecz w całym freelansie z AI. Jeśli rozliczasz się za godzinę, AI obniża Ci zarobek. Policzmy:

Zlecenie, które kiedyś zajmowało 10 godzin po 150 zł, dawało 1 500 zł. Dziś robisz je w 4 godziny i przy stawce godzinowej dostajesz 600 zł. Klient się cieszy. Ty nie. Jeśli wyceniasz za projekt - 1 500 zł za całość - te same 4 godziny dają Ci 375 zł za godzinę. Ta sama praca, ten sam klient, zupełnie inny wynik.

Zasada. Zapamiętaj to zdanie: szybkość zarabia tylko wtedy, kiedy płacą Ci za wynik. Dotyczy freelansu i dotyczy etatu. Dlatego w drodze #1 rozmawiasz z szefem o wynikach, a nie o godzinach.

Opcja B: własny produkt. U mnie to StrefaWatow.pl - aplikacja, która układa plan treningowy dla kolarzy. Krótka ankieta, gotowy plan i konkretny trening na dziś: na Zwifta, MyWhoosha albo na zewnątrz. Zrobiłem ją, bo sam długo jeździłem bez planu i nie widziałem postępów. Od pomysłu do działającej aplikacji minęło 7 dni - zbudowałem ją w tydzień, z AI. Bez AI to byłyby miesiące wieczorów i pewnie nigdy by nie wyszła z mojej głowy.

Zanim zaczniesz: sprawdź umowę. Zanim odpalisz cokolwiek po godzinach, jedna nudna, ale ważna rzecz. Sprawdź w umowie i trzymaj się kilku zasad:

• zakaz konkurencji - czy w ogóle go masz i co dokładnie obejmuje,
• prawa do kodu pisanego po godzinach - szczególnie na B2B bywają tu różne zapisy,
• żadnego firmowego laptopa, konta ani licencji AI - projektów pobocznych nigdy na nich nie rób,
• nie wynosisz kodu ani wiedzy klienta.

Jeśli masz wątpliwości, zapytaj prawnika. 30 minut rozmowy może Ci oszczędzić bardzo dużo nerwów.

Jak zacząć. Nie rzucaj etatu. Na start wystarczy:

• 1 wieczór w tygodniu,
• 1 mały projekt,
• 1 cel: pierwszy klient, który Ci zapłaci. Nawet mało.

Pierwsze zarobione w ten sposób pieniądze zmieniają w głowie więcej niż 10 przeczytanych poradników.

Pułapka: szybciej, ale z bugami

Teraz pułapka, przez którą możesz stracić wszystko, o czym była mowa wyżej.

Bilans jednego buga. Wróćmy do mojego endpointu. Zaoszczędziłem 3 godziny 15 minut. A teraz wyobraź sobie, że wypuszczam go bez porządnego review i na produkcji wychodzi bug:

• diagnoza, czyli szukanie przyczyny: 1 h,
• poprawka: 1 h,
• testy i wdrożenie hotfixa: 1 h,
• spotkanie "co poszło nie tak": 1 h.

Razem 4 godziny. Bilans:

+3:15 - 4:00 = -45 minut

Jestem 45 minut na minusie. I to nie jest najgorsze. Najgorsze jest to, że straciłem zaufanie. A zaufanie to dokładnie to, czego potrzebujesz przy rozmowie o podwyżce. Jeden poważny bug i w głowie szefa "szybki" zamienia się w "niedokładny". Wszystkie Twoje liczby z drogi #1 właśnie straciły wartość.

Gdzie AI najczęściej myli się w .NET? 6 typowych błędów

Z mojego doświadczenia AI w .NET myli się w powtarzalnych miejscach. Warto znać je na pamięć, bo właśnie je trzeba wyłapywać w review.

1. Bezpieczeństwo: brak [Authorize] albo sprawdzenia właściciela zasobu. AI chętnie generuje endpoint, który działa, ale nie sprawdza, czy użytkownik w ogóle powinien mieć dostęp. Brakuje atrybutu [Authorize] albo sprawdzenia, czy zasób, o który pyta użytkownik, w ogóle do niego należy:

/* Źle: każdy może pobrać dowolne zamówienie */
[HttpGet("{id}")]
public async Task<IActionResult> GetOrder(int id)
{
    var order = await _db.Orders.FindAsync(id);
    return Ok(order);
}

/* Lepiej: [Authorize] + sprawdzenie, czy zamówienie należy do użytkownika */
[Authorize]
[HttpGet("{id}")]
public async Task<IActionResult> GetOrder(int id)
{
    var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    var order = await _db.Orders
        .FirstOrDefaultAsync(o => o.Id == id && o.UserId == userId);

    return order is null ? NotFound() : Ok(order);
}

2. EF Core: N+1 i ToListAsync() przed Where. Problem N+1 to zapytanie do bazy w pętli: zamiast 1 zapytania aplikacja wysyła ich tyle, ile jest rekordów. Drugi klasyk to ToListAsync() przed Where - cała tabela ląduje w pamięci, a filtrowanie odbywa się dopiero w C#. Na testowej bazie ze 100 rekordami wszystko działa świetnie. Na produkcji z milionem - już nie:

/* N+1: osobne zapytanie do bazy dla każdego zamówienia */
var orders = await _db.Orders.ToListAsync();
foreach (var order in orders)
{
    var items = await _db.OrderItems
        .Where(i => i.OrderId == order.Id)
        .ToListAsync();
    Console.WriteLine($"{order.Id}: {items.Sum(i => i.Price)}");
}

/* Lepiej: 1 zapytanie, sumowanie po stronie bazy */
var totals = await _db.Orders
    .Select(o => new { o.Id, Total = o.Items.Sum(i => i.Price) })
    .ToListAsync();

/* Źle: cała tabela trafia do pamięci, filtrowanie dopiero w C# */
var customers = await _db.Customers.ToListAsync();
var active = customers.Where(c => c.IsActive).ToList();

/* Dobrze: Where przed ToListAsync - filtruje baza */
var activeCustomers = await _db.Customers
    .Where(c => c.IsActive)
    .ToListAsync();

3. Async: .Result albo .Wait() zamiast await. Blokujesz wątki, czekając na wynik, i pod obciążeniem aplikacja staje:

/* Źle: blokujesz wątek */
var product = _productService.GetByIdAsync(id).Result;
_emailService.SendAsync(message).Wait();

/* Dobrze */
var product = await _productService.GetByIdAsync(id);
await _emailService.SendAsync(message);

4. Wyjątki połknięte przez pusty catch. Błąd znika bez śladu, a Ty szukasz go 2 dni:

/* Źle: wyjątek znika bez śladu */
try
{
    await _paymentService.ChargeAsync(order);
}
catch { }

/* Lepiej: zaloguj i nie udawaj, że wszystko poszło dobrze */
try
{
    await _paymentService.ChargeAsync(order);
}
catch (Exception ex)
{
    _logger.LogError(ex, "Płatność za zamówienie {OrderId} nie powiodła się", order.Id);
    throw;
}

5. Zmyślone API. AI potrafi z pełnym przekonaniem użyć metod, których nie ma w Twojej wersji biblioteki. Kod wygląda wiarygodnie, dopóki nie spróbujesz go zbudować. Dlatego przy każdej nieznanej metodzie warto zajrzeć do dokumentacji tej wersji pakietu, której faktycznie używasz.

6. Testy, które sprawdzają mocki zamiast logiki. Wszystko jest zielone, a kod i tak nie działa. Typowy przykład - test, który wywołuje mocka zamiast testowanej klasy:

/* Test, który sprawdza mocka, a nie logikę */
[Fact]
public void GetTotal_ReturnsOrderTotal()
{
    var repository = new Mock<IOrderRepository>();
    repository.Setup(r => r.GetTotal(1)).Returns(100m);

    var total = repository.Object.GetTotal(1); /* wywołujemy mocka, nie serwis */

    Assert.Equal(100m, total); /* zawsze zielony */
}

Taki test podnosi pokrycie kodu, ale nie sprawdza ani jednej linijki Twojej logiki. Jeśli AI pisze Ci testy, zawsze sprawdź, co tak naprawdę jest w nich wywoływane i porównywane.

Jak się bronić: 4 zasady i uczciwy pomiar

Żadnego z tych błędów nie da się wyeliminować w 100%, ale da się je wyłapać, zanim trafią na produkcję. Wystarczą 4 zasady:

1. Małe kroki i commit po każdym.
2. Testy, zanim powiesz "gotowe".
3. Review każdej linii - tak, jakby napisał ją junior.
4. Definition of Done ustalone, zanim w ogóle zaczniesz.

W skrócie: zarządzaj AI jak juniorem. Dajesz mu zadanie, ale za wynik odpowiadasz Ty.

Co naprawdę mierzysz. Dlatego mierz uczciwie. Nie czas do momentu, kiedy AI wypluło kod. Nie czas do pierwszego "działa u mnie". Liczy się czas do działającego kodu na produkcji, który nie wrócił jako bug. Tylko ta liczba ma wartość, bo tylko ją możesz pokazać szefowi bez ryzyka, że za tydzień obróci się przeciwko Tobie.

Zadanie na ten tydzień: tabelka do skopiowania

Bez tego kroku nic z powyższego nie zadziała: przy każdym zadaniu zapisuj estymację i rzeczywisty czas. Od tego zaczyna się każda z opisanych dróg - i rozmowa z szefem, i wycena zleceń, i uczciwy pomiar. Skopiuj taką tabelkę do notatek albo arkusza:

Po tygodniu masz pierwszą twardą liczbę. Po 4-6 tygodniach - argumenty do rozmowy o podwyżce. Pamiętaj tylko, żeby w kolumnie "rzeczywisty czas" liczyć czas do działającego kodu na produkcji, a nie do pierwszego "działa u mnie".

Podsumowanie

AI oszczędza Ci godziny, ale te godziny domyślnie trafiają do firmy. Żeby to zmienić, zapamiętaj 4 rzeczy:

1. Policz, ile oddajesz: stawka × zaoszczędzone godziny. Przy 100 zł za godzinę i 1 godzinie dziennie to 25 200 zł rocznie.
2. Zmierz i pokaż wyniki językiem szefa: tempo i jakość w jednym zdaniu, a najlepiej przyspiesz cały zespół.
3. Po etacie wyceniaj za projekt, nie za godzinę.
4. Nie płać za szybkość bugami.

I zacznij jeszcze w tym tygodniu: przy każdym zadaniu zapisuj estymację i rzeczywisty czas.

Ten artykuł to było "co" i "dlaczego". Jeśli chcesz "jak" - jak krok po kroku dojść do takich godzin w prawdziwym projekcie .NET i jak pokazać je szefowi - robimy to w Szkole 3x Dev. W ostatnim module dostajesz gotowy szablon prezentacji dla CTO albo PM-a: wpisujesz swoje liczby i idziesz na rozmowę.

Szczegóły i najbliższy termin zapisów znajdziesz tutaj: modestprogrammer.pl/szkola-3x-dev.

Powodzenia w odzyskiwaniu swoich godzin :)