Zbudowałem API z ponad 1,2 mln pytań quizowych, nie pisząc samodzielnie ani jednej linijki kodu. Nazywa się QuizBase i jest w pełni działającym, produkcyjnym serwisem: wielojęzyczne pytania z 12 otwartych źródeł, OpenAPI 3.1, TypeScript SDK na npm i serwer MCP dla Claude i Cursora. Brzmi jak przechwałka albo marketingowy skrót. Nie jest ani jednym, ani drugim. To opis tego, jak realnie wygląda dziś budowanie produktu, gdy jesteś produktowcem, a nie programistą.
Piszę to nie po to, żeby pochwalić się projektem, tylko żeby pokazać zmianę, która ma konsekwencje dla każdego, kto myśli o tym, co AI naprawdę zmienia w firmach. Bo “nie pisząc kodu” nie znaczy “bez pracy”. Znaczy: praca przesunęła się gdzie indziej.
Co właściwie znaczy “nie pisząc kodu”?
Jestem produktowcem od 1996 roku. Pracuję na styku technologii i biznesu, rozumiem procesy, ryzyka i architekturę, ale nie programuję. Przez większość mojej kariery oznaczało to jasny podział: ja definiuję, co i dlaczego ma powstać, ktoś inny pisze kod.
Przy QuizBase ten podział się nie zniknął - on się przesunął. Cały kod pisze Claude Code, agentowe narzędzie do programowania. Ja podejmuję każdą decyzję produktową i architektoniczną: jak ma wyglądać schemat bazy, jak modelować trudność pytań, które źródła włączyć, jak obsłużyć licencje, gdzie postawić granice darmowego planu. Claude proponuje implementację, ja ją oceniam, akceptuję albo odrzucam.
To nie jest “AI zrobiło wszystko”. To jest “jedna osoba rozumiejąca produkt dowiozła go od pomysłu do produkcji”, bo warstwa, która kiedyś wymagała zespołu inżynierów, stała się dostępna przez rozmowę. Różnica jest dokładnie taka jak między dyktowaniem listu a pisaniem go samemu - tekst i tak musi być przemyślany, ale bariera wykonania znika.
Od pomysłu do działającego API
QuizBase nie jest zabawką ani demem. To 1,2 mln pytań zblendowanych i zdeduplikowanych z 12 otwartych zbiorów na licencjach Creative Commons i MIT. Każde pytanie ma kalibrowaną przez model 5-poziomową trudność, przypisanie do regionów kulturowych i pełną atrybucję licencji - autora, źródło i typ licencji per rekord. Do tego REST API ze specyfikacją OpenAPI, klient w TypeScripcie i serwer MCP, który podłącza te dane wprost do asystentów AI.
Pełen opis tego, czym jest produkt i dla kogo, opisałem na stronie QuizBase. Tu ważniejsze jest co innego: to wszystko powstało jako jeden spójny system, utrzymywany i rozwijany dalej. Nie “wygenerowałem kod i mam nadzieję, że działa”. Działa, jest testowane, monitorowane i poprawiane.
Dlaczego produktowiec może dziś zbudować produkt
Przez lata największą barierą między pomysłem a produktem była zdolność wykonania. Miałeś wizję, ale potrzebowałeś zespołu, budżetu i miesięcy, żeby sprawdzić, czy w ogóle ma sens. Większość pomysłów umierała na etapie “nie ma kto tego napisać”.
AI tę barierę radykalnie obniża. To samo zjawisko obserwuję w firmach, z którymi pracuję, i opisywałem je przy okazji tego, jak wdrażać AI zamiast go zakazywać. Pracownik z dobrym rozumieniem procesu i narzędziem AI robi dziś rzeczy, które jeszcze dwa lata temu wymagały całego działu. QuizBase jest moim prywatnym dowodem na tę tezę - zbudowanym na własnej skórze, a nie zasłyszanym z konferencji.
Konsekwencja dla biznesu jest poważna. Jeśli jedna osoba potrafi dowieźć działające API w kilka tygodni, to przewagą przestaje być sam fakt “umiemy to zbudować”. Przewagą staje się to, co budujesz i dlaczego - czyli dokładnie ta warstwa, którą zawsze zajmował się produktowiec.
Gdzie człowiek jest nadal niezastąpiony
Łatwo z tej historii wyciągnąć fałszywy wniosek: skoro AI pisze kod, to wystarczy pomysł i gotowe. Nie wystarczy. Im dłużej buduję QuizBase, tym wyraźniej widzę, gdzie kończy się to, co AI robi świetnie, a zaczyna to, czego nie odda za Ciebie nikt.
- Decyzje architektoniczne. AI zaproponuje schemat bazy, ale to, czy pytania mają mieć kanoniczne ID łączące tłumaczenia między językami, jest decyzją produktową o długofalowych skutkach. Zła decyzja tutaj kosztuje miesiące później.
- Licencje i ryzyko prawne. Zbudowanie zbioru z 12 źródeł to pole minowe licencyjne. Które wolno blendować, co wymaga atrybucji, co można udostępniać dalej. To nie jest pytanie do modelu, to pytanie o odpowiedzialność.
- Kalibracja jakości. Model oceni trudność pytania, ale to ja decyduję, czy pięć poziomów ma sens, gdzie przebiega granica i co znaczy “expert”. Bez tej ramy dane są tylko hałasem.
- Wiedza, czego nie budować. Najtrudniejsza decyzja produktowa to ta o odrzuceniu. AI nigdy nie powie “to jest zbędne” - przeciwnie, chętnie dobuduje każdą funkcję, o którą poprosisz.
To są te same kompetencje, które są kluczowe przy ocenie ryzyka wdrożeń - opisywałem to w metodzie oceny ryzyka AI. Narzędzie jest potężne, ale to człowiek odpowiada za to, gdzie je skierować i kiedy je powstrzymać.
Czego nauczył mnie ten projekt
Po pierwsze: bariera wykonania naprawdę zniknęła, a wraz z nią wymówka “nie mam jak tego sprawdzić”. Jeśli masz pomysł na produkt, dziś realnie możesz zbudować jego działającą wersję sam. To zmienia kalkulację ryzyka przy każdym nowym pomyśle.
Po drugie: wartość przesunęła się w stronę osądu. Kiedy kod jest tani, najcenniejsze staje się wiedzieć, co jest warte zbudowania, jak to ułożyć i kiedy powiedzieć “dość”. To dobra wiadomość dla produktowców i menedżerów, którzy myśleli, że rewolucja AI jest “techniczna” i ich nie dotyczy. Dotyczy - tyle że wzmacnia dokładnie te kompetencje, które oni już mają.
Po trzecie: to nie jest magia, to jest dźwignia. QuizBase wymagał setek decyzji, dziesiątek iteracji i sporo cierpliwości. AI nie zastąpiło myślenia - zastąpiło żmudne wykonanie, które dotąd to myślenie blokowało.
Jeśli zastanawiasz się, jak ta zmiana dotyczy konkretnie Twojej organizacji - co realnie da się dziś zbudować wewnętrznie, a gdzie zaczyna się ryzyko - to dokładnie temat, który rozkładam na czynniki pierwsze podczas konsultacji i szkoleń z AI dla firm. Produkt to najlepszy dowód, że teoria działa w praktyce.