Prompting dla nietechnicznych founderów: jak rozmawiać z AI, żeby dostać działający kod

Nie jestem inżynierem z wykształcenia. Buduję produkty — VADYM.AI, Dronehub, Oswin AI — i sporą część prototypów dziś składam sam, z AI. Nie dlatego, że nagle nauczyłem się pisać kod, tylko dlatego, że nauczyłem się stawiać AI zadania tak, żeby na wyjściu był kod, który działa.

I oto, co zrozumiałem przez ten czas: różnica między „AI pisze mi śmieci" a „AI pisze mi działającą aplikację" to prawie nigdy nie kwestia modelu. To kwestia promptu. A dokładniej — tego, jak jasno masz w głowie obraz tego, co chcesz dostać, i jak starannie przekazujesz ten obraz maszynie.

Ten tekst to praktyczny przewodnik dla takich samych founderów jak ja: ludzi z myśleniem produktowym, ale bez inżynierskiego zaplecza. Bez hype'u. Po prostu zasady i szablony, które działają u mnie na co dzień.

Główna zmiana w głowie: jesteś teraz dyrektorem technicznym, a nie wykonawcą

Kiedy nietechniczna osoba pierwszy raz siada do pisania kodu z AI, popełnia zawsze ten sam błąd — pisze zapytanie jak do Google: krótko i mgliście. „Zrób mi wizytówkę." „Napisz skrypt, który zbiera dane."

AI coś wypluje. Ale to „coś" prawie na pewno nie jest tym, co masz w głowie — bo przecież nie powiedziałeś, co masz w głowie.

Właściwa rama jest inna. Wyobraź sobie, że zatrudniłeś bardzo szybkiego, bardzo oczytanego, ale kompletnie niesamodzielnego juniora. Napisze cokolwiek w kilka sekund, ale nie zna Twojego biznesu, nie widzi całości obrazu i nie domyśli się oczywistości. Twoja praca to nie pisanie kodu. Twoja praca to postawić mu zadanie tak, żeby nie zostało miejsca na zgadywanie.

I to jest ten kluczowy nawyk. Nie „znać Pythona". Tylko umieć opisać zadanie.

Zasada 1. Zawsze dawaj kontekst i cel

Najsłabsze prompty to te, w których jest czynność, ale nie ma celu. „Dodaj przycisk" — po co? „Zrób formularz" — w jakim celu, co się z nim stanie dalej?

AI pisze nieporównanie lepiej, kiedy rozumie po co. Cel pozwala mu dobudować szczegóły, o których nie pomyślałeś.

Porównaj:

Zrób formularz rejestracji.

i

Buduję landing dla kursu online. Potrzebuję formularza rejestracji: imię, e-mail, telefon. Po wysłaniu dane mają trafić na mojego maila i pokazać użytkownikowi komunikat „Dziękujemy, jesteśmy w kontakcie". To dla osób nietechnicznych, więc formularz ma być maksymalnie prosty.

W drugim przypadku model zna grupę odbiorców, przeznaczenie, pola i scenariusz po wysłaniu. Podejmie sensowną decyzję tam, gdzie przemilczałeś.

Szablon, którego używam:

Buduję [co to za produkt]. Potrzebuję [konkretne zadanie]. To dla [kto jest użytkownikiem]. Efekt końcowy ma [co ma się stać]. Ważne, żeby [kluczowe ograniczenie].

Zasada 2. Pokazuj przykłady — to najsilniejsza dźwignia

Opis słowami zawsze zostawia dwuznaczność. Przykład — nie. Jeśli możesz pokazać, jak wygląda wejście i jak ma wyglądać wyjście, zrób to. To ucina połowę nieporozumień.

Zamiast „obrabiaj datę po ludzku" — pokaż:

Daty w danych wejściowych wyglądają tak: 2026-06-13. Potrzebuję, żeby na stronie pokazywały się jako 13 czerwca 2026. Oto kolejne przykłady: 2026-01-01 → 1 stycznia 2026, 2026-12-25 → 25 grudnia 2026.

To samo działa dla wszystkiego: formatu tabeli, struktury odpowiedzi, wyglądu komunikatu. Jeden przykład wart jest akapitu wyjaśnień. Trzy przykłady zdejmują niemal wszystkie wątpliwości.

Zasada 3. Proś o plan przed kodem

To chyba najbardziej niedoceniana sztuczka dla osób nietechnicznych. Zanim AI napisze choćby linijkę, poproś, żeby opisał, jak zamierza to zrobić.

Zanim napiszesz kod, opisz plan: jakie pliki utworzysz, co będzie w każdym z nich, jakie kroki. Najpierw chcę uzgodnić podejście.

Dlaczego to krytyczne właśnie dla Ciebie? Bo plan napisany słowami, a nie kodem — możesz go przeczytać i zrozumieć. Jeśli w planie jest już coś dziwnego („podłączę bazę danych", choć Tobie wystarczy prosta strona statyczna), wyłapiesz to zanim model napisze 200 linii w złym kierunku.

Współczesne agenty AI do kodu już to wbudowują. W Claude Code od Anthropic jest na przykład tryb planowania (Plan Mode): agent najpierw bada zadanie i proponuje plan, a dopiero po Twoim zatwierdzeniu zabiera się do pisania. Korzystaj z tego. Uzgodniony plan to umowa, do której można wrócić: „przecież umówiliśmy się, że robimy tak".

Zasada 4. Pracuj iteracjami — małymi krokami

Pokusa nietechnicznego foundera to opisać całą aplikację jedną wielką wiadomością i czekać na gotowy produkt. Przechodziłem przez to. To nie działa.

Wielkie monolityczne zapytanie ma dwa problemy. Po pierwsze: im więcej naraz prosisz, tym większe prawdopodobieństwo, że gdzieś model się pomyli. Po drugie — i to jest najważniejsze — gdy wynik nie działa, nie wiesz gdzie dokładnie. Wszystko zepsute naraz i nie ma od czego zacząć rozplątywania.

Małe kroki wyglądają na wolniejsze, ale w praktyce są szybsze:

1. Najpierw — szkielet strony. Sprawdziłeś: otwiera się?
2. Potem — formularz. Sprawdziłeś: wyświetla się?
3. Potem — wysyłka danych. Sprawdziłeś: mail dochodzi?
4. Potem — komunikat o sukcesie. Sprawdziłeś.

Na każdym kroku masz działający stan, do którego można się cofnąć. Kiedy na kroku 3 coś się psuje, wiesz na pewno: problem jest w wysyłce, a nie gdzie indziej. To jest właśnie dyscyplina inżynierska, tylko bez inżynierskiego wykształcenia.

Sformułowanie do iteracji:

Zróbmy na razie tylko [jeden mały fragment]. Nie dodawaj nic zbędnego. Kiedy sprawdzę, że to działa, przejdziemy do kolejnego kroku.

Zwrot „nie dodawaj nic zbędnego" jest ważny. AI lubi być pomocne i dopisywać to, o co nie prosiłeś. Na etapie prototypu to szkodzi.

Zasada 5. Opisuj dane i ograniczenia wprost

Kod żyje pośród danych. Jeśli nie powiesz, jakie masz dane, AI je sobie wymyśli — i zgadnie błędnie.

Zawsze nazywaj wprost:

• Co na wejściu. „Mam plik Excel, w nim kolumny: Data, Kwota, Klient."
• Co na wyjściu. „Potrzebuję wykresu sprzedaży w podziale na miesiące."
• Ograniczenia. „Plik jest duży, do 50 tysięcy wierszy." „To ma działać w przeglądarce, bez instalowania programów." „Nie chcę płatnych usług."

Ograniczenia to nie drobiazg, to często rzecz najważniejsza. „Zrób bez bazy danych", „tylko darmowe narzędzia", „ma się uruchamiać na moim Macu bez terminala" — każde takie zdanie odcina całą klasę rozwiązań, które Ci nie pasują, i oszczędza godziny.

Zasada 6. Naucz się czytać błędy — i nie bój się ich

Największa bariera psychologiczna dla osoby nietechnicznej to czerwony tekst błędu. Wygląda strasznie, niezrozumiale, chce się zamknąć i uciec.

W rzeczywistości błąd to prezent. To najdokładniejszy kontekst, jaki masz. Maszyna wprost mówi, co poszło nie tak, i często nawet w której linii.

Zasada jest jedna: kopiuj pełną treść błędu do czatu, bez skracania i bez opowiadania własnymi słowami.

Najgorsze, co możesz zrobić:

Nie działa, coś się zepsuło, pomóż.

Najlepsze:

Uruchomiłem kod, który napisałeś, i dostałem ten błąd. Oto on w całości: [wklejasz cały traceback]. Wcześniej zrobiłem [co dokładnie]. Wyjaśnij prostymi słowami, co się stało, i napraw.

Proś o wyjaśnienie prostymi słowami — to osobno przydatne. Stopniowo zaczynasz rozumieć, dlaczego rzeczy się psują, i następnym razem formułujesz zadanie lepiej. Błędy to Twoja darmowa nauka.

Słabe vs silne prompty: tabela

Zasada 7. Wiedz, gdzie jest Twoja granica

Teraz rzecz ważna, o której mało kto mówi szczerze. Prompting daje Ci dużo — ale nie wszystko. Jest strefa, w której nietechniczny founder powinien się zatrzymać i zawołać inżyniera.

Granicę prowadzę tak. Wszystko, co dotyczy prototypu, narzędzia wewnętrznego, dema czy landingu — składaj sam. Cena błędu jest tu prosta: zepsuty prototyp, który po prostu przerobisz.

Ale są rzeczy, gdzie cena błędu jest inna:

• Płatności. Pieniądze użytkowników. Tu błąd kosztuje pieniądze — dosłownie.
• Hasła i logowanie. Jeśli zrobisz to niedbale, konta zostaną przejęte.
• Dane osobowe. Imiona, e-maile, telefony, dokumenty ludzi. To nie tylko etyka, to prawo.
• Infrastruktura produkcyjna. Serwery, na których już pracują realni klienci.
• Wszystko, co jest widoczne publicznie i na dużą skalę.

W tych strefach AI napisze kod, który wygląda na działający. Uruchomi się, a nawet zadziała na Twoich testach. Ale „działa na moim przykładzie" i „bezpieczne dla tysiąca realnych użytkowników" to dwie różne rzeczy, a różnicy między nimi osoba nietechniczna nie zobaczy. Inżynier zobaczy ją w minutę.

To nie słabość. To też nawyk foundera — wiedzieć, gdzie kończą się Twoje kompetencje. Sam składam prototypy z AI, ale płatności i pracę z danymi klientów w poważnych produktach oddaję ludziom, którzy się na tym znają. Prototyp — mój. Produkcja z realnymi pieniędzmi i danymi — zespołowa.

Jak to wygląda w praktyce: jedna sesja

Zbiorę wszystko w całość. Oto jak realnie pracuję, kiedy składam niewielkie narzędzie wewnętrzne:

1. Kontekst i cel. Piszę akapit: co to jest, dla kogo, co ma się stać.
2. Plan. „Najpierw opisz plan, bez kodu." Czytam, zatwierdzam albo poprawiam.
3. Pierwszy krok. „Zrób tylko szkielet." Uruchamiam, sprawdzam.
4. Błąd? Kopiuję pełną treść do czatu. Proszę o wyjaśnienie i naprawę.
5. Kolejny krok. Mały. Sprawdzam. I tak dalej.
6. Granica. Dochodzę do danych użytkowników — zatrzymuję się, wołam inżyniera.

Żadnej magii. Żadnych sekretnych sformułowań. Po prostu dyscyplina: jasność na wejściu, sprawdzanie na każdym kroku, uczciwość wobec własnych granic.

Tej dyscypliny uczę zresztą founderów w polskiej marce KIERUNEK.AI, którą prowadzę razem z Instytutem Kryptografii — bo to ona, a nie kolejny „trik na prompt", odróżnia tych, którzy z AI faktycznie budują, od tych, którzy tylko o tym mówią.

Podsumowanie

Prompting do kodu to nie jest nauka „właściwych słów". To nauka myślenia jak zleceniodawca zadania technicznego: jasno wyobrażać sobie efekt, dawać kontekst, pokazywać przykłady, poruszać się małymi krokami i nie bać się błędów.

Nietechniczny founder może dziś zrobić z AI więcej niż kiedykolwiek. Robię to codziennie. Ale narzędzie jest tak dobre, jak dobre jest zadanie, które mu postawisz. Jasność — to właśnie Twój prawdziwy nawyk. Resztę maszyna dopisze sama.

I na koniec: wiedz, gdzie jest Twoja granica. Umiejętność powiedzenia „tutaj wołam inżyniera" jest tak samo ważna jak umiejętność napisania dobrego promptu. Prototyp składaj sam. Realne pieniądze i realnych ludzi powierzaj tym, którzy się na tym znają.