Programista w czasach AI

Programuję od 2005 roku i przez te ponad 20 lat słyszałem już kilka razy, że „programiści za chwilę nie będą potrzebni”. Najpierw miały nas zastąpić generatory stron, potem WordPress z gotowymi motywami, potem narzędzia no-code. Dziś tę samą śpiewkę słychać o AI – tyle że tym razem po raz pierwszy mam wrażenie, że coś faktycznie jest na rzeczy. Tylko nie do końca to, co straszą nagłówki.

Do napisania tego wpisu skłoniło mnie ostatnie pół roku – zarówno w pracy, gdzie rozwijamy bramkę płatniczą Autopay, jak i po godzinach, przy własnych projektach: Florino.io, flora-art.pl i… tym blogu, który niedawno przeprowadziłem z WordPressa na Nuxta. We wszystkich tych miejscach Claude Code dramatycznie zmienił mój sposób pracy. Kiedyś cały kod trzeba było napisać ręcznie, pamiętać o wszystkich zależnościach, mozolnie dłubać testy. Dziś żmudne kodowanie i ręczne rozwiązywanie każdego problemu mogę oddelegować narzędziu, które robi to szybciej i dokładniej ode mnie – a sam mogę skupić się na szukaniu ulepszeń, optymalizacji i nowych ficzerów.

Moja teza jest prosta: AI nie sprawi, że programista będzie niepotrzebny. Ale dramatycznie zmieni to, czym się na co dzień zajmuje. Zamiast pisać kod linijka po linijce, będziemy wyznaczać ramy, w jakich AI ten kod tworzy – i pilnować, żeby z tych ram nie wychodziło. A ponieważ samo gadanie niczego nie dowodzi, to na koniec opiszę projekt, który sam w ten sposób zbudowałem od zera do produkcji. No to lecimy…

Woźnica, kierowca i… programista?

Każdy postęp technologiczny wymusza zmiany. Kiedy samochód zaczął wypierać powóz konny, woźnice nie zniknęli z dnia na dzień – większość z nich po prostu przesiadła się za kierownicę. Zmieniło się narzędzie, zmieniły się umiejętności (o koniu można było zapomnieć, za to trzeba było ogarnąć silnik i skrzynię biegów), ale potrzeba została ta sama – ktoś musi zawieźć ludzi i towar z punktu A do punktu B.

Ktoś powie: no dobra, ale kierowców też za chwilę zastąpią autonomiczne samochody. Być może. Tylko zauważmy, że wtedy znowu ktoś będzie musiał zdecydować, dokąd ten samochód ma jechać, jaką trasą, z jakim ładunkiem i co zrobić, gdy po drodze coś pójdzie nie tak. Rola się przesuwa – z wykonawcy w stronę tego, kto wyznacza cel i pilnuje rezultatu.

W programowaniu dzieje się dokładnie to samo. Przez lata naszą główną wartością było to, że potrafimy przetłumaczyć wymagania na działający kod. Teraz to tłumaczenie coraz lepiej robi maszyna. Więc albo zostaniemy przy koniu i będziemy narzekać na hałaśliwe automobile, albo przesiądziemy się za kierownicę.

Co tak naprawdę się zmieniło?

Na pewno nie to, że AI „pisze kod”. Sam przeszedłem tę drogę po kolei: najpierw zwykłe pytania na czacie, potem AI wbudowane w WebStorma – przydatne np. przy plikach tłumaczeń i drobnych podpowiedziach. Fajne, ale szału nie było. Przełom zrobiły dopiero agenty – w moim przypadku Claude Code w pełni zintegrowany z projektem. Takie narzędzie nie podpowiada linijki, tylko dostaje zadanie, czyta kod, odpala testy, poprawia błędy i wraca z gotowym rozwiązaniem. Dopiero to otworzyło mi oczy na zupełnie nowy sposób pracy z kodem.

