O czym jest ten film
- REA to repozytorium narzędzi do inżynierii wstecznej dla agentów AI, które w trzy dni przeszło drogę od 70 tysięcy do ponad 220 tysięcy gwiazdek na GitHubie.
- Z technicznego punktu widzenia to serwer MCP: agent skanuje gotową aplikację, sporządza listę tego, co dostaje użytkownik, i tłumaczy z dowodami, jak działa każda funkcja.
- Twórcy podkreślają etykę: narzędzie nie kopiuje kodu ani designu – opisuje jedynie działanie, a nowa aplikacja powstaje od zera.
- Autor przetestował cały proces na aplikacji Klop (licencja GPL) i w około 40 minut uzyskał działający klon „Zgniotek” – 224 linijki Swifta.
- Rachunek w API: 6,54 dolara za analizę (z tego 1,10 dolara pochłania sam załadunek 170 narzędzi REA, czyli ok. 110 tysięcy tokenów), a cała sesja z budowaniem – około 15 dolarów.
- Drugi projekt, Bassgrow, to własna wersja Excalidraw zbudowana od zera i opublikowana w internecie przez wtyczkę Hostinger obsługiwaną z poziomu rozmowy z Claude’em.
- Trzeci przypadek to mody do Slay the Spire 2 – nowa karta i tryb draftu talii – powstałe głównie dzięki Claude’owi i otwartym szablonom społeczności, niemal bez udziału REA.
- Czwarty przypadek, widget „Limitomierz” do OBS, pokazuje granice narzędzia: dekompilator przeciążył komputer, a własna instrukcja dla agenta okazała się skuteczniejsza.
- Główny wniosek autora: żeby zbudować własną wersję czegokolwiek bez kradzieży cudzego kodu, REA nie jest potrzebna – wystarczy metoda i rozmowa z odpowiednim agentem.
- Z oryginału bierze się wiedzę o tym, jak coś działa – nigdy kod, nazwę ani wygląd.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Mierz, zamiast zgadywać
Na czym polega: Sednem inżynierii wstecznej z agentem AI nie jest „klonowanie”, tylko zbieranie faktów z dowodami: najpierw opis działania oryginału, dopiero potem nowy kod.
Jak stosować: Zamiast prosić agenta, żeby „zrobił coś podobnego”, każ mu najpierw rozpisać, jak oryginał działa krok po kroku, a budowę zacząć dopiero na podstawie takiego raportu.
Na co uważać: Raport bez odwołań do konkretnych miejsc w kodzie to zgadywanie w przebraniu. Żądaj identyfikatorów dowodów przy każdym fakcie.
2.Pracuj wyłącznie na kopii
Na czym polega: Agent dostaje kopię aplikacji w osobnym folderze i na niej wykonuje całą analizę – oryginał nie jest uruchamiany ani modyfikowany.
Jak stosować: Zanim polecisz agentowi jakąkolwiek analizę, skopiuj pliki do wydzielonego katalogu i wyraźnie zaznacz w prompcie, że pracuje na kopii.
Na co uważać: Bez takiej zasady agent może namieszać w oryginalnej instalacji albo w jej ustawieniach, a przy aplikacjach, z których korzystasz na co dzień, będzie to bolesne.
3.Prosty prompt wystarcza na start
Na czym polega: Autor wystartował krótkim, potocznym poleceniem („użyj REA, przyjrzyj się Klopowi…”) – agent sam załadował podręcznik procedur narzędzia i rozpisał zadanie na osiem konkretnych pytań.
Jak stosować: Nie spędzaj godzin nad idealnym promptem. Napisz, co chcesz wiedzieć i co chcesz zbudować, a dalszą dekompozycję zostaw agentowi.
Na co uważać: Prostota promptu nie zwalnia z nadzoru – warto przejrzeć wygenerowaną listę pytań i doprecyzować te, które idą w złą stronę.
4.Etykiety „widzę / wnioskuję / nie wiem” porządkują wiedzę
Na czym polega: Każda odpowiedź w raporcie dostaje etykietę: fakt zaobserwowany, wniosek z przesłanek albo otwarta niewiadoma.
Jak stosować: Wprowadź taki podział we własnych analizach z agentem – od razu widać, co jest pewne, a co wymaga twojej decyzji albo dalszego badania.
Na co uważać: Bez etykiet łatwo wziąć wniosek agenta za fakt. Każde „nie wiem” to sygnał, że dany fragment musisz zweryfikować sam lub zaakceptować ryzyko.
5.Pilnuj kosztu kontekstu
Na czym polega: Samo załadowanie 170 narzędzi REA zajmuje około 110 tysięcy tokenów kontekstu i kosztowało 1,10 dolara – zanim cokolwiek zostało zrobione.
Jak stosować: Przy rozliczaniu po API wliczaj koszt startu sesji w each projekcie; w abonamencie pamiętaj, że takie narzędzia zjadają limit szybciej, niż się wydaje.
Na co uważać: Sesja, która ma być tania, może zacząć się od sporego rachunku za sam „bagaż” narzędzi. Przy małych zadaniach rozważ lżejsze podejście.
6.Sprawdzaj licencje i trzymaj się etykiety procesu
Na czym polega: Autor wybierał aplikacje na licencjach GPL i MIT, analizował zbudowane paczki, a nie repozytoria, i z oryginału czerpał wyłącznie wiedzę o działaniu – nie kod, nazwę ani wygląd.
Jak stosować: Zanim zaglądniesz do środka programu, upewnij się, że licencja na to pozwala; nową wersję buduj od zera, z własnym designem i nazwą.
Na co uważać: Przy takiej popularności REA pojawiła się masa podróbek repozytorium – pobieraj wyłącznie z oficjalnego źródła. Granica między inspiracją a kopiowaniem bywa cienka i to ty za nią odpowiadasz.
7.Szum w analizie trzeba wycinać ręcznie
Na czym polega: W pierwszym podejściu do Excalidraw pliki z tłumaczeniami „zjadły” cały wynik, a najważniejszy plik pozostał bez analizy – REA sama nie rozpozna, co jest śmieciem.
Jak stosować: Po nieudanym przebiegu zawęź cel: wskaż agentowi, które pliki lub elementy pominąć, i powtórz analizę.
Na co uważać: Nie każdej porażce winne jest narzędzie – czasem wystarczy przyciąć zakres i wszystko rusza. Automat nie zastąpi twojej oceny, co jest istotne.
8.Weryfikuj znaleziska u źródła
Na czym polega: Po zmapowaniu Excalidraw autor porównał wyniki REA z oficjalnym repozytorium – każda sprawdzona funkcja okazała się dokładnie tam, gdzie wskazywała analiza.
Jak stosować: Gdy oryginał ma otwarte źródła, użyj ich jako kontrolnego zestawu referencyjnego dla raportu agenta.
Na co uważać: Weryfikacja na próbce nie gwarantuje całości – sprawdzaj przynajmniej funkcje krytyczne dla twojego projektu.
9.Ciężkie binarki potrafią położyć narzędzie
Na czym polega: Przy analizie OBS dekompilator Ghidra dwa razy przekroczył limit czasu, mocno obciążył procesor, a po ponad 50 minutach mielenia pokrycie kluczowych faktów wyniosło zaledwie 23 procent.
Jak stosować: Przy dużych, skomplikowanych programach testuj najpierw na fragmencie i obserwuj obciążenie sprzętu; jeśli narzędzie się dławi, zmień podejście.
Na co uważać: Nie każde zadanie wymaga ciężkiej artylerii. Ten sam efekt często daje zwykła instrukcja dla agenta – autor uzyskał działający widget bez REA.
10.REA nie jest niezbędna – metoda wystarczy
Na czym polega: W modach do Slay the Spire 2 i w widżecie do OBS większość pracy odrobił sam agent na szablonach, otwartych bibliotekach i własnej instrukcji; REA grała rolę drugoplanową albo żadną.
Jak stosować: Zanim sięgniesz po nowe narzędzie, spróbuj najpierw z samym agentem i dobrze napisaną instrukcją – często to wystarczy.
Na co uważać: „Wiral na GitHubie” nie jest automatycznie właściwym narzędziem do twojego zadania. Dopasuj metodę do problemu, a nie do hype’u.
Redakcyjne tłumaczenie
(Informacja dodatkowa: transkrypt automatyczny przekręca nazwy własne – m.in. „Girda” zamiast Ghidra, „Excalidrow” zamiast Excalidraw czy „clot code” zamiast Claude Code. W tekście przywrócono poprawne wersje tam, gdzie to pewne.)
Trzy dni od 70 tysięcy do 220 tysięcy gwiazdek
W światku narzędzi dla agentów AI pojawiło się repozytorium, które błyskawicznie podbiło GitHuba. Dwa dni temu miało nieco ponad 70 tysięcy gwiazdek – już to uczciwy wynik. Wczoraj licznik przekroczył 100 tysięcy, dziś pokazuje ponad 220 tysięcy. Mowa o REA, czyli – rozwijając skrót – agencie do inżynierii wstecznej.
W dużym uproszczeniu to zbiór gotowych narzędzi dla agentów takich jak Claude Code, dzięki którym mogą one rozbierać skończone aplikacje na części pierwsze. Techniczniej: serwer MCP – wtyczka podłączająca do agenta zewnętrzne narzędzia. Agent dostaje możliwość przeskanowania programu, sporządzenia listy tego, co faktycznie otrzymuje użytkownik, a następnie wyjaśnienia – z dowodami w ręku – jak działa dana funkcja.
Twórcy uprzedzają pytania: to nie jest „chamska kopiarka”. Agent nie wyjmuje cudzego kodu ani cudzego designu. REA opisuje jedynie, jak coś działa, a całą resztę agent tworzy od zera – i według autora to jest klucz do całej sprawy. Przy takiej popularności narosła już masa podróbek, więc łatwo trafić na fałszywkę; link do właściwego repozytorium znajdziemy w opisie filmu.
Autor, jak sam przyznaje, przepalił spory kawał swojego limitu tokenów, żeby sprawdzić, co narzędzie naprawdę potrafi. Poniżej relacja z czterech testów.
Klop pod lupą: przedmiot pierwszego testu
Na warsztat poszła aplikacja, z której autor korzysta codziennie: Klop na macOS. Program mieszka w pasku menu i odchudza obrazki oraz pliki wideo – po kompresji nadają się do wysłania mailem czy wrzucenia do mediów społecznościowych, nie tracąc zbytnio na jakości. Dodatkowo w prawym dolnym rogu ekranu jest „drop zone”, czyli strefa, w którą przeciąga się pliki i one od razu zmniejszają swój rozmiar. Źródła Klopa są otwarte (licencja GPL), więc zaglądanie do środka jest w pełni legalne.
Zasada na start: agent dostaje kopię aplikacji w osobnym folderze. Oryginał nie jest uruchamiany ani dotykany – cała praca toczy się wyłącznie na skopiowanych plikach.
Cztery etapy: od promptu do „Zgniotka”
Etap 1: prompt i lista pytań
Wysyła się polecenie: wskazujesz agentowi aplikację i mówisz, co chcesz wiedzieć. Agent sam ładuje podręcznik procedur REA, rozpisuje pytania na listę i obiecuje, że każda odpowiedź dostanie etykietę: „widzę”, „wnioskuję” albo „nie wiem”. Sam prompt autora był skromny: „Użyj REA, przyjrzyj się Klopowi. Kopia w folderze. Jak wykrywa obrazek w schowku, czym kompresuje, jak decyduje o jakości, jak podmienia wynik? Skróty, Finder – chcemy własną wersję od zera”. W konfiguracji jako orkiestrator pracował model Fable 5.1, a właściwą analizę wykonał Opus 5.5, oba na średnim poziomie wysiłku. Po około pół minuty lista liczyła osiem pytań – bez ani jednego wywołania REA, bo ten krok to dopiero rozruch.
Etap 2: mapa aplikacji
Następnie REA zajęła się sporządzeniem mapy. Każdy komponent Klopa trafił do właściwego silnika – dekompilatora Ghidra – a na wyjściu powstała gotowa mapa: pliki, napisy, importy, kto co wywołuje. (Informacja dodatkowa: Ghidra to otwartoźródłowy dekompilator, pierwotnie stworzony przez NSA, służący do analizy skompilowanych programów.) Wynik to paczka 65 elementów: główna binarka 8,7 MB, moduł raportowania błędów, rozszerzenie Findera, osobne interfejs wiersza poleceń oraz zbiór zewnętrznych narzędzi ważący 85 MB – dane dla technicznych entuzjastów. Do tego informacja, że aplikacja żyje wyłącznie w pasku menu, bez ikony w doku. Etap zajął około 16 minut i 10 wywołań REA.
Etap 3: śledztwo, czyli pętla małych pytań
Trzeci etap autor nazywa śledztwem. Claude zadaje pytania, REA odpowiada faktem wraz z „paragonem” – identyfikatorem dowodu. Tam, gdzie narzędzie sobie nie radziło, Claude czytał kod sam, a całość zamknęła się raportem z etykietami. Co ustalono wraz z dowodami: pętlę schowka, pomijanie własnego wyniku przez znacznik, pomijanie haseł z menedżerów, korzystanie z zewnętrznych programów do kompresji – Ghostscript dla PDF-ów, ExifTool dla metadanych, FFmpeg dla wideo – skróty zarejestrowane przez bibliotekę Magnet oraz fakt, że rozszerzenie Findera komunikuje się z aplikacją przez porty Mach. Czego REA nie ustaliła: zawartości paczek narzędzi, interwału odpytywania schowka i liczb decydujących o jakości. Powód jest ciekawy – Swift chowa krótkie napisy w instrukcjach procesora, a nie w sekcji tekstowej, więc wyszukiwarka napisów ich po prostu nie widzi. Brakujące liczby Claude dopisał z repozytorium. Ten etap trwał około 7,5 minuty: 31 wywołań REA i osiem własnych kroków agenta.
Etap 4: zbuduj własne
Na koniec Claude pisze nowy kod – na podstawie raportu, nie pseudokodu oryginału. Odpowiedzi stają się planem, a każde „nie wiem” zamienia się w decyzję do podjęcia. Efekt: aplikacja wzorowana na Klopie, nazwana przez agenta „Zgniotkiem”. Działa w pasku menu i ma własną strefę upuszczania, a całość to 224 linijki Swifta. Test na żywo: grafika PNG ważąca 4,5 MB po przeciągnięciu na strefę zmienia się w plik JPEG o wadze 451 KB – około 90 procent mniej. Działa.
Bilans czasu i kosztów
Od pierwszego promptu do działającej aplikacji minęło około 40 minut. Faza analizy z REA: 24 minuty plus 5 minut na raport. Łącznie 41 wywołań REA i 20 własnych komend Claude’a. Rozliczając po API, a nie w abonamencie: 6,54 dolara, z czego 1,10 dolara pochłonął sam start sesji – 170 narzędzi REA zajmuje około 110 tysięcy tokenów kontekstu, zanim cokolwiek się wydarzy. Cała sesja, z budowaniem aplikacji i zrzutami ekranu, kosztowała w API około 15 dolarów. I od razu nasuwa się pytanie, które będzie wracać przez resztę materiału: ile z tej roboty faktycznie zrobiła REA, a ile Claude zrobiłby i bez niej? Autor sprawdził – odpowiedź pada w podsumowaniu.
Bassgrow: własna wersja Excalidraw
Drugim projektem była aplikacja Bassgrow, zbudowana na bazie Excalidraw – bezpłatnej, interaktywnej tablicy do rysowania, z której autor często korzysta podczas nagrywania materiałów. Projekt jest na licencji MIT, więc wgląd w źródła był w pełni legalny. Podejście do sprawy było przy tym dość uczciwe: REA dostała zbudowaną paczkę z npm, a nie repozytorium z GitHuba – w dokumentacji REA wprost napisano, żeby nie używać jej do zwykłego czytania repozytoriów, bo to narzędzie do skanowania skończonych aplikacji.
Uczciwie trzeba przyznać, że pierwsze podejście wylądowało w koszu. Poważnie: pliki z tłumaczeniami zjadły cały wynik, a główny plik pozostał bez analizy, więc cel trzeba było ręcznie przyciąć – REA sama nie podpowie, co w jej analizie jest tylko szumem. Za drugim razem całość przeszła. Po około 4 minutach REA zamieniła pobraną paczkę w mapę blisko 115 funkcji z nazwami i numerami linii, wydobywając przy okazji parametry kreski, których nikt nie zna na pamięć. Każde znalezisko miało swój dowód, a rzeczy, których narzędzie nie było pewne, trafiły na osobną listę.
Potem wyniki porównano z oficjalnym repozytorium Excalidraw, żeby sprawdzić, czy REA nie zmyśla. Wynik był spokojny: każda sprawdzona funkcja siedziała dokładnie tam, gdzie siedzieć powinna.
Na kolejnym etapie Claude zaczął budowę własnej wersji – roboczo nazwanej Bassgrow – całkowicie od zera. Napisał własny generator kreski, bez gotowej biblioteki do rysowania i bez jednej linijki kodu z GitHuba, a całość dostała autorski design. Nie obeszło się bez wpadek: jedna z funkcji nie działała, pola nie dało się przewijać, był tylko jeden krój pisma – ale po jednym prompcie agent poprawił wszystko w kilka minut.
Publikacja na hosting – sekcja partnerska
Skoro Bassgrow działał, ale tylko na laptopie, autor postanowił wystawić go w sieci, tak by widzowie też mogli się pobawić. Tu zaczyna się sekcja partnera kanału, firmy Hostinger, z której usług (serwery VPS, domeny, hosting) autor korzysta od ponad roku. Kluczowa dla tematu jest oficjalna wtyczka Hostinger dla Claude Code: po dodaniu jej i zalogowaniu się agent potrafi zarządzać hostingiem z poziomu zwykłej rozmowy na czacie.
Polecenie brzmiało: „Wgraj statyczną stronę Bassgrow na mój hosting przez connector Hostinger, skillem do deployu statycznych stron, z gotowego archiwum. Zapytaj o potwierdzenie. Nic nie buduj, nic nie puszuj, żadnych tokenów na ekranie. Po deployu sprawdź”. Agent zapytał o dostępne domeny, autor wybrał subdomenę pod swoim klikania.pl – i po chwili aplikacja żyła w sieci, z aktywnym certyfikatem SSL. Ponieważ Bassgrow to statyczna strona bez bazy danych i logowania, rysunek zostaje w przeglądarce użytkownika: nikt nie widzi cudzych szkiców i nic nie trafia na serwer.
W skrócie oferta, którą autor poleca: plan bez limitu z 50 GB miejsca i codziennymi kopiami zapasowymi (co ratuje, gdy agent zrobi coś, czego nie chcieliśmy), wdrażanie aplikacji webowych w React, Next.js, Vite czy Vue, a przy zamówieniu powyżej roku darmowa domena i skrzynki pocztowe na rok. Z kodem rabatowym hosting na 48 miesięcy wychodzi niecałe 850 zł, do tego 30-dniowa gwarancja zwrotu pieniędzy. Linki – w opisie filmu.
Pierwsze na kanale: mody do Slay the Spire 2
Kolejny przypadek to coś, czego na tym kanale jeszcze nie było: modyfikacje do gry, w której autor ma ponad 500 godzin – Slay the Spire 2. Powstały dwie.
Pierwsza dodaje kartę, której normalnie w grze nie ma: po wpisaniu komendy w konsoli deweloperskiej karta zadaje osiem obrażeń i nakłada jeden punkt słabości. Działa. Druga całkowicie zmienia zasady gry: na starcie wyprawy wybieramy talię startową z dwukrotnie większej puli losowych kart naszej klasy – dziesięć z dwudziestu – a przez cały pierwszy akt walki nie dają już nagród w postaci kart. Mechanizm działa, karty są zmienione, całość się spina.
Technicznie Claude pracował tutaj na gotowym szablonie od społeczności Slay the Spire 2 oraz otwartej bibliotece (w transkrypcie „Base Sleep” – najpewniej chodzi o BaseMod) na licencji MIT. Kod gry pozostał nietknięty. Nowe karty dostały własne grafiki, które wygenerowało AI. I co istotne: REA była w tym projekcie mało użyteczna, bo większość roboty odwalił sam Claude, korzystając z szablonu, otwartych źródeł i kompilatora. To zapowiedź wniosku z podsumowania.
Limitomierz: kiedy REA mówi „nie”
Przy okazji autor pokazuje dwa rozwiązania open source do śledzenia limitów w narzędziach agentowych: CodexBar, który po kliknięciu pokazuje limity Claude’a i Codexa wraz z przeglądem wszystkich limitów na koncie, oraz Code Notch – pasek z limitami do ustawienia z boku ekranu. Linki w opisie.
Na tej kanwie autor wpadł na pomysł: zrobić coś podobnego, ale jako widżet do OBS – programu open source, którym streamuje weekendowe live’y (przy okazji: świeżo pobity rekord – w najlepszym momencie oglądało aż 11 osób, co autora szczerze ucieszyło). I tu REA niestety zawiodła, bo komputer po prostu jej nie uciągnął. Analiza mieliła się ponad 50 minut, pokrycie kluczowych faktów z kodu wyniosło zaledwie 23 procent, a dekompilator Ghidra dwa razy przekroczył limit czasu i mocno obciążył procesor.
Autor nie odpuścił i podszedł do tematu drugi raz, ale inaczej: zamiast dawać Claude’owi dostęp do narzędzi REA, załatwił sprawę własną instrukcją. Efekt? Rozwiązanie bazujące na CodexBarze, nazwane przez agenta „Limitomierzem” – sprawdza limity w Claude Code i wyświetla je w widżecie OBS, odświeżając się co dwie minuty. Liczby (15 procent pięciogodzinnej sesji, 9 procent tygodniowego limitu, 9 procent dla modelu Fable) zgadzają się jeden do jednego z tym, co pokazuje komenda /usage. Co więcej, autor niczego nie robił ręcznie: Claude sam stworzył widżet i sam dodał go do OBS – co autor kwituje uwagą, w jakich to niesamowitych czasach przyszło nam żyć.
Wniosek: mierz, zamiast zgadywać
Czas zebrać wszystko w całość. Jeśli chodzi o inżynierię wsteczną z agentami AI, cały proces sprowadza się do jednej zasady: mierzysz zamiast zgadywać. Agent – na przykład Claude Code – skanuje wybraną aplikację i sprawdza wszystko, co dostaje użytkownik. Potem przygotowuje listę z dowodami oraz osobną listę tego, czego nie jest pewien, a na końcu buduje własną wersję od zera, na podstawie raportu.
Obiecany wniosek, którym autor chce zostawić widzów, brzmi następująco: żeby zbudować własną wersję czegoś bez kradzieży cudzego kodu, REA wcale nie jest potrzebna. Wystarczy odpowiednia metoda i rozmowa z odpowiednim agentem, takim jak Claude Code. Z oryginału bierzesz wyłącznie wiedzę o tym, jak coś działa – nigdy kod, nazwę ani wygląd.
Gotowy skill do inżynierii wstecznej bez instalowania REA czeka w zamkniętej społeczności autora, Operatorzy AI (ponad 420 osób): w środku nagrania weekendowych live’ów, dodatkowe materiały oraz skille i prompty z poradników. Link ze specjalną zniżką – w opisie. Wszystkie pozostałe odnośniki, od REA po wystawionego publicznie Bassgrow, również znajdziemy w opisie filmu. Kanał celuje w 20 tysięcy subskrypcji do końca roku – jest już prawie 19 tysięcy, więc każda pomoc się liczy.