Nie jestem programistą. Nie skończyłem informatyki i nie zaczynałem tej drogi od kursu języka programowania. Zaczynałem jako człowiek marketingu, który przez lata obserwował ten sam problem: ważny kontekst firmy był rozrzucony między głową właściciela, rozmowami, dokumentami i narzędziami, które nie pamiętały, dlaczego podjęliśmy daną decyzję.
W pewnym momencie przestałem szukać kolejnej aplikacji, która rozwiąże fragment tego problemu. Zacząłem budować własną.
Tak powstał NIENARAZ OS. Od pierwszego pustego projektu do działającego systemu minęło 171 dni. Historia repozytorium pokazuje 5646 commitów na głównej gałęzi i aktywność w 168 z tych 171 dni. Te liczby nie są dowodem kompetencji programistycznej. Są dowodem regularności i tysięcy małych decyzji, które da się podejmować również wtedy, gdy nie zna się całej drogi.
Najpierw znałem problem, dopiero później zacząłem budować
Największą przewagą nieprogramisty nie jest szybkość pisania kodu. Jest nią znajomość problemu od środka.
Przez ponad dziesięć lat pracowałem w marketingu po stronie marek, twórców i firm usługowych. Prowadząc NIENARAZ, widziałem, jak decyzje znikają między spotkaniami, jak nowa osoba ponownie pyta klienta o ten sam kontekst i jak raporty opisują przeszłość, ale nie pomagają zdecydować, co zrobić dalej.
Nie zacząłem więc od pytania: „jaką aplikację mogę zbudować?”. Zacząłem od pytania: „jaki problem wraca tak często, że warto stworzyć dla niego własny mechanizm?”.
To rozróżnienie jest ważne. Narzędzia AI potrafią szybko wygenerować ekran, formularz albo fragment logiki. Nie powiedzą jednak, czy budujesz rzecz istotną. Bez dobrze poznanego problemu można dziś bardzo szybko stworzyć produkt, którego nikt nie potrzebuje.
Co naprawdę znaczy budowanie aplikacji z AI
AI obniża próg wejścia, ale nie usuwa odpowiedzialności. Pomaga tłumaczyć intencję na kod, odnajdywać właściwe pliki, proponować rozwiązania i wykonywać powtarzalną pracę. Dzięki temu osoba bez klasycznego przygotowania technicznego może wejść znacznie dalej niż kilka lat temu.
Nie oznacza to jednak, że wystarczy opisać pomysł w jednym poleceniu i odebrać gotowy produkt.
Każda nowa funkcja rodzi pytania, których AI nie może rozstrzygnąć za właściciela:
AI może przygotować warianty. Odpowiedzialność za wybór nadal należy do człowieka.
Nie musiałem znać całej architektury. Musiałem umieć zawężać problem
Na początku łatwo popaść w dwa skrajne przekonania. Pierwsze mówi: „bez programisty nie mam prawa zaczynać”. Drugie: „AI zbuduje wszystko samo”. Oba prowadzą w złe miejsce.
Pomogła mi trzecia droga: budować możliwie małe fragmenty i za każdym razem domykać pełny obieg. Zamiast projektować cały system w głowie, wybierałem jeden konkretny moment pracy. Co użytkownik widzi? Co robi? Co powinno wydarzyć się później? Skąd wiadomo, że to zadziałało?
To bardziej przypomina projektowanie procesu niż pisanie kodu. I właśnie tutaj doświadczenie biznesowe staje się techniczną przewagą.
Jeżeli potrafisz jasno opisać wejście, decyzję i oczekiwany rezultat, możesz współpracować z AI lub programistą znacznie precyzyjniej. Jeżeli nie potrafisz, znajomość narzędzi nie uratuje produktu.
Działający kod nie oznacza jeszcze działającego produktu
Najważniejsza lekcja przyszła szybko: komunikat „gotowe” nie jest dowodem, że coś jest gotowe.
Kod może się kompilować, a ekran nadal może być nieczytelny na telefonie. Formularz może zapisywać dane, ale ujawniać je niewłaściwej osobie. Funkcja może działać osobno, lecz nie mieć naturalnego miejsca w codziennej pracy. AI może rozwiązać lokalny problem i przy okazji naruszyć wcześniejsze założenie w innym miejscu.
Dlatego wraz z produktem budowałem sposób kontrolowania zmian: mały zakres, osobna gałąź pracy, testy dopasowane do ryzyka, przegląd różnic przed połączeniem i wyraźne oddzielenie zmiany w kodzie od publikacji na produkcji.
Nie trzeba samodzielnie rozumieć każdej linii kodu. Trzeba natomiast wiedzieć, jakiego dowodu oczekuje się przed zaufaniem zmianie.
Pięć zasad, które dały mi najwięcej
1. Zaczynaj od powtarzającego się problemu
Najlepszy pierwszy produkt nie wynika z burzy mózgów. Wynika z problemu, który znasz tak dobrze, że potrafisz podać jego przykłady, wyjątki i koszt.
2. Buduj jeden pełny obieg, nie dziesięć ekranów
Mały proces, który działa od początku do końca, uczy więcej niż rozbudowana makieta. Pozwala też szybciej pokazać produkt prawdziwej osobie.
3. Traktuj AI jak wykonawcę i partnera do myślenia, nie jak właściciela decyzji
Proś o warianty, ryzyka i wyjaśnienia. Nie oddawaj mu decyzji o użytkowniku, zakresie, prywatności ani kryterium ukończenia.
4. Zapisuj zasady pracy
AI jest skuteczniejsze, gdy zna nazwy, granice produktu, styl komunikacji i warunki bezpieczeństwa. Instrukcje nie są biurokracją. Są pamięcią projektu.
5. Regularność wygrywa z technicznym zrywem
Nie zbudowałem systemu jedną idealną sesją. Powstał z codziennego dokładania i sprawdzania małych elementów. Nie trzeba czuć się gotowym do całego projektu. Trzeba być gotowym do następnego możliwego do zweryfikowania kroku.
Czego nie oddałbym AI, nawet gdy stanie się dziesięć razy lepsze
Nie oddałbym mu rozmowy z użytkownikiem, interpretacji napięć w firmie, decyzji o tym, czego nie budować, ani odpowiedzialności za dane i skutki błędu. To właśnie te elementy tworzą produkt.
Kod jest ważny, ale nie jest jedynym tworzywem aplikacji. Drugim jest kontekst. Trzecim — jakość decyzji. Czwartym — zaufanie użytkownika.
Dlatego nie przedstawiam swojej drogi jako historii o tym, że „każdy może być programistą”. Nie każdy musi nim zostać. Znacznie ciekawsza jest możliwość, że osoba z głęboką wiedzą branżową może dziś zamienić ją w działające narzędzie — pod warunkiem, że podejdzie do tego odpowiedzialnie.
Jeśli masz pomysł, nie zaczynaj od wyboru technologii
Zapisz najpierw pięć zdań:
1. Kto ma ten problem? 2. W jakiej konkretnej sytuacji się pojawia? 3. Jak człowiek radzi sobie z nim dzisiaj? 4. Jaki jest najmniejszy obieg, który można poprawić? 5. Po czym poznasz, że rozwiązanie naprawdę pomaga?
To może być początek specyfikacji, rozmowy z programistą albo pierwszej sesji z AI. Przede wszystkim będzie to początek myślenia o produkcie, a nie o samym kodzie.
Ja również nie znałem całej drogi. Znałem problem i potrafiłem wskazać następny ruch. Reszta powstawała — nienaraz.
Szymon Witczak Założyciel NIENARAZ · twórca NIENARAZ OS