Z mojej perspektywy zmieniły się 3 rzeczy.

Szybciej. To oczywiste, ale skala jest trudna do wyobrażenia, dopóki się samemu nie spróbuje. Strona flora-art.pl – razem ze sklepem online i integracjami z bramką płatniczą, mailami, fakturami i Baselinkerem – powstawała kilka miesięcy i wymagała sporej rozkminy. Dziś dodanie nowych funkcjonalności, gruntowna modernizacja wyglądu i działania czy optymalizacja SEO to kwestia dni. I uczciwie przyznam – ograniczeniem nie jest już narzędzie, tylko ja i tempo, w jakim jestem w stanie przeglądać i iterować kolejne zmiany.

Pewniej. I tu wielu osobom włączy się czerwona lampka – bo przecież AI halucynuje, wymyśla nieistniejące API i pisze bzdury. Tak, zdarza się. Ale to jest dokładnie ten sam problem, który mamy z kodem pisanym przez ludzi – i rozwiązanie jest to samo: testy. Różnica polega na tym, że AI testów pisać się nie nudzi. Nie ma tego klasycznego „dopiszę później”, które w praktyce znaczy „nigdy”. Jeśli w ramach pracy ustalę, że każda zmiana ma być pokryta testem i przejść lint + typecheck, to tak będzie – za każdym razem.

Wydajniej. I nie chodzi tylko o wydajność kodu, ale o wydajność całego procesu. Mniej przełączania kontekstu, mniej szukania w dokumentacji, mniej „klepania” boilerplate'u. Zostaje więcej głowy na to, co naprawdę ważne – czyli na to, co ma powstać, a nie jak to napisać.

Od pomysłu do produktu – w tydzień?

Najbardziej spektakularnie widać to po czasie realizacji. Klasyczna droga wygląda mniej więcej tak: pomysł → makieta → POC → MVP → produkt. Każdy z tych etapów to były tygodnie, a w większych firmach miesiące. Często projekt umierał gdzieś między POC a MVP, bo po prostu skończył się budżet albo cierpliwość.

Dziś te etapy skracają się tak bardzo, że zaczynają się zlewać. POC robi się w jedno popołudnie, a granica między „działającym prototypem” a „produktem, który można sprzedać” zaczyna zależeć bardziej od integracji z zewnętrznym światem (płatności, faktury, przepisy) niż od samego pisania kodu.

Brzmi jak marketing? Też bym tak pomyślał. Dlatego przejdę do konkretów.

Florino – czyli eksperyment na sobie

Florino.io to SaaS dla firm, które obsługują uroczystości – kwiaciarni, dekoratorów, cateringów, sal weselnych. Problem, który rozwiązuje, jest bardzo przyziemny: takie firmy w kółko odpowiadają ręcznie na pytanie „ile to będzie kosztować?” – przez telefon, Messengera, WhatsAppa – i za każdym razem dopytują o datę, miejsce i zakres.

Pomysł wziął się z naszego własnego podwórka. Pierwotnie Florino było zwykłym formularzem na stronie flora-art.pl – narzędziem, które miało rozwiązać nasz konkretny problem, czyli tracenie czasu na zbieranie ustaleń do wyceny. Z czasem, po rozmowach z innymi florystami, okazało się, że ten problem jest powszechny. A skoro tak, to rozwiązanie można udostępnić także innym firmom – w formie platformy SaaS.

Florino daje każdej firmie własny konfigurator wyceny – na subdomenie (firma.florino.io) albo osadzony na jej stronie. Klient w 3 krokach wybiera typ uroczystości, usługi z wariantami (suma liczy się na żywo) i podaje termin oraz kontakt. Firma dostaje gotowe zapytanie w panelu, może je edytować, wersjonować, odesłać klientowi wycenę zwrotną. Do tego rozliczenia w modelu kredytów albo abonamentu – z płatnościami online i automatycznymi fakturami.

