O czym jest ten film
- REA („Reverse Engineer Anything”) zdobyła ponad 100 tys. gwiazdek na GitHubie w kilka dni, a najgłośniejsze komentarze ogłaszają koniec oprogramowania — autor ten ton prostuje.
- Narzędzie podłącza się do Claude Code lub Codexa i pozwala agentowi otworzyć program na twoim komputerze oraz pokazać, jak jest zbudowany w środku.
- Dwa zastosowania: dla budujących oprogramowanie to przyspieszenie pracy, dla wszystkich pozostałych — „rentgen” do badania dowolnej aplikacji, także bez znajomości programowania.
- Przykład: śledztwo w androidowym authenticatorze Aegis pokazało, że sześciocyfrowy kod powstaje z klucza konta i czasu dzielonego na 30-sekundowe przedziały.
- Przykład: badanie Notion wyjaśniło, jak kopiowanie zachowuje strukturę bloków — HTML niesie identyfikator, który przy wklejaniu łączy treść z lokalnie zapisanymi danymi.
- Przykład: przycisk procentu w Kalkulatorze Windows daje różne wyniki po dodawaniu i po mnożeniu — to pokazuje, że specyfikacja funkcji dla AI musi obejmować konteksty użycia.
- Przykład komercyjny: po zbadaniu QuickBooks Desktop deweloper ze społeczności zbudował niezależną aplikację księgową (Ledger Reborn) w Pythonie i SQLite.
- Przykłady deweloperskie: mechanizm przyspieszania gry dinozaura z Chromium oraz rekonstrukcja funkcji dźwięku w skompilowanym DX Ballu.
- Praktyczna rada: każ agentowi, jak głęboko ma zejść i po co — pełne wyjaśnienie całej aplikacji to lawina materiału, która nic nie wnosi do decyzji.
- Ograniczenia i etyka: widać wyłącznie kod po stronie klienta; prywatnego kodu serwerowego nie widać, a próba jego zdobycia to hacking.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Największa przepaść w budowie oprogramowania biegnie między „chcę” a „działa”
Na czym polega: Kod pisany przez AI często wygląda dobrze i sypie się po premierze, bo nikt nie przełożył pomysłu na konkretne wymagania techniczne. REA pozwala obejrzeć, jak prawdziwy zespół rozwiązał pokrewny problem, zanim sam zaczniesz budować.
Jak stosować: Zanim zlecisz agentowi nową funkcję, poproś go o zbadanie, jak istniejąca aplikacja radzi sobie z analogicznym zadaniem, i wyciągnij z tego listę decyzji, które musisz podjąć samodzielnie.
Na co uważać: Zrzut ekranu konkurencji nie jest specyfikacją. Kluczowe są zachowania w różnych sytuacjach, nie wygląd interfejsu.
2.Znajomość pracy nie jest jeszcze modelem danych
Na czym polega: Możesz doskonale wiedzieć, co chcesz osiągnąć (np. zbierać cytaty z notatkami), ale to nie przesądza, czy cytat to „zwykły tekst”, „obiekt z przypisanym źródłem”, co ma wędrować przy kopiowaniu i czy edycja kopii zmienia oryginał. Te rozstrzygnięcia dopiero kształtują architekturę.
Jak stosować: Odkrywaj wymagania iteracyjnie: proś agenta o pokazanie prostych sposobów reprezentacji danych i pytaj, co każdy z nich kosztuje przy kopiowaniu, wyszukiwaniu i eksporcie.
Na co uważać: Nie zawsze da się skończyć listę wymagań przed budową — część z nich zobaczysz dopiero w działającym systemie. Planuj iteracje, nie wielki plan z góry.
3.„Zadbaj, żeby kopiuj-wklej działało” to nie wymaganie
Na czym polega: Śledztwo w Notion pokazało, że wklejanie to złożona umowa: HTML z ukrytym identyfikatorem, lokalnie zapisana struktura bloków, ponowne połączenie obu światów przy wklejeniu. To właśnie detale decydują o odczuciu dopracowania.
Jak stosować: Przy każdej „oczywistej” funkcji pytaj: co dokładnie ma przetrwać operację? Źródło? Notatka? Formatowanie? Powiązania?
Na co uważać: Elegancki wygląd nie oznacza dopracowanego zachowania — możesz stracić coś, na czym ci naprawdę zależy, i nie wiedzieć o tym aż do premiery.
4.Ten sam przycisk, różne zachowania — kontekst jest częścią wymagania
Na czym polega: Procent w Kalkulatorze Windows zachowuje się inaczej po dodawaniu (200 + 10% = 220) i po mnożeniu (200 × 10% = 20). To samo dotyczy poleceń typu „wyślij przypomnienie” (od kiedy liczy się czas?), „zatwierdź wniosek” (co się zmienia?) czy „cofnij” (ile pracy ma zniknąć?).
Jak stosować: Spisz przypadki użycia funkcji i każdą niejednoznaczność przekaż agentowi jako osobne wymaganie; poproś, żeby rozróżnienia były zaszyte w implementacji.
Na co uważać: Autor widział agenty wysyłające przypomnienia z opóźnieniem, bo ich zegar startował za późno. Przypadki kontekstowe trzeba testować celowo.
5.Ucz się od istniejących rozwiązań, zamiast je klonować
Na czym polega: Projekt Ledger Reborn powstał po śledztwie w QuickBooks Desktop: autor zrozumiał obliczenia i zachowanie księgi, a potem niezależnie zaimplementował to, co go interesowało — w Pythonie i SQLite, własnym stosem technologicznym.
Jak stosować: Badaj zachowania, które mają dla ciebie znaczenie (np. czy jedna płatność może pokryć kilka faktur), a nie całą architekturę oryginału. Technologie dobieraj pod własne potrzeby.
Na co uważać: Skopiowanie ekranu odtwarza miejsce, gdzie pojawia się liczba, ale nie wyjaśnia, jak ona powstała. Wartość tkwi w obliczeniach i regułach, nie w interfejsie.
6.Wypytuj o ukryte koszty decyzji projektowych
Na czym polega: Jeśli bogatsze dane zależą od lokalnego zapisu, trzeba wiedzieć, co się dzieje po jego usunięciu, przy przenoszeniu na inny komputer czy przy wysyłce do kogoś, kto nie ma twojej aplikacji.
Jak stosować: Dla każdej decyzji o reprezentacji danych przepytaj agenta o scenariusze awaryjne: usunięcie wpisu, migracja, eksport, odbiorca spoza twojego narzędzia.
Na co uważać: W badanej aplikacji bywają ślepe uliczki i błędy, które łatwo powielić nieświadomie. Traktuj ją jako źródło pytań, nie wzorzec do skopiowania w całości.
7.Mów agentowi, jak głęboko ma zejść
Na czym polega: Pełny opis całej aplikacji to lawina materiału, która nie pomaga podjąć następnej decyzji. Wąskie pytanie daje szybką i użyteczną odpowiedź.
Jak stosować: Zaczynaj od celu („chcę zrozumieć X”), nie od „wyjaśnij mi aplikację Y”. Nieprogramista: opisz pracę, którą oprogramowanie ma wspierać. Deweloper: opisz sytuację, ograniczenia i punkt, w którym utknąłeś.
Na co uważać: Nie przepalaj tokenów na śledztwa bez celu — to rada ponadczasowa. Mikroskop bez ustawionej ostrości nic nie pokaże.
8.REA to przede wszystkim potężne narzędzie do nauki
Na czym polega: Możesz „porozmawiać” z dowolną aplikacją, zrozumieć mechanizm, a potem wytłumaczyć go własnymi słowami — właśnie tak działa uczenie się. Agent pełni rolę niestrudzonego nauczyciela oprogramowania.
Jak stosować: Wybierz coś, na czym się znasz lub czego jesteś ciekaw — znajomość własnej dziedziny to przewaga — i drąż pytania, dopóki nie będziesz w stanie wyjaśnić mechanizmu samodzielnie.
Na co uważać: Wiedza dziedzinowa nie zastępuje rozumienia, jak dane są reprezentowane. Połącz jedno z drugim, zanim zlecisz budowę.
9.Ekspert z agentem to silniejszy decydent
Na czym polega: Specjalista od faktur wie, które sytuacje są częste i które błędy generują dodatkową robotę. REA pozwala mu połączyć tę wiedzę z decyzjami technicznymi i realnie uczestniczyć w rozmowie inżynierskiej.
Jak stosować: Formułuj wymagania jako zdania sprawdzalne: „źródło ma przetrwać wysyłkę cytatów do kolegi, który nie używa mojej aplikacji” albo „wystarczy, że działa wewnątrz mojego środowiska”.
Na co uważać: Proste podejście to legalny wybór — byle świadomy. Delegowanie budowy nie zwalnia z odpowiedzialności za to, co system ma robić.
10.Znasz ograniczenia: kod klienta tak, kod serwera nie
Na czym polega: REA pokazuje wyłącznie kod po stronie klienta. Kodu serwerowego firm nie widać i najwyżej można domyślać się jego działania po zachowaniu aplikacji.
Jak stosować: Przed śledztwem w aplikacji webowej ustal, które zachowania da się w ogóle prześwietlić — resztę badaj przez obserwację interakcji i traktuj wnioski jako hipotezy.
Na co uważać: Próba dostania się do prywatnego kodu serwerowego to hacking. Nie rób tego.
Redakcyjne tłumaczenie
Hype i sedno: przepaść między „chcę” a „działa”
Może widzieliście, jak w tym miesiącu eksplodowała popularnością REA — a może wam to umknęło. Tak czy inaczej, warto się temu uważnie przyjrzeć. Reverse Engineer Anything: ponad sto tysięcy gwiazdek na GitHubie w kilka dni, a najgłośniejsze komentarze ogłaszają, że z oprogramowaniem jako rzemiosłem skończone. Nie podzielam tego poglądu.
Doskonale wiesz, co twoje oprogramowanie ma robić. Tego, czego nigdy nie mogłeś zobaczyć, jest sposób, w jaki prawdziwy zespół zamienia taki zamysł w coś, co faktycznie działa. Przepaść między wymaganiem biznesowym a tym, jak dana rzecz jest poskładana, to jeden z najtrudniejszych problemów w technologii. Dokładnie dlatego tak wiele pisanych dziś programów wygląda dobrze, a wkrótce po uruchomieniu zaczyna się sypać. (Informacja dodatkowa: REA — skrót od Reverse Engineer Anything, „prześwietl wszystko”; narzędzie do inżynierii wstecznej, czyli badania, jak zbudowano istniejący program, z pomocą agentów AI.)
REA domyka sporą część tej przepaści. Podłącza się do Claude Code albo Codexa i pozwala twojemu AI otworzyć program na twoim komputerze, a potem pokazać ci, jak jest zbudowany w środku. Nie klonujesz przy tym niczyjego dzieła — uczysz się od ludzi, którzy wykonali trudne myślenie, żebyś sam nauczył się budować lepsze oprogramowanie.
Rentgen na wszystko — przykład authenticatora
Są dwie zupełnie różne drogi korzystania z tego narzędzia. Jeśli budujesz oprogramowanie, ono cię przyspiesza. Jeśli nie budujesz — działa jak aparat rentgenowski. Pokażę obie, zaczynając od tej, o której większość ludzi w ogóle nie pomyślała.
Przypomnijcie sobie aplikację uwierzytelniającą na telefonie. Pewnie jakąś macie. Pojawia się sześć cyfr, obok tyka licznik, cyfry się zmieniają. Pewnie logujecie się nią do konta służbowego. Ale skąd bierze się ta liczba? Co sprawia, że się zmienia? Co tak naprawdę musiałbyście zbudować, żeby powstało takie narzędzie?
REA ma opublikowane śledztwo dotyczące Aegisa, androidowej aplikacji tego typu. Autorzy wzięli wydany pakiet aplikacji i ruszyli tropem kodu, który generuje te liczby. Obliczenie łączy klucz konta z aktualnym czasem, pogrupowanym w 30-sekundowe przedziały — ten sam klucz w tym samym przedziale daje ten sam kod. Potem przygotowali małą demonstrację, w której można przestawiać zegar i na żywo patrzeć, jak zmienia się wynik.
Nie chodzi o to, że chcecie budować authenticatora. Chodzi o to, że możecie wziąć najprostsze kawałki oprogramowania, nad którymi zawsze się zastanawialiście — „jak to działa? zrobiłbym coś takiego, tylko dopracowanego albo odrobinę innego” — i nagle rozumiecie, jak działają. Zamiast sześciu tajemniczych cyfr macie rozłożoną na części zależność, która je produkuje. Możecie pytać, który element zależy od zegara, a który od konta. Macie realną implementację czegokolwiek zechcecie. Nie musi to być authenticator ani kalendarz — może być dosłownie cokolwiek w sieci, co oglądacie, podczas gdy agent pomaga wam to pojąć.
I o to mi chodzi. To jak zdobycie prześwietlenia całego oprogramowania na świecie. Rzeczy, z którymi masz codziennie do czynienia, zawierają decyzje podjęte przez konkretnych ludzi — a teraz masz sposób, by zacząć widzieć te decyzje w szczegółach. Możesz o nie pytać i uczyć się z nich. Tak, ty — również ty, jeśli nigdy nie napisałeś ani jednej linijki kodu.
„Śmierć oprogramowania”? Raczej deficyt zrozumienia
Ludzie nazywają REA śmiercią oprogramowania. Eh, ileż razy to już słyszeliśmy. Serdecznie mam tego dość. Takie komentarze pomijają fakt, jak niewiele osób rozumie programy, których już używa — tym bardziej te, które próbuje zbudować. Danie większej rzeszy ludzi drogi do zrozumienia to rzecz pozytywna i wielka, zwłaszcza teraz, gdy agent może napisać za ciebie tak dużo kodu. Nadal potrzebujesz sposobu, by ustalić, co ten kod ma robić — ale dla nieprogramisty to ogromna przewaga.
Powiem więcej: dla nieprogramisty REA pełni dwie kluczowe funkcje. Pierwsza — pomaga zrozumieć oprogramowanie, które chce się zbudować: z jakich składa się części i co musi się w nim dziać. Druga — pomaga zrozumieć, dlaczego dana implementacja dokonuje takich, a nie innych wyborów inżynierskich, żebyś mógł zdecydować, które z nich pasują do twojego rozwiązania. Dla dewelopera pytanie bywa węższe: jak oni to zrobili? Czy to rozwiązuje mój problem? Czy nauczywszy się tego, ruszę szybciej?
Dobra, rozumiem — zaczynajmy. Albo, jak to w 2026 roku bywa, każmy zacząć naszemu AI. Widzicie wzorzec? To samo narzędzie, ale przy różnym punkcie wyjścia wiedzy używa się go inaczej. I jak z każdym instrumentem — trzeba się nauczyć nim grać.
Przykład: własne narzędzie badawcze, czyli gdzie ludzie utykają
Przybliżmy więc, jak REA wygląda w praktyce. Załóżmy, że chcesz zrobić narzędzie do własnej pracy badawczej: zbierać fragmenty z różnych dokumentów, dopisywać do nich notatki i odnajdywać wszystko na moment, gdy siadasz do pisania. Nie chcesz zagraconego biurka. Znasz tę pracę. Wiesz, co cię irytuje w narzędziach, których teraz używasz. To dobry powód, żeby coś zbudować. Ale znajomość pracy wcale nie mówi, jak powinna być odwzorowana w oprogramowaniu — i nie mogę tego podkreślić dość mocno. Czy cytat to po prostu tekst na stronie? Czy to osobny obiekt z przypisanym źródłem? Gdy kopiujesz go do innego projektu, co musi wędrować razem z nim? Jeśli edytujesz kopię, czy oryginał ma się zmienić? To są realne wymagania techniczne, które dopiero trzeba odkryć — i każda odpowiedź popchnie cię ku innym wyborom technicznym.
Na tym etapie większość ludzi, gdy im patrzę przez ramię, utyka. To naprawdę trudne. Nie zawsze da się najpierw do końca ustalić, czego się chce, a dopiero potem wręczyć komuś gotową listę wymagań, bo czasem odkrywa się ją po drodze. Zdarza się, że dopiero zobaczenie, jak jakiś system działa, pozwala w ogóle rozpoznać wymaganie: nie wiedziałeś, że jakieś rozróżnienie ma znaczenie, dopóki nie zobaczyłeś, co ono umożliwia — a wtedy nagle miało. Przez ponad dekadę sam byłem taką osobą, patrzącą deweloperom przez ramię, i dałbym się pokroić za coś takiego jak REA.
Śledztwo w Notion: co naprawdę znaczy „działające kopiowanie”
Śledztwo REA w Notion daje tu bardzo konkretny przykład. Zaczyna się od zwykłej czynności: kopiujesz coś. REA pomaga znaleźć w aplikacji desktopowej interfejs schowka i czyta otaczający go kod, który łączy ten interfejs z systemem. Śledztwo zagląda też do zapisanego kodu edytora webowego, żeby zrozumieć, jak kopia może zachować bogatszą strukturę bloków Notion. (Informacja dodatkowa: Notion to popularny edytor dokumentów zbudowany z modułów-bloków; „struktura bloków” to zapis, który pamięta nie tylko tekst, ale też układ i powiązania tych bloków.)
W tym kodzie Notion wysyła do schowka tekst i HTML, a równolegle przechowuje lokalnie ustrukturyzowane dane bloków i umieszcza w HTML-u identyfikator. Dzięki temu przy wklejaniu identyfikator potrafi ponownie połączyć widoczną treść z zapisaną strukturą. Test odzyskanego modułu pokazuje, że bogate dane bloków wracają, gdy identyfikatory się zgadzają. To wszystko możliwe dlatego, że użyto REA do zrozumienia, jak Notion to robi.
Popatrzcie teraz, czego to uczy w sprawie naszej aplikacji badawczej. Wcześniej moglibyście powiedzieć agentowi: „zadbaj, żeby kopiowanie i wklejanie działało”. Bardzo rozsądna prośba — ale co właściwie znaczy? Czy dociera sam cytat? Czy dociera link do źródła? Czy dociera notatka, którą dołączyliście? Ile wam zależy na tych szczegółach? To właśnie detale sprawiają, że oprogramowanie wydaje się dopracowane. Można mieć słowa na ekranie i nadal nie mieć czegoś, na czym się naprawdę czuło — i można o tym nie wiedzieć, dopóki się tego nie zbuduje. Od ponad roku jest to zmora ludzi tworzących w stylu vibe codingu. (Informacja dodatkowa: „vibe coding” — budowanie aplikacji głównie przez formułowanie poleceń dla AI, bez wnikania w szczegóły techniczne; efektem bywają programy efektowne na pierwszy rzut oka, ale kruche w praktyce.) Teraz możecie prowadzić znacznie bogatszą rozmowę, zanim powstanie cały edytor.
Odkrywacie bowiem, czym wasze informacje muszą być, żeby działać w środowisku komputerowym. Jeśli relacja między cytatem a źródłem ma znaczenie, trzeba znaleźć sposób, by ją zachować. Można poprosić agenta o pokazanie prostego sposobu jej przedstawienia, a potem zapytać, co kopiowanie takiej reprezentacji pociąga za sobą.
Konsekwencje dla architektury — i lekcja o uczniu się od innych
Wszystko to wpływa na wybór stosu technologicznego. Edytor obsługujący stronę zwykłego tekstu daje jeden punkt startowy. Edytor, który ma zachować osobne cytaty, notatki i relacje między nimi — zupełnie inny, znacznie bardziej złożony. Sposób przechowywania informacji musi wspierać to, co chce się z nimi robić. To szersza lekcja na 2026 rok: uczysz się jednocześnie, o co pytać i co technologia musi udźwignąć.
A jeśli ktoś myśli, że żaden element jego pomysłu nie ma odpowiednika we wcześniejszym oprogramowaniu — mam nowinę: ma. Możecie mieć bardzo osobliwe połączenie potrzeb, wasz bieg pracy może być nietypowy, ale obiecuję, że inni pracowali nad edytorami, przechowywaniem dokumentów, wyszukiwaniem, kopiowaniem, linkowaniem, przenoszeniem informacji między miejscami. Nad wszystkim w środowisku komputerowym ludzie już pracowali. Możecie uczyć się z tych rozwiązań, układając własne — niezależnie od tematu. Jestem tego głęboko pewien.
Zauważcie przy tym: nie musieliście przychodzić ze znajomością wszystkich szczegółów ani ze zrozumieniem, co znaczy „ustrukturyzowane dane bloków”. Wystarczyło przyjść z ciekawością i chęcią zrozumienia tego, nad czym pracujecie i co budujecie. A potem wypytuje się z pomocą REA, dopóki samemu się nie pojmie tych powiązań. To jest naprawdę wasze pierwsze zadanie: zrozumieć, co próbujecie zbudować. Drugie zaczyna się, gdy pytacie, dlaczego ktoś ułożył to w ten sposób — i nie dajecie za wygraną, bo właśnie to prowadzi do własnego przebłysku, do decyzji, co chcecie zrobić inaczej.
Weźcie projekt schowka: po co w HTML-u trzymać zwykły tekst, a obok osobno bogatszą reprezentację? Przemyślcie, co każda z nich umożliwia. Inne aplikacje potrafią coś zrobić z tekstem. Wasza własna aplikacja może znać relacje i funkcje edycji. Projektując narzędzie badawcze, musicie ustalić, ile zbadanych wymagań przeżywa konkretną operację kopiowania i wklejania. Kopiuj-wklej jest mi bliski, bo przed paroma tygodniami opisywałem wam, jak zbudowałem aktywnego menedżera schowka — sporo tego przemyślałem i żałuję, że REA nie istniało wtedy. Byłaby frajda.
Ukryte koszty i ślepe uliczki
REA pomaga też pytać o ukryte koszty oprogramowania. Jeśli bogatsza informacja zależy od lokalnie zapisanego wpisu danych — co się dzieje, gdy ten wpis znika? Czym jest funkcja usuwania? Dokąd trafia martwa informacja? Co się dzieje, gdy treść trafia na inny komputer? Czy wasza aplikacja musiałaby wpakować więcej danych do kopiowanej treści? Czy osobny eksport byłby lepszym wyjściem? Krótko mówiąc, można w ten sposób wykrywać ślepe uliczki, a nawet błędy, których nie chcecie powielać.
To wszystkie pytania, które warto sobie zadać podczas projektowania, podsunięte przez zaobserwowaną implementację. Po raz pierwszy można rozumować o konsekwencjach, nie udając, że zna się wszystko z góry. Gdyby oryginalny zespół opublikował wyjaśnienie — czego prawie nigdy nie robi — wspaniale. Ale go nie potrzebujemy: wystarczy poprosić agenta, żeby zrozumiał kod i pomógł go wspólnie interpretować. Można to robić z Codexem, z Claude. Czy się to komuś podoba, czy nie, bierze się teraz udział w rozmowie inżynierskiej. Można powiedzieć: „źródło musi przetrwać, gdy wyślę ten cytat koledze, nawet jeśli nie używa mojej aplikacji”. Albo: „to ma działać tylko wewnątrz mojego środowiska i proste podejście aż nadto wystarczy”. Tak czy owak — decydujecie wy. Więcej rozumiecie z tego, o co prosicie i co implementacja musi zachować. Jesteście mądrzejszymi liderami dla AI — to kolejny wielki wątek tego roku.
Przycisk procentu: ten sam klawisz, różne zachowania
Kolejny przykład REA czyni ten problem niemal absurdalnie wyraźnym: przycisk procentu w Kalkulatorze Windows. Wpiszcie 200 + 10%, dostaniecie 220. Wpiszcie 200 × 10%, dostaniecie 20. Ten sam przycisk, inny kontekst. Zbadanie tego — a REA to zrobiło — pokazuje, że zainstalowana biblioteka kalkulatora i wyłuskana z kodu ścieżka pozwalają ustalić, co się dzieje: po dodawaniu 10% staje się dziesięcioma procentami pierwszej liczby; przy mnożeniu przycisk korzysta z już wybranej operacji i w zależności od niej decyduje, co ma znaczyć.
Wyobraźcie sobie, że macie taką funkcję opisać budowniczemu-AI w czymś tak prostym jak kalkulator. „Potrzebuję przycisku procentu.” Świetnie — agent go da. Ale dopóki nie przemyślicie tych różnych sytuacji, nie sprecyzowaliście rzeczywistego zachowania. Zrzut ekranu tego nie załatwi, prawda? Dopiero działająca implementacja pokazuje, czego brakuje: że procent znaczy coś w kontekście i że tę wrażliwość na kontekst trzeba zaszyć w kalkulatorze.
I to przenosi się na znacznie większe decyzje. Gdy mówicie „wyślij przypomnienie” — od kiedy biegnie zegar? Widziałem na żywo agenty wysyłające przypomnienia z opóźnieniem, bo ich zegar startował za późno. To nie teoria — ludzie doświadczają tego w 2026 roku. Gdy mówicie „zatwierdź wniosek” — które uprawnienia się zmieniają? Gdy mówicie „cofnij” — ile pracy ma zniknąć? Rozumienie realnej implementacji pomaga przejść od zwiastuna funkcji do decyzji, które czynią ją naprawdę użyteczną. To trochę jak oglądanie samego zwiastuna „Odysei” — bez obejrzenia całego filmu. Dlatego nie chcę bagatelizować tego, co się z REA dzieje: zobaczymy cały film. Zobaczymy całe oprogramowanie. Przejście od „chcę tego” do opisu pasującego do systemu technicznego to jedna z najtrudniejszych rzeczy w branży — a jeśli się pomylisz, możesz spędzić mnóstwo czasu, dopracowując coś, co nie obsługuje sytuacji, do której było ci potrzebne. Agent może pomóc odkryć te wymagania, badając, jak istniejąca aplikacja radzi sobie z pokrewnym problemem w szczegółach.
Ledger Reborn: od QuickBooks do własnej księgowości
Wróćmy, jak obiecałem, do przykładu QuickBooks, bo to dzieje się już poza małymi demo dydaktycznymi. Deweloper ze społeczności opublikował projekt Ledger Reborn — świetna nazwa — po zbadaniu z REA wersji QuickBooks Desktop na Maca. Opis mówi o skupionej pracy nad arytmetyką zapasów, liniami budżetowymi, saldami uzgodnień i gałęziami logiki odpowiedzialnymi za księgowanie metodą kasową. Następnie autor niezależnie zaimplementował aplikację robiącą to wszystko — w Pythonie i SQLite. W opublikowanej wersji podglądowej zapisuje ona faktury i zarejestrowane płatności w lokalnej księdze, ewidencjonuje zapasy i wylicza raporty. W skrócie: REA dostarczyło materiału dowodowego i pseudokodu pokazującego, jak to działa, a potem powstała niezależna implementacja podążająca za wzorcami, które zainteresowały autora. (Informacja dodatkowa: QuickBooks to popularny w USA program księgowy firmy Intuit; metoda kasowa to ujmowanie przychodów i kosztów dopiero w momencie faktycznej płatności.)
Co mnie tu fascynuje, to rodzaj pytań, które badano. Jeśli ograniczycie się do skopiowania ekranu księgowego, odtworzycie miejsce, w którym pojawia się liczba — nie rozumiejąc, jak ona powstała. Tu śledztwo weszło w obliczenia i zachowanie księgi, czyli właśnie tam, gdzie tkwi znaczenie tego oprogramowania. I to jest część, którą trzeba zrozumieć, żeby zrobić działającą wersję. Pomyślcie o wymogu tak zwykłym jak zapisanie płatności: czy płatność pokrywa całą fakturę? Czy jedna płatność może pokryć kilka faktur? Co pozostaje do zapłaty? Co powinien pokazać raport? To wzajemnie powiązane decyzje. Potrzebujecie reprezentacji informacji, która udźwignie te zachowania, i testów, które powiedzą, czy wynik jest poprawny.
Widać tu wyraźnie, dlaczego wiedza dziedzinowa ma tak wielkie znaczenie. Ktoś, kto codziennie ma do czynienia z fakturami, wie, które sytuacje są częste i które błędy generują dodatkową robotę. REA daje takiej osobie jeszcze jedną drogę, by połączyć swoją wiedzę z decyzjami technicznymi u podstaw — może badać z agentem i drążyć pytania, dopóki proponowany system naprawdę nie obejmie jej pracy.
Oryginalna aplikacja może używać zupełnie innego stosu niż wasz. Niekoniecznie chcecie całą architekturę — chcecie zrozumieć zachowania, które mają dla was znaczenie. Nikt tu nie próbuje robić klonów; robimy oprogramowanie osobiste, które ma dla nas znaczenie, albo narzędzia dla wąskiej grupy odbiorców. Właśnie dlatego przejście od badanego produktu desktopowego do osobnej aplikacji w Pythonie i SQLite jest tak interesujące: śledztwo zasila nowy zestaw wyborów inżynierskich. I można wykonać tę użyteczną pracę, nie zamierzając nikogo zastępować — powtarzam to, bo ludzie błędnie biorą to za kopiowanie. Wasz produkt może obsługiwać jedynie to jedno zadanie, którego potrzebujecie w firmie. Okazja polega na zrozumieniu tego zadania na takim poziomie, by umieć wyjaśnić, co powinno się dziać, wybrać odpowiednią implementację z dużą wiedzą w tle i rozpoznać, czy działa. To wy ustalacie, ile trzeba zbudować — a teraz macie techniczne przyrządy do prześwietlania oprogramowania.
Dla deweloperów: dinozaur i DX Ball
Dla deweloperów można wejść znacznie głębiej. Znacie już struktury danych, framework, ograniczenia. Patrzycie na funkcję i myślicie: jak dokładnie uzyskali to zachowanie? Dajcie mi odpowiednie mechanizmy, a ruszam. Świetną ilustracją jest przykład gry dinozaura w REA. Zbadano edycję przeglądarkową wywodzącą się z dinozaura Chromium i odzyskano JavaScript faktycznie ładowany przez stronę. Pytanie brzmiało: dlaczego gra stale przyspiesza. Kod startuje z prędkością 6 i przy każdej aktualizacji bez kolizji dodaje tysięczną, dopóki prędkość nie przekroczy 13. Dostajecie wdzięczną regułę, która tłumaczy „poczucie” gry. Projekt wykorzystuje ją w małej nowej grze z regulacją prędkości — można to zaimplementować od razu, zachować odzyskane przyspieszenie albo podkręcić je jeszcze mocniej. Tak czy inaczej, porównanie w projekcie drąży zachowanie pod powierzchnią zrzutu ekranu — zachowanie na poziomie kodu, którego potrzebujecie, budując własną grę. Pozwala to na znacznie precyzyjniejsze zmiany: może chcecie łagodniejszego przyrostu, może nie — ale to wy decydujecie, bo zajrzeliście pod maskę. (Informacja dodatkowa: „dinozaur” to wbudowana gra offline w przeglądarce Chrome, pojawiająca się przy braku połączenia z internetem.)
Ostatnie pytanie dotyczy samej pracy inżynierskiej. Praca inżyniera przesuwa się od „czy potrafię zrozumieć system” ku „jak chcę skonfigurować system” — a REA to po prostu przyspiesza. Agent pomaga śledzić zależności, tłumaczyć reguły i implementować wybraną wersję; całe śledztwo trwa teraz krócej. Ale to wciąż wy musicie zdecydować, co chcecie zbudować.
Wersję natywną widać w studium przypadku DX Ball w REA: prześledzono, jak pozioma pozycja cegły zamienia się w skompilowanej grze na wartość panoramy dźwięku lewo–prawo. Początkowy wynik dekompilatora był niekompletny, więc śledztwo podążało za rozkazami procesora, wywołaniami i ograniczeniami — a opublikowana rekonstrukcja doprowadziła do funkcji, która faktycznie działa względem oryginału. To bardzo celne pytanie: nie trzeba odtwarzać całej gry, by zrozumieć tę jedną zależność. Skoro jednak deweloper może z REA zejść na taki poziom detalu, to naprawdę można pytać o cokolwiek — a nieprogramista zada znacznie prostsze pytanie i też dostanie świetne wyjaśnienie. (Informacja dodatkowa: DX Ball to klasyczna gra typu arkanoid z lat 90., w której odbija się piłkę, niszcząc cegły.)
Jak zadawać pytania: cel i głębokość
Jedną rzeczą, którą warto przemyśleć przy pracy z tym narzędziem, jest to, jak głęboko każecie mu zejść. Jeśli poprosicie o pełne wyjaśnienie całej aplikacji, dostaniecie ogrom materiału, który nie pomoże w podjęciu następnej decyzji. Dajcie agentowi powód do śledztwa: „chcę zrozumieć ten wynik, pomóż mi śledzić istotną część”. Moja prośba do was, jeśli używacie REA: mówcie mu, jak głęboko ma zejść. Powiedzcie swojemu mikroskopowi, na czym ma się skupić.
Nieprogramista zacząłbym od opisania pracy, którą moje oprogramowanie ma wspierać, a potem poprosiłbym agenta o wskazanie znajomych komponentów i drążenie ich. Można tak kopać dalej, po kolei pojmując pojęcia — można nawet poprosić o diagramy. Deweloper może opisać sytuację i własne ograniczenia precyzyjniej: „znajdź tę implementację i pomóż mi zrozumieć te zależności; tu utknąłem; pokaż przykłady, a potem pomóż zaimplementować”. Przy wąskim pytaniu to może być krótkie, celne śledztwo. Krótko mówiąc: nie przepalajcie tokenów, jeśli nie musicie — to moja rada ponadczasowa.
Instalacja i granice narzędzia
Żeby zacząć, podłącza się REA do agenta kodującego, takiego jak Claude czy Codex. Warto wiedzieć, że jest tu trochę oficjalnej konfiguracji: narzędzie korzysta z Node.js i npm, a różne cele wymagają różnych narzędzi do inspekcji. Przy instalacji pojawią się pytania w stylu „dodać to?”. Brzmi banalnie, ale spytajcie swoje AI, czy dodanie danego elementu cokolwiek zmieni w waszym projekcie. Czasem będzie potrzebne, czasem nie — a Node.js nie jest niczym strasznym, jeśli trzeba je zainstalować.
I pamiętajcie: gdy zaczniecie kopać, nie zobaczycie kodu po stronie serwera. To pokazuje wyłącznie kod klienta, a firmy trzymają prywatny kod serwerowy, którego nigdy nie ujawniają. Można co nieco wywnioskować o jego działaniu z zachowania aplikacji, ale zobaczyć się go nie da — ani nie próbujcie, bo to byłby hacking. Nie róbcie tego.
Nauka i nowa relacja z oprogramowaniem
Jako narzędzie do nauki — jeśli instalujecie to, bo „Nate powiedział” — oto, co zrobiłbym w pierwszej kolejności: używajcie tego, żeby się uczyć. To bardzo mocne narzędzie edukacyjne. Nawet jako inżynier możecie „porozmawiać” z aplikacją, zrozumieć, jak działa, a potem spróbować wytłumaczyć ją własnymi słowami — na tym polega uczenie się. Mamy teraz w praktyce niestrudzonego nauczyciela, który rozumie oprogramowanie w internecie i potrafi zejść do głębi technicznej, do której wcześniej było trudniej dotrzeć. I myślę, że właśnie tak zaczyna się zmieniać nasza relacja z oprogramowaniem: patrzymy na coś znajomego, uświadamiamy sobie, że zawsze było pytanie, które chcieliśmy zadać — i po prostu je zadajemy.
A jeśli się zastanawiacie: czyż Codex nie umiał tego wcześniej? Czy Claude nie umiał? Umieli — pod warunkiem że ostrożnie ich poprowadziliście i mieliście cierpliwość. Ale REA daje to wszystko od razu, bez dodatkowych zabiegów, i jest bardzo proste. Dla nieprogramisty, dla wszystkich nas, którzy nie budują zawodowo, to droga do zrozumienia oprogramowania, jakiej nigdy wcześniej nie było. Ledwo byliśmy w stanie prowadzić te wyszukane, wyrafinowane prompty. Teraz możemy wejść, zrozumieć i zdobyć rentgen, o jakim wcześniej mogliśmy tylko pomarzyć.
W aplikacjach, których już używacie, tkwi ogrom ludzkiego rozwiązywania problemów. Niezależnie od tego, czy jesteście deweloperami, macie teraz kolejny sposób, by to przebadać — z agentem, który pomoże wyjaśnić, co widzicie. Wybierzcie więc coś, czego jesteście ciekawi, i zacznijcie drążyć. Może się okazać, że potraficie zadawać — i odpowiadać — na znacznie ciekawsze pytania, niż myśleliście. A jeśli oprogramowanie to wasza pasja, z REA będzie sama przyjemność.
Może jeszcze pytanie: jak w ogóle zacząć? Nate właśnie podał podstawy instalacji, więc na Substacku pojawi się wpis z konkretnymi „punktami kopania” — miejscami, od których warto zacząć. Jeśli więc myślicie: mam tę moc, ale nie wiem, gdzie jej użyć — pomożemy wam ją wykorzystać. Wchodźcie, w społeczności aż się gotuje. Trzymajcie się!