Scenariusz z 2026 roku, który widzieliśmy już wielokrotnie: founder pokazuje demo aplikacji, którą „zbudował z AI w tydzień". Wygląda świetnie do momentu, gdy pojawia się drugi użytkownik, pierwsza integracja z płatnościami albo pytanie „a gdzie właściwie są dane osobowe klientów?". AI zdemokratyzowało pisanie kodu, ale nie zdemokratyzowało budowania produktów. Właśnie w tej szczelinie narodziła się nowa rola: product builder. Najważniejsza obserwacja tego tekstu: AI nie jest dodatkiem do kompetencji, tylko ich mnożnikiem. Pomnóż przez zero doświadczenia, a dostaniesz zero, tyle że szybciej i ładniej opakowane. Pomnóż przez lata praktyki architekta, a dostaniesz aplikacje o jakości i kompleksowości, na które kiedyś potrzeba było całego zespołu i kwartałów pracy. W artykule: kim jest product builder, dlaczego to nie jest „programista z Copilotem" ani „PM, który nauczył się promptować", i dlaczego najlepsi product builderzy wyrastają z solution architectów.
Co się zmieniło: kod przestał być wąskim gardłem
Przez dekady najdroższym zasobem w projektach software'owych był czas programisty i cały przemysł zbudowano wokół racjonowania tego zasobu: scrum, estymaty, backlogi, roadmapy na kwartały. Narzędzia klasy agentic coding odwróciły to równanie. Skala adopcji nie jest już przedmiotem sporu: według raportu DORA 2025 (State of AI-assisted Software Development) 90% specjalistów wytwarzających oprogramowanie używa AI w pracy, poświęcając na to medianę dwóch godzin dziennie; ponad 80% deklaruje wzrost produktywności. Podobnie Stack Overflow Developer Survey 2025: 84% respondentów używa lub planuje używać narzędzi AI.
Ale te same badania pokazują drugą stronę: zaufanie spada, gdy rośnie użycie. W badaniu Stack Overflow więcej developerów aktywnie nie ufa dokładności odpowiedzi AI (46%), niż jej ufa (33%), a „wysokie zaufanie" deklaruje ledwie 3%. W DORA 30% respondentów ma niewielkie zaufanie do generowanego kodu albo nie ma go wcale, choć używa go codziennie. I jeszcze ciekawiej: rygorystyczne badanie METR (randomizowane, na realnych zadaniach w dojrzałych projektach open source) pokazało, że doświadczeni developerzy pracujący z AI na dobrze znanym sobie kodzie byli o 19% wolniejsi, będąc jednocześnie przekonanymi, że są szybsi.
Jak pogodzić te dane? Naszym zdaniem tak: AI radykalnie przyspiesza wytwarzanie kodu, ale kod przestał być wąskim gardłem. Wąskim gardłem stało się wszystko wokół kodu: decyzje co budować, jak złożyć to w system i po czym poznać, że działa naprawdę, a nie tylko na demo. Tam, gdzie tych decyzji brakuje, przyspieszenie generowania daje wolniejszy projekt (przypadek METR) albo szybszą produkcję długu. Tam, gdzie są, dzieje się coś, do czego wrócimy: mnożnik.
Kim jest product builder: definicja przez odpowiedzialność
Product builder to jedna osoba (lub bardzo mały zespół), która bierze odpowiedzialność za produkt end-to-end: od rozmowy z klientem i zrozumienia problemu biznesowego, przez architekturę i implementację z pomocą AI, po deploy, monitoring i iterację na danych z produkcji. Nie jest to nowa nazwa na żadną z istniejących ról, co najlepiej widać w zestawieniu odpowiedzialności:
| Programista + AI | Product manager | Product builder | |
|---|---|---|---|
| Odpowiada za | jakość kodu | „co i po co" | działający produkt w produkcji |
| Horyzont | task / sprint | roadmapa | cały cykl życia produktu |
| Miara sukcesu | zamknięte tickety | zaadoptowane funkcje | produkt, który realizuje cel biznesowy |
| Relacja z AI | akcelerator pisania | konsument raportów | dyrygent zespołu agentów |
Sedno: AI skompresowało role. Tam, gdzie kiedyś potrzebny był product manager, architekt, dwóch developerów i DevOps, dziś jedna właściwa osoba z flotą agentów dowozi to samo szybciej, pod warunkiem, że wie, czego od tych agentów wymagać. To „pod warunkiem" jest treścią całej reszty tego artykułu.
Paradoks vibe codingu: im łatwiej o kod, tym więcej trzeba wiedzieć
Termin vibe coding, czyli programowanie przez opisywanie intencji i akceptowanie tego, co wygeneruje model, bez czytania kodu, zrobił w 2025 roku oszałamiającą karierę. I uczciwie: do prototypów, walidacji pomysłu i narzędzi wewnętrznych działa znakomicie. Problemy zaczynają się przy pierwszym kontakcie z rzeczywistością produkcyjną i są dobrze udokumentowane:
- Bezpieczeństwo. Veracode przetestował kod generowany przez ponad 100 modeli językowych: w 45% zadań AI wprowadziło podatność z listy OWASP Top 10; w przypadku cross-site scriptingu modele nie obroniły się w 86% prób (Veracode, GenAI Code Security Report 2025). Co istotne: wynik nie poprawia się wraz z rozmiarem modelu: nowsze modele piszą kod, który częściej działa, ale nie jest bezpieczniejszy.
- Produkcja. Głośny incydent z lipca 2025: agent AI na platformie Replit skasował produkcyjną bazę danych firmy SaaStr, wbrew wyraźnym instrukcjom, w trakcie code freeze, a następnie wprowadził użytkownika w błąd co do możliwości odzyskania danych (The Register, Fortune). Nie przywołujemy tego, żeby straszyć (platforma wyciągnęła wnioski i dodała zabezpieczenia), tylko dlatego, że doświadczony inżynier nie oddałby agentowi dostępu do produkcyjnej bazy w ogóle. Separacja środowisk to elementarz, ale trzeba wiedzieć, że istnieje.
Na tym polega paradoks vibe codingu: AI z entuzjazmem zbuduje dokładnie to, o co poprosisz, łącznie z antywzorcami. Problem nie leży w modelu, tylko w tym, że osoba prosząca często nie wie, o co powinna poprosić: o idempotentny endpoint, o walidację po stronie serwera, o backup przed migracją, o limit kosztów API. Łatwość generowania kodu nie obniżyła wymagań wobec człowieka, ona je podniosła, bo przesunęła całą odpowiedzialność z „umiem napisać" na „wiem, co ma powstać". AI dało każdemu orkiestrę światowej klasy. Nie dało nikomu słuchu.
Doświadczenie solution architecta: słuch, którego AI nie zastąpi
Skąd więc wziąć ten słuch? Naszym zdaniem najlepszym „poprzednim wcieleniem" product buildera jest solution architect, bo to jedyna rola, która zawodowo ćwiczyła dokładnie te mięśnie, które w erze AI decydują o wszystkim:
- Myślenie systemami, nie feature'ami. Architekt widzi, że „prosty formularz zapisu" to naprawdę walidacja, kolejka, retry po błędzie, zgody RODO i monitoring dostarczalności maili. Wie, gdzie góra lodowa ma podwodną część; pisaliśmy o tym przy okazji PWA i API jako serca aplikacji: ekran to wierzchołek, wartość żyje pod spodem.
- Decyzje o trade-offach pod niepewnością. Kupić czy zbudować? Monolit czy serwisy? Spójność czy dostępność? AI generuje opcje szybciej niż kiedykolwiek, ale wybiera ten, kto poniósł już kiedyś koszt złego wyboru i pamięta, jak on smakuje.
- Projektowanie granic i kontraktów. To umiejętność, która w erze agentów zyskała drugie życie: dobrze zdefiniowany kontrakt (API, schemat danych, interfejs modułu) to najlepszy prompt, jaki istnieje. Agenci znakomicie wypełniają dobrze narysowane pudełka. Ktoś musi umieć je narysować.
- Nieufność zawodowa. Architekt całe życie robił review cudzych rozwiązań. Kod od AI to kod od bardzo szybkiego, bardzo pewnego siebie juniora. Dane Veracode i Stack Overflow z poprzedniej sekcji pokazują, że nawyk weryfikacji nie jest opcją, tylko warunkiem: bez niego skala błędów rośnie dokładnie z prędkością generowania.
- Znajomość „nudnej" warstwy produkcyjnej. Backup i jego testowe odtworzenie, obserwowalność, proces deployu, koszty infrastruktury i API. To, czego nie widać w demie, a co odróżnia produkt od prototypu.
I tu wracamy do tezy z leadu. Relacja między AI a doświadczeniem nie jest sumą, tylko iloczynem. Sam architekt bez AI dowozi dobrze zaprojektowany produkt, ale powoli. Samo AI bez architekta dowozi szybko, ale prototyp, który rozpada się na produkcji. Dopiero razem powstaje coś, czego wcześniej nie było w cenniku małych zespołów: aplikacje jednocześnie szybkie w budowie, kompletne (bezpieczeństwo, monitoring, przypadki brzegowe, zgodność z prawem: rzeczy, na które kiedyś „nie starczało budżetu") i zaprojektowane na rozwój. Doświadczenie przestało być kosztem, który spowalnia. Stało się mnożnikiem, który decyduje, czy dźwignia AI podnosi produkt, czy tylko liczbę linii kodu.
Mnożnik w praktyce: dzień pracy product buildera
Jak to wygląda od kuchni? Odczarujmy: dzień pracy product buildera nie polega na wpisywaniu „zbuduj mi aplikację" i czekaniu.
- Rano: decyzje na granicach. Architektura, kontrakty API, model danych, wybór tego, czego nie budujemy. To praca człowieka i najwyżej lewarowana godzina dnia: każda decyzja tutaj ustawia pracę agentów na resztę doby.
- W ciągu dnia: delegowanie równoległe. Kilku agentów pracuje jednocześnie: implementacja modułu według kontraktu, testy do istniejącego kodu, dokumentacja API, migracja danych. Człowiek nie pisze: wyznacza pudełka, przegląda, odsyła do poprawki.
- Wieczorem: weryfikacja i pomiar. Review wygenerowanego kodu, wycinanie tego, co agent „dobudował z rozpędu", testy na stagingu, potem produkcja i metryki: co użytkownicy naprawdę robią z tym, co powstało.
Zasada organizująca całość: człowiek decyduje na granicach, AI pracuje wewnątrz granic. Tak właśnie budujemy produkty w calmfox, a efekt mnożnika najlepiej widać w zakresie: w budżecie, w którym kiedyś mieściło się „MVP z kompromisami", dziś mieści się produkt z pełną warstwą produkcyjną (testami, monitoringiem, dokumentacją API i ścieżką skalowania). Nie dlatego, że AI „robi więcej", tylko dlatego, że doświadczony builder wie, że o to wszystko trzeba poprosić, i umie zweryfikować, że dostał to naprawdę.
Checklist: po czym poznać prawdziwego product buildera
Zanim powierzysz komuś budowę swojego produktu (niezależnie, czy to freelancer, software house, czy kandydat do zespołu), zadaj pięć pytań:
- Czy potrafi opowiedzieć o produkcie, który utrzymywał po wdrożeniu, a nie tylko zbudował i przekazał?
- Czy na pytanie „jak to zrobisz" odpowiada od danych, użytkowników i granic systemu, czy od nazwy frameworka?
- Czy umie powiedzieć, czego nie zbuduje w pierwszej wersji i dlaczego?
- Czy ma nawyk weryfikacji kodu AI (testy, review, staging), czy „działa na demo" znaczy dla niego „działa"?
- Czy rozumie warstwę produkcyjną: koszty, monitoring, bezpieczeństwo, backup, zgodność z prawem?
5 „tak": masz przed sobą product buildera; AI w jego rękach będzie mnożnikiem. 3–4 „tak": solidny wykonawca; zadbaj, żeby decyzje architektoniczne miały jeszcze jedną parę doświadczonych oczu. 0–2 „tak": dostaniesz demo, nie produkt, nieważne, jak imponująco będzie wyglądać pierwszy tydzień.
Podsumowanie
AI nie zlikwidowało seniority, tylko je przesunęło. Z „jak napisać kod" na „co jest warte zbudowania i jak złożyć to w system, który przeżyje kontakt z użytkownikami". Product builder to nowa nazwa dla starej prawdy: produkty budują ludzie, którzy rozumieją całość. Dane z 2025 roku układają się w jeden wniosek: 90% branży używa AI, ale zaufanie do jego wyników spada, prawie połowa wygenerowanego kodu ma podatności, a doświadczeni inżynierowie bez procesu weryfikacji bywają z AI wolniejsi, nie szybsi. To nie są argumenty przeciwko AI. To argumenty za tym, że AI jest mnożnikiem i że drugi czynnik tego iloczynu, doświadczenie, nigdy nie był więcej wart.
„Najlepsza inwestycja, jaką zrobiłem w erę AI, wydarzyła się dekadę przed nią: to były wszystkie systemy, które zaprojektowałem, zepsułem i naprawiłem jako architekt. AI daje mi dziś dźwignię, jakiej nie miał żaden zespół, z którym pracowałem. Ale dźwignia wzmacnia obie rzeczy: dobre decyzje i złe. Doświadczenie architekta służy do tego, żeby wiedzieć, którą z nich właśnie podejmujesz."
Łukasz Jurys, CTO calmfox.pl sp. z o.o.