Całość zbudowałem sam, z Claude Code jako partnerem do programowania. Budżetu jako takiego nie zakładałem – chyba że liczyć mój czas. Na etapie POC i pilotażu całość stoi na darmowych planach Vercela i Resenda. Dziś Florino jest osadzone jako iframe na flora-art.pl i działa jako samodzielne narzędzie – nadal rozwiązuje nasz problem, ale jednocześnie każda inna firma może je u siebie zintegrować.

Kilka liczb, które same w sobie mówią więcej niż cały ten wstęp:

• 1 dzień do działającego MVP – szkielet na Nuxt 4, multi-tenant po subdomenach, konfigurator, panel admina, landing, rejestracja i logowanie
• ~2 tygodnie do produktu kompletnego – z płatnościami jednorazowymi i cyklicznymi, fakturami VAT i gotowością pod KSeF
• 543 commity w 144 dni kalendarzowe, z czego aktywnie pracowałem tylko przez 25 dni
• 313 z 350 merytorycznych commitów (89%) ma trailer Co-Authored-By: Claude
• 1 autor – czyli ja

Jak to wyglądało w praktyce?

Pierwszy commit poleciał 3 maja 2026. Tego samego dnia stał już cały szkielet: model danych z tenantId, middleware rozpoznający firmę po subdomenie, konfigurator i panel. Przy czym – żeby nie było tak różowo – większość tego dnia zeszła na walce z routingiem subdomen i sesją, która miała przechodzić między domeną platformy a subdomeną firmy. Kilkanaście poprawek w pierwszej dobie…

Potem poszło już z górki:

• 4–9 maja – produkt, którego da się używać: kolejka zadań na Upstash QStash, maile przez Resend, wersjonowanie wycen, embed na stronę klienta, dane firmy z GUS po NIP, Sentry, GA4
• 7–25 maja – monetyzacja: plany BASIC/STANDARD/PRO, kredyty, płatności przez Autopay (jednorazowe i cykliczne), faktury w iFirma, KSeF
• czerwiec – przerwa, 0 commitów. Po intensywnym maju to był naturalny czas na regenerację, ale też na wygrzanie się niektórych rozwiązań – np. subskrypcji, czyli płatności rekurencyjnych w bramce. Praktyka szybko obnażyła dziury w funkcjonalności, które potem trzeba było załatać
• lipiec – audyt i hardening
• wrzesień – onboarding, landing dla florystów, przebudowa strony głównej, kampanie mailowe

Rekordowym dniem był 14 maja – 77 commitów, w tym branding, Autopay i iFirma. Ciekawostka z gatunku „programista to też człowiek”: najczęstsza godzina commitowania to 20:00, a 37% commitów poleciało między 20:00 a 6:00 rano. Kto ma 3 dzieci, ten wie, że wieczór to jedyny moment na własne projekty 🙂

A co robiłem ja?

I tu dochodzimy do sedna całego wpisu. Bo gdyby te 89% commitów oznaczało, że AI zrobiło 89% roboty, a ja tylko klikałem „akceptuj” – to cała moja teza by się posypała.

Tak to nie działa.

Moja praca polegała na czymś zupełnie innym niż klasyczne programowanie. Wyznaczałem ramy:

• architektura – multi-tenant na jednej instancji, tenantId zawsze z kontekstu requestu, nigdy z body
• stack – Nuxt 4 + Prisma + Neon + Vercel, czyli serverless i zero infrastruktury do utrzymania przez jedną osobę
• narzędzia i usługi – Better Auth zamiast własnej autoryzacji, kolejka do maili (bo w serverless nie ma bezpiecznego „fire and forget”), Autopay do płatności, iFirma do faktur
• zasady – TypeScript strict, walidacja przez Zod, testy unit (Vitest) i E2E (Playwright), CI na GitLabie
• decyzje produktowe – i to jest chyba najważniejsze

Bo to nie AI wymyśliło, że katalog usług nie może być sztywnym enumem WEDDING/COMMUNION, tylko danymi definiowanymi przez każdą firmę – co z dnia na dzień otworzyło produkt na inne branże niż floryści. To nie AI zdecydowało, że gdy firmie skończą się kredyty, zapytanie klienta ma się zapisać jako „zablokowane” (z zamaskowanymi danymi), a nie zwrócić błąd – bo lead nie może przepaść, a firma ma mieć powód, żeby doładować konto. To nie AI wpadło na to, że wycena musi przechowywać kopię nazw usług, a nie relację do katalogu – bo inaczej zmiana cennika popsuje całą historię.

Natomiast jak to zaimplementować – jaką strukturę tabel przyjąć, jak napisać endpointy, jak to przetestować – to już w zdecydowanej większości dobierał i realizował Claude. Ja czytałem, poprawiałem kierunek, odrzucałem, prosiłem o inaczej.

Gdzie AI się wyłożyło – a raczej: gdzie ja się wyłożyłem?

Żeby nie było, że to bajka o cudownym narzędziu – kilka rzeczy poszło mocno nie tak. I co ciekawe, prawie żadna z nich nie dotyczyła samej logiki produktu.

Najwięcej czasu pochłonęły integracje zewnętrzne. Podpis (hash) w płatnościach Autopay wymagał kilkunastu kolejnych prób ustalenia kolejności pól – dokumentacja i SDK nie dawały jednoznacznej odpowiedzi, pomogło dopiero logowanie i iterowanie na sandboksie. Z iFirma i KSeF podobnie – większość pracy szła w odkrywanie, jak API działa naprawdę, a nie jak jest opisane. Do tego CSP, gdzie każda zewnętrzna usługa (GA, Sentry, CookieYes, YouTube, Meta Pixel…) to osobna poprawka nagłówków. AI potrafi przeczytać dokumentację szybciej niż ja – ale jeśli dokumentacja kłamie, to kłamie dla obu z nas tak samo.

Ale prawdziwy zimny prysznic przyszedł w lipcu, przy audycie. Okazało się, że:

• crony nie działały w ogóle – Vercel wywołuje je metodą GET, a endpointy były zrobione jako *.post.ts. Odnawianie subskrypcji i czyszczenie kont po prostu nigdy się nie uruchomiło. Przez 2 miesiące…
• ceny w wycenie przychodziły z body requestu – czyli z przeglądarki – i bez weryfikacji lądowały w bazie i w mailach. Klasyka, którą każdy z nas zna z teorii.
• usunięcie konta zamykało tylko użytkownika, a firma i subskrypcja działały dalej

Ktoś powie: no i proszę, AI pisze dziurawy kod. Tylko że… to jest dokładnie ten rodzaj błędów, który robią ludzie, zwłaszcza pod presją czasu. I dokładnie ten rodzaj błędów, który powinien wyłapać ktoś, kto patrzy na system z góry – czyli ja. Z wielką mocą wiąże się wielka odpowiedzialność, jak mawiał wujek Spider-Mana. Jeśli AI daje mi moc zbudowania SaaS-a w 2 tygodnie, to odpowiedzialność za to, czy on jest bezpieczny, nadal leży po mojej stronie.

Wniosek wyciągnąłem prosty: „działa” to nie to samo co „działa poprawnie”. Regularny przegląd architektury i bezpieczeństwa musi być stałym etapem pracy, a nie jednorazową akcją po fakcie. I – co ciekawe – sam audyt też robiłem z AI, tylko z zupełnie inną rolą: nie „napisz”, a „znajdź, co tu jest źle”. Zresztą robię tak do dziś – różnymi narzędziami AI sprawdzam SEO, optymalizację i wydajność, a także analizuję zgłoszenia z Sentry.

Programista jako architekt i orkiestrator

Jeśli więc mam opisać, jak zmieniła się moja rola przy tym projekcie, to wyglądało to mniej więcej tak:

• wyznaczam cel – co ma powstać i po co (biznesowo, nie technicznie)
• wyznaczam ramy – architektura, stack, zasady, czego nie wolno
• daję narzędzia – jakie usługi, biblioteki, dostęp do jakiej dokumentacji
• pilnuję jakości – testy, review, audyty
• podejmuję decyzje, których nie da się wyczytać z kodu – produktowe, prawne, kosztowe

Natomiast samo dobranie optymalnego rozwiązania w tych ramach i jego wykonanie – to robi AI. I robi to coraz lepiej.

Brzmi znajomo? Pisałem kiedyś o tym, czym różni się Junior, Mid czy Senior. Wtedy Mid był dla mnie osobą, której zlecam zadanie, a ona je wykonuje. Dziś mam wrażenie, że AI wskoczyło właśnie na ten poziom – samodzielnego wykonawcy. A od człowieka zaczyna się wymagać tego, czego dotąd wymagało się od Seniora albo Architekta: rozumienia kontekstu, znajomości drogi kodu na produkcję, umiejętności oceny cudzych rozwiązań.

I tu widzę największe zagrożenie – nie dla doświadczonych programistów, a dla juniorów. Bo skoro ten „wykonawczy” poziom przejmuje maszyna, to jak zdobyć doświadczenie potrzebne, żeby ją nadzorować? Nie mam na to gotowej odpowiedzi. Ale to już temat na inny wpis…

Czy było warto?

Technologicznie – zdecydowanie tak. Technologia przestała być ryzykiem po około 2 tygodniach. Kompletny SaaS z płatnościami, fakturami i testami (~330 przypadków unit i 33 scenariusze E2E) zbudowałem sam w czasie, który kiedyś wystarczał na makietę i kilka spotkań o wymaganiach.

Biznesowo – szału na razie nie ma i nie będę udawał, że jest. Stan na wrzesień: 5 zarejestrowanych firm, 1 aktywnie testuje, płacących klientów brak. Ryzyko przesunęło się z „czy uda się to zbudować?” na „czy ktoś tego potrzebuje i jak do niego dotrzeć?”. I to jest chyba najciekawsza lekcja z całego projektu – skoro kod przestaje być wąskim gardłem, to wąskim gardłem staje się wszystko inne: sprzedaż, marketing, dystrybucja, rozmowy z klientami. Rzeczy, których żaden agent za mnie (jeszcze) nie zrobi.

Dla mnie Florino było przede wszystkim poligonem doświadczalnym. To pierwszy serwis, który zbudowałem w roli architekta i orkiestratora zadań, a nie „klepacza” kodu. I jednocześnie eksperyment – czy uda mi się stworzyć działającą, funkcjonalną aplikację praktycznie bez samodzielnego pisania kodu, ale przy zachowaniu dobrych praktyk i świadomym doborze narzędzi. Odpowiedź – przynajmniej w moim przypadku – brzmi: tak.

Co dalej?

Postanowiłem nie dokładać na siłę kolejnych funkcji. Na razie skupiam się na onboardingu zaprzyjaźnionych florystów – chcę, żeby przetestowali platformę i dali mi szczery feedback. Dopiero potem przyjdzie czas na szersze testowanie popytu i kanał partnerski, czyli twórców stron i agencje. Jeśli prowadzisz kwiaciarnię albo robisz strony dla takich firm – zajrzyj na Florino.io i daj znać, co o tym myślisz 🙂

A co do samej tezy – jestem ciekaw, jak to wygląda u Was. Czy też czujecie, że coraz mniej piszecie, a coraz więcej czytacie, oceniacie i decydujecie? Czy może uważacie, że to wszystko jest przereklamowane? Zapraszam do komentowania – bardzo chętnie skonfrontuję swoje spojrzenie z innym.