O czym jest ten film
- Test viralowego repozytorium do inżynierii odwrotnej, które — wedle obietnic — odtwarza dowolną aplikację w kilka minut na podstawie analizy interfejsu, logiki i danych.
- Autor sprawdza metodę na trzech znanych serwisach: Calendly, Typeform i Trello. Za każdym razem wystarczyły zrzut ekranu i jedna instrukcja, a całość powstawała w Base44 (sponsor odcinka).
- Klon Calendly wyszedł z logowaniem przez Google, kalendarzem dostępności, linkiem do 15-minutowych spotkań, walidacją formularzy i automatycznym powiadomieniem e-mail.
- Brakujące funkcje — edycja spotkań, emoji, własne pytania obowiązkowe — doszły po jednym dodatkowym promptem.
- Klon Typeform (nazwany „Ask”) tworzy ankiety z pytaniami zamkniętymi, otwartymi i ocenami w skali 1–10, generuje publiczny link i od razu pokazuje wyniki.
- Klon Trello („Lanes”) ma przeciąganie kart między listami, okładki, checklisty i działające zaproszenia zespołowe wysyłane e-mailem.
- W jednym promptem zmieścił się cały stos technologiczny: interfejs, backend, baza danych, logowania i hosting — a w razie potrzeby także płatności.
- Reguła kciuka: pierwsze podejście odtwarza około 80% rdzenia funkcji; reszta to iteracje — ogranicza już tylko wyobraźnia.
- Czerwona linia prawna: wolno inspirować się funkcjonalnością, nie wolno kopiować kodu, grafik, logotypów ani płatnych funkcji.
- Ramy decyzyjne „budować czy płacić” opierają się na dwóch czynnikach: złożoności narzędzia i wartości własnego czasu — a trend coraz mocniej premiuje własne wersje droższych subskrypcji.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jedna instrukcja i jeden zrzut ekranu potrafią uruchomić pełną aplikację
Na czym polega: klon Calendly powstał z pojedynczego obrazu interfejsu i krótkiej prośby „odtwórz funkcjonalność, zmień nazwę” — i od razu miał logowanie przez Google, kalendarz dostępności, walidację pól i powiadomienia mailowe.
Jak stosować: zanim odnowisz subskrypcję, zrób zrzut ekranu kluczowej funkcji narzędzia i poproś platformę typu Base44 o wersję pod własną nazwą, z zachowaniem rdzenia działań.
Na co uważać: pierwszy wynik to zwykle ok. 80% funkcji — resztę trzeba dopisywać kolejnymi komunikatami i na bieżąco testować.
2.Nie składaj backendu ręcznie — wybierz platformę, która zrobi to za ciebie
Na czym polega: największą ulgą w testach okazało się, że bazy danych, logowania, integracje i hosting konfigurowały się same; ręczne „łączenie rur” było dotąd prawdziwą zmorą takich projektów.
Jak stosować: buduj w środowisku, które samo prowadzi backend; przy bardziej złożonych projektach korzystaj z trybu planowania i publikuj najpierw jako prywatne.
Na co uważać: wygoda oznacza uzależnienie od jednej platformy, a w filmie jest ona sponsorem — potraktuj zachętę z dystansem i sprawdź limity oraz koszty.
3.Pierwsze podejście daje ok. 80% — resztę dokładasz iteracjami
Na czym polega: pojedyncza instrukcja odtworzyła rdzeń każdego z trzech serwisów, a detale (edycja spotkań, tryb podglądu, nowe typy pytań) dochodziły po jednym dodatkowym promptem.
Jak stosować: po pierwszej generacji wejdź w aplikację jak użytkownik, spisz czego brakuje i dorzucaj każdą rzecz osobną, konkretną prośbą.
Na co uważać: nie wszystko wychodzi od razu — np. rozciągnięta okładka karty w klonie Trella; drobne wpadki stylistyczne trzeba poprawiać ręcznie.
4.Zanim zaczniesz, przejdź oryginał jak użytkownik i spisz listę funkcji
Na czym polega: metoda pokazana w filmie to: obejrzeć aplikację oczami użytkownika, zapisać co robi, zbudować odpowiednik od zera i opatrzyć go własną marką.
Jak stosować: przeklikaj oryginalny produkt i wypisz funkcje, których realnie używasz (typy pytań, zbieranie wyników, udostępnianie) — to lista stanie się specyfikacją dla AI.
Na co uważać: klonowanie 100% funkcji rzadko ma sens; celuj w te 80%, które naprawdę wykorzystujesz.
5.Testuj klon obok oryginału i domykaj całe procesy
Na czym polega: autor sprawdzał rezerwację od kliknięcia w link, przez formularz, aż po e-mail z potwierdzeniem; w klonie Trella zaproszenie e-mailem faktycznie przyszło i nowe konto dołączyło do tablicy.
Jak stosować: po każdym etapie otwieraj aplikację w nowym oknie i przechodź cały proces jako klient — końcem w końcem, nie tylko sam interfejs.
Na co uważać: ładny ekran to nie to samo co działająca usługa — weryfikuj powiadomienia, uprawnienia i współdzielenie.
6.Dedykowany moduł (skill) pracuje szybciej niż zwykły czat
Na czym polega: całe repozytorium to 420 tysięcy linii TypeScriptu, z których 789 tworzy wydzieloną umiejętność inżynierii odwrotnej; w testach wypadała ona szybciej niż te same zadania w zwykłym Claude czy ChatGPT.
Jak stosować: jeśli często odtwarzasz funkcjonalności, korzystaj z gotowego, wypraskanego prompta (link w opisie filmu) zamiast układać własny od zera.
Na co uważać: „szybciej” nie znaczy „nieomylnie” — wyniki nadal wymagają weryfikacji i pilnowania granic prawnych.
7.Największy błąd: kopiowanie zamiast budowania po swojemu
Na czym polega: autor wyraźnie odcina się od przejmowania cudzego kodu, grafik, logotypów i płatnych funkcji; między inspiracją a kopiuj-wklej biegnie wyraźna granica.
Jak stosować: opisuj AI „co” ma robić aplikacja, a nie „co ma skopiować”; własna nazwa i marka są warunkiem — w testach klony nazywały się inaczej niż oryginały (Ask, Lanes).
Na co uważać: sama zmiana nazwy nie usprawiedliwia przejęcia cudzego interfejsu jeden w jeden; ryzyko prawne rośnie wraz z upowszechnianiem kopii.
8.Zamiast „skopiuj ten serwis” dawaj listę funkcji i wzorce stylistyczne
Na czym polega: najlepszy sposób na dobre wyniki to instrukcja w stylu „zbuduj aplikację, która robi A, B, C, D, E, F, G”, uzupełniona o listę funkcji i inspiracje wizualne.
Jak stosować: zamiast wręczać AI produkt do skopiowania, podaj specyfikację funkcjonalną plus kilka ładnych przykładów interfejsu jako wskazówkę stylistyczną.
Na co uważać: im dokładniejsza lista, tym mniej rund poprawek — warto spędzić chwilę na jej ułożeniu przed startem.
9.Budować czy płacić? Rozstrzygają dwa czynniki
Na czym polega: decyzję wyznacza złożoność i trudność zastąpienia narzędzia oraz wartość twojego czasu; przy 200–1000 dolarów miesięcznie i budowie w dzień–dwa własna wersja się broni, przy tanich abonamentach i długiej budowie — niekoniecznie.
Jak stosować: policz roczny koszt subskrypcji, oszacuj czas budowy i porównaj obie kwoty — pamiętając, że nie masz za plecami zespołu programistów.
Na co uważać: do rachunku dolicz utrzymanie, aktualizacje i bezpieczeństwo, które przy produkcie komercyjnym zapewnia dostawca.
10.Własność intelektualna przestaje być fosą — wyciągnij wnioski
Na czym polega: autor cytuje głosy z rynku, że przewaga oparta na własności intelektualnej — tak zwana fosa — przestaje chronić firmy (stąd panika w Adobe), bo funkcjonalność da się dziś odtworzyć jednym promptem.
Jak stosować: jeśli sprzedajesz oprogramowanie, nie zakładaj, że sama funkcjonalność obroni produkt; jeśli jesteś po stronie kupującej, coraz częściej opłaca się wersja własna.
Na co uważać: to wciąż opinie z wiru hype’u — realny horyzont tych zmian bywa dłuższy, niż sugerują viralowe demonstracje.
Redakcyjne tłumaczenie
Obietnica: trzy aplikacje wyceniane na miliardy, zbudowane w kilka minut
Inżynieria odwrotna to najnowsze viralowe narzędzie, które — jeśli wierzyć obietnicom — klonuje dowolną aplikację w kilka minut, oszczędzając wam setki dolarów i pomagając zarabiać. Postanowiłem to sprawdzić na własnej skórze, a w tym odcinku zbudujemy trzy programy o łącznej wycenie liczonej w miliardach dolarów — i to w kilkanaście minut. Po drodze zobaczycie, jak z tego korzystać, na co naprawdę stać dzisiejsze AI oraz jaki błąd powstrzymuje większość ludzi przed skorzystaniem z tej fali. Zaparzcie więc kawę i zaczynamy.
Dlaczego pół internetu mówi tylko o tym
Od premiery projektu ludzie pół żartem, pół serio wysyłają paczki chusteczek do centrali Adobe — bo to właśnie ona będzie ich teraz najbardziej potrzebować. Na YouTube i X roi się od materiałów, w których ktoś odtwarza za pomocą AI praktycznie dowolny program: Photoshopa, After Effects i całą listę kolejnych znanych nazw. I od razu pytanie: ile w tym prawdy? Zanim nagrałem odcinek, sprawdziłem metodę na zamiennikach Photoshopa i Premiere Pro — i powiem szczerze, byłem zaskoczony. Działa naprawdę dobrze.
Co właściwie siedzi pod maską
Zanim coś zbudujemy, trzeba rozumieć, jak narzędzie pracuje. Sama idea jest prosta: system przygląda się interfejsowi, potem logice działania, na końcu danym — i z tych trzech elementów składa całość od nowa. O skali najlepiej świadczą przykłady: jeden użytkownik odtworzył Terrarię w trójwymiarze, ktoś incy zrobił odpowiednik całej gry o Człowieku-Pająku. Ale nie gry są tu najciekawsze. Najważniejszy jest dla mnie serwis, za który płacicie krocie — przeciętny użytkownik zostawia na subskrypcjach około 219 dolarów. Sprawdźmy więc, czy da się je po prostu skreślić z listy wydatków.
Zrobię to na trzech narzędziach: Calendly, Typeform i Trello. (Informacja dodatkowa: Calendly to popularny system umawiania spotkań, Typeform — kreator formularzy i ankiet, a Trello — tablice kanban do zarządzania zadaniami.) Całość zbudujemy w Base44, które zajmie się backendem i integracjami — i tu uczciwe wyznanie: to sponsor dzisiejszego odcinka.
Szczegół, który wyszedł w testach
Po wielu godzinach zabawy natrafiłem na coś, co nazwałbym kontrowersyjnym. Cały projekt to 420 tysięcy linii TypeScriptu, z których zaledwie 789 tworzy wydzieloną umiejętność (tzw. skill) odpowiedzialną za inżynierię odwrotną. Kiedy porówna się to z próbą wyciśnięcia tych samych efektów z „gołego” Claude’a albo ChatGPT, okazuje się, że ten niewielki wycinek pracuje szybciej. Prompt, którego sam używam, zostawiam pod filmem.
Warsztat: jeden zrzut ekranu i kilka zdań
Sama praca wygląda tak. Siadam przy Base44, bo wystarczy tam wrzucić zrzut ekranu i krótki opis, a platforma sama podłącza backend, integracje i wszystko po drodze — ja nie ruszam żadnej śrubki. (Informacja dodatkowa: Base44 to platforma typu „vibe coding” — aplikacje powstają tam na podstawie opisu słownego, a backend i hosting zakładają się automatycznie.)
Robię więc zrzut ekranu Calendly, poklikam chwilę po interfejsie i przenoszę obraz do Base44. Cała instrukcja ma dosłownie kilka zdań: „Odtwórz dla mnie na podstawie zrzutu ekranu Calendly — system rezerwacji. Nadaj mu inną nazwę, ale chcę całą kluczową funkcjonalność”. Klikam „buduj”. Dla bardziej złożonych projektów jest też tryb planowania, w którym najpierw rozpisujemy założenia — bardzo się przydaje. Backend, bazy danych i cała reszta dzieją się przy okazji same.
Calendly: system rezerwacji za pierwszym podejściem
Podczas budowania system myśli na głos, a gdy czegoś mu brakuje, po prostu dopytuje. Wyszedł z tego kompletny produkt, więc publikuję go i otwieram w nowym oknie, żeby przetestować jak zwykły użytkownik. Od progu jest ekran logowania — wchodzę kontem Google i trafiam do panelu. I tu pierwsze, szczere wrażenie: po prawej stronie mam dostępność rozpisaną na dni, którą mogę włączać i wyłączać. Ustalam więc, że pracuję tylko w poniedziałki i niedziele, pozostałe dni kasuję, i otwieram kalendarz na 15-minutowe spotkania. Podkreślam: wszystko to powstało za pierwszym razem, jednym podejściem. Zapisuję godziny, klikam link do 15-minutowego spotkania i… otwieram obok prawdziwe Calendly, żeby porównać. Przechodzę dalej: imię, adres e-mail — i Base44 z własnej inicjatywy dorzuciło walidację pól. Potwierdzam rezerwację i gotowe. A potem niespodzianka: system sam skonfigurował powiadomienie, które przyszło mi na skrzynkę. Mamy więc nie tylko odtworzony interfejs, ale działający, dynamiczny system rezerwacji podpięty pod moje konto Google. Nie spodziewałem się, że z jednej instrukcji wyjdzie aż tyle.
Druga tura promptów: edycja spotkań i własne pytania
Rdzeń działa, ale sekcji edycji brak. Wrzucam więc kolejną prośbę: „Chciałbym edytować informacje o swoich spotkaniach — dodawać emoji i własne pytania w trakcie ich tworzenia”. I tak się to toczy: wracasz, prosisz, poprawiasz. Można zresztą od razu wypisać pełną listę wymagań — lepiej wszystko ustalić przed startem niż poprawiać po fakcie. Po chwili w aplikacji pojawia się przycisk edycji: dopisuję opis, emoji i pytanie „Jaki jest twój roczny przychód?”, które oznaczam jako obowiązkowe. Zapisuję spotkanie i otwieram link: rezerwujący widzi dokładnie to, co ustaliłem, a odpowiedzi przychodzą do mnie mailem. W ten sposób odzyskujecie od ręki te 10–20 dolarów, które zostawialibyście na subskrypcji.
Jeżeli w tym miejscu czujecie, że gubicie wątek — pod filmem zostawiam link do mojego pełnego kursu o pracy z Claude i agentami: od zera do własnych aplikacji, stron i systemów pamięci, wraz z moimi gotowymi zestawami narzędzi i sposobem na łączenie tego wszystkiego w jedną spójną całość.
Typeform: klon o imieniu Ask
Drugi egzamin: Typeform. Formularzy używa się wszędzie, a sam płacę za tego typu narzędzie od lat — testowałem i polecałem zarówno Typeform, jak i Paperform. Ten test zapowiadał się trudniej. Znów kopiuję instrukcję z dokumentu w Notion (link pod filmem — budujcie razem ze mną: wybierzcie dowolny serwis, za który dziś płacicie, i sprawdźcie, czy uda się go odtworzyć jednym promptem), dołączam zrzut ekranu i piszę: „Zbuduj mi na podstawie zrzutu wersję Typeforma. Chcę mieć możliwość tworzenia formularzy, żeby móc wyłączyć subskrypcję i przestać za nią płacić. Nadaj mu oczywiście inną nazwę i trochę własnego charakteru”.
Najpierw pobawiłem się oryginałem: zakładam konto, odpalam szablon — to beżowe tło osobiście nie jest mi w smak, ale widać, jak to działa: po lewej listy pytań o sobie, klikasz, przechodzisz dalej. Typowe Typeform, firma z końskim sukcesem — ideę znacie. A teraz zobaczcie, co zrobiło Base44.
Publikuję projekt jako prywatny, bo nie chcę wypuszczać go w świat. Przy okazji: można wybrać wersję mobilną, a nawet podpiąć własną domenę, dzięki czemu narzędzie wygląda profesjonalnie. Program nazwał się Ask i — mówiąc szczerze — interfejs ma naprawdę elegancki. Loguję się przez Google i to jest największa ulga w pracy z Base44: nie muszę robić żadnego „instalowania rur”. Bazy danych, uprawnienia, konfiguracja poczty — kiedyś była to prawdziwa zmora takich projektów, teraz dzieje się samo.
Zaczynam od ekranu powitalnego — na potrzeby testu niech to będzie Wielki Kwestionariusz Kawowy — i dodaję pytanie jednokrotnego wyboru: „Ile kaw pijesz dziennie?” z opcjami od zera wzwyż. Potem krótkie pole tekstowe i skala od 1 do 10: „Jak dobra jest kawa?”. Zapisuję, zmieniam kolejność pytań, klikam „udostępnij” i dostaję publiczny link. Otwieram go w nowej karcie, przechodzę przez całą ankietę — więcej niż trzy kawy, ocena osiem na dziesięć — i finito. Wchodzę w wyniki: odpowiedzi są tam od razu. To robi na mnie wrażenie, bo za narzędzia do formularzy łatwo zostawić 400 dolarów, a tu jeden prompt, jeden link i jestem gotowy.
Zasada 80% i czasy projektantów
I tu pierwsza poważna uwaga: jak przy każdym AI, rozstrzyga głębia i złożoność. Odtworzyłem to, co nazwałbym osiemdziesięcioma procentami — tworzenie pytań, różne ich typy, zbieranie wyników, udostępnianie. Na stronie Typeforma jest więcej: sekcja projektowania, optymalizacja pod telefony i tak dalej. Ale każdy z tych elementów dzieli mnie od jednego prompta. Chcecie podgląd? Proszę bardzo: „dodaj tryb podglądu i jeszcze jeden typ pytania” — i po chwili mam pytania tak/nie oraz podgląd odpalany przyciskiem play. Wniosek: ogranicza was już tylko wyobraźnia. Oficjalnie weszliśmy w erę projektantów — co potraficie wymyślić i opisać, to zbudujecie. To złoty czas na budowanie czegokolwiek i naprawdę w to wierzę. W chaosie jest okazja — chaos to drabina. (Informacja dodatkowa: nawiązanie do serialu „Gra o tron”, w którym chaos zostaje nazwany drabiną — szansą dla tych, którzy potrafią się po niej wspinać.)
Zdaję sobie sprawę, że prawnicy od własności intelektualnej będą mieli w tym roku najlepsze premie w życiu, bo firmy patrzą na te dema i pytają, co się tu w ogóle dzieje — wszyscy budują świetne oprogramowanie. O tym za chwilę, bo to kluczowe. Sedno jest takie: nie musicie już umieć kodować ani siedzieć po nocach zamknięci z laptopem i sześcioma puszkami Red Bulla. Mówicie do AI — AI buduje.
Trello, czyli Lanes
Trzeci poziom: Trello. Firma bardzo wysoko wyceniana, a zasada działania banalnie prosta: przeciągasz kartę między listami, klikasz w nią, zaglądasz w szczegóły. Kopiuję instrukcję z Notion, wrzucam do Base44 i patrzę, co wyszło. Porównajcie sami. Program nazwał się Lanes; loguję się przez Google — przyznam, że samo w sobie jest wygodne, iż logowanie działa od razu — i otwieram tablicę demo. I tu rzecz, która mnie rozbawiła: skoro na zrzucie w tle były zielone liście, klon też ma zielone liście. Narzędzie trzyma się każdego szczegółu. Przeciąganie kart działa bez zarzutu, więc dodaję własną: „Pogłaskać Dextera” — tak ma na imię mój springer spaniel — dorzucam okładkę i zapisuję: „Dexter musi dostawać głaski codziennie”. Przyznam, okładka rozciągnęła mi się trochę za mocno. Drobnych poprawek będzie trzeba dokładać — nie żyjemy jeszcze w czasach, gdy wszystko wychodzi za pierwszym podejściem — ale z każdą rundą jest bliżej. Checklisty działają: dodaję punkt „Czy się uśmiecha?”. Przycisku zapisu nie widać, ale po wyjściu z karty wszystko zostaje na miejscu. Przesuwam zadanie do kolumny „zrobione” i mam pełnoprawną aplikację. No dobrze — a współpraca? Klikam link zaproszenia i wpisuję własny adres e-mail. I uwierzcie albo nie: dostaję zaproszenie od Lanes do dołączenia jako użytkownik. Otwieram, jestem w środku, na tablicy widzę już dwóch członków — serwis żyje.
Policzmy, co właśnie zrobiliśmy
Zatrzymajcie się na sekundę. Jednym promptem — jednym! — zbudowaliśmy interfejs, backend, bazę danych, logowania i hosting, a gdybyśmy chcieli, dołożylibyśmy płatności. To pokazuje siłę całej strategii: popatrzeć na produkt jak użytkownik, spisać, co robi, zbudować odpowiednik od zera i opatrzyć go własną marką.
Jedna rzecz, której nie wolno robić
I tu dochodzimy do najważniejszego zastrzeżenia — tego błędu, który powstrzymuje większość ludzi. Nie kopiujcie cudzego kodu. Nie kopiujcie cudzych grafik, logotypów ani płatnych funkcji. Między wzięciem inspiracji a kopiuj-wklej biegnie wyraźna granica i tej drugiej strony nie wolno przekraczać — nie można po prostu przenosić elementów z cudzych serwisów i stron do własnych.
Budować samemu czy dalej płacić?
Skoro tak, to kiedy opłaca się własna wersja, a kiedy abonament? Skoro AI robi się tańsze i sprawniejsze, coraz częściej bardziej opłaca się budowa niż płacenie — ale nie zawsze. Rozstrzygają dwie rzeczy. Po pierwsze: jak złożony jest program i jak trudno go zastąpić. Po drugie: ile jest warta wasza godzina. Jeśli zostawiacie na jakimś serwisie 200 albo 1000 dolarów miesięcznie, a AI zbuduje wam w dzień–dwa lepszą wersję — to rozmowa, którą warto przeprowadzić. Jeśli natomiast subskrypcja kosztuje 20–100 dolarów, a odtworzenie zajmie dużo czasu, sprawa się komplikuje — zwłaszcza że nie macie za plecami zespołu ekspertów budującego i rozwijającego wszystko na bieżąco. Te rachunki każdy musi policzyć sam. Tendencja jest jednak jednoznaczna: własne oprogramowanie robi się coraz bardziej opłacalne. Stąd panika w Adobe i coraz głośniejsze głosy, że własność intelektualna — ta sławna fosa wokół biznesu — przestaje istnieć.
Jak budować dobrze
Powtórzę, bo to kluczowe: nie kopiujcie cudzych aplikacji. Ani kodu źródłowego, ani obrazów — niczego nie ściągajcie i nie zabierajcie na siłę. Budujcie rzeczy oryginalnie. Najlepszy sposób, jaki znam, to najpierw zrozumieć funkcjonalność: co dane narzędzie ma właściwie robić? I dopiero potem zbudować to pod własną marką, z własnym charakterem. Nie wręczajcie AI produktu ze słowami „skopiuj to”. Powiedzcie zamiast tego: „zbuduj mi aplikację, która robi A, B, C, D, E, F i G”, podajcie listę funkcji i dorzućcie kilka ładnych wzorców interfejsu jako inspirację. To wyniesie wyniki na zupełnie inny poziom.
Na koniec
Zostaje jedno pytanie: skąd wziąć ten piękny interfejs, który wygląda bajecznie i zamienia oglądających w kupujących? Akurat rozłożyłem to na czynniki pierwsze — razem z rzeczami, których nigdzie indziej nie słyszałem — w filmie, którego miniaturę widzicie obok. Zaparzcie kawę i do zobaczenia tam.