Oprogramowanie umarło

O czym jest ten film

Teza autora: „software umarł” — kod przestał być źródłem przewagi konkurencyjnej, bo AI z narzędziami inżynierii wstecznej potrafi odtworzyć niemal każdą aplikację.
Dowody z sieci: ludzie przenoszą Minecrafta i GTA V na platformy, na których nigdy nie miały działać — GTA V uruchomiono na zwykłym iPhonie, Super Mario Bros działa na PC.
Autor sam zbudował z pomocą AI własne odpowiedniki znanych programów: Screen Studio (Glide), TradingView (Terminal), Paper (paper-rs) oraz aplikację REC, którą nagrywa ten film — wszystko w Rust.
Kluczem jest repozytorium REA („Reverse Engineer Anything”), obecnie numer jeden na GitHubie: lokalny serwer MCP plus narzędzie wiersza poleceń, które wystawia agentowi klasykę inżynierii wstecznej — Hoppera, Ghidrę i IDA.
Wykład o kompilacji i dekompilacji „jak dla pięciolatka”: kod źródłowy to przepis na ciasto, binarka to upieczone ciasto, a dekompilacja to zgadywanie przepisu na podstawie smaku.
Odtworzony kod nie jest identyczny z oryginałem (4 + 1 = 5 versus 3 + 2 = 5) — jest jedynie równoważny, więc liczy się zgodność zachowania, nie podobieństwo linijek.
Warsztat autora: GrokBot dyryguje na domowej sieci (VPS, MacBooki, laptop Framework, maszyna z Linuksem) sesjami Claude Code, wybierając komputery bezczynne lub z najwięcej wolnej pamięci.
Zastosowania produkcyjne: w aplikacji Pluto odtworzył mechanizm błyskawicznych odpowiedzi czatu z GrokBota — czas reakcji spadł z 50–170 ms do 17–33 ms; produkt Bezela, zbudowany z jego udziałem, zarabia pieniądze.
Autor oddziela zabawę od pracy: GrokBot z Claude służą do jednorazowych projektów, do poważnej pracy nad produktami używa T3 code.
Konkluzja: prawdziwą fosą jest dziś dbałość — dopracowanie interfejsu, doświadczenie użytkownika i utrzymanie; zwykłe aplikacje użytkowe, jak kolejna lista zadań, przestały być pomysłem na biznes.

10 najważniejszych takeaways — z kontekstem zastosowania

1.REA: każda aplikacja może stać się dla ciebie „open source”

Na czym polega: Repozytorium REA łączy agenta kodującego z narzędziami inżynierii wstecznej przez lokalny serwer MCP i interfejs wiersza poleceń. Wystarczy prompt w stylu „jak działa funkcja X? Zbuduj ją” — i agent analizuje wybrany mechanizm, a potem go odtwarza.

Jak stosować: Wręcz repo swojemu agentowi (Claude Code lub innemu), wskaż jedną konkretną funkcję, a nie całą aplikację, i pozwól agentowi w pętli porównywać swoją wersję z oryginałem.

Na co uważać: Inżynieria wsteczna bywa ograniczona licencją lub umową EULA — zanim przeniesiesz cudze rozwiązanie, zwłaszcza do produktu komercyjnego, sprawdź konsekwencje prawne.

2.Bez zrozumienia kompilacji nie pokierujesz agentem

Na czym polega: Kod źródłowy to „przepis”, binarny plik to „upieczone ciasto”, które faktycznie dostajemy przy pobieraniu aplikacji. Dekompilacja to odtwarzanie przepisu na podstawie smaku gotowego ciasta.

Jak stosować: Gdy agent nie wie, jak coś działa, poproś go o analizę skompilowanego pliku i przełożenie wniosków na kod — zamiast zgadywać mechanizm po samym interfejsie.

Na co uważać: To proces iteracyjny i żarłoczny. Zawężaj zadanie do pojedynczych funkcji, inaczej pętla analizy rozrośnie się w koszty i czas.

3.Odtworzony kod jest równoważny, nie identyczny

Na czym polega: Jeżeli w oryginale było 4 + 1 = 5, agent może dojść do wniosku, że chodziło o 3 + 2 = 5. Wynik ten sam, droga inna — dekompilacja nie zwraca oryginalnego źródła, tylko kod o zbliżonym zachowaniu.

Jak stosować: Formułuj kryteria akceptacji jako zachowanie i testy porównawcze wobec oryginału, a nie podobieństwo kodu do wzorca.

Na co uważać: Równoważny kod może mieć inną charakterystykę wydajności — zawsze mierz efekty (u autora czas odpowiedzi spadł z 50–170 ms do 17–33 ms).

4.Przewaga agenta: pętla bez zmęczenia

Na czym polega: Człowiek się męczy, musi spać, ma rodzinę i rozproszone zadania. Agent kręci pętlą „zgadnij — zbuduj — porównaj” bez końca, bez emocji i bez potrzeby przerwy.

Jak stosować: Ustaw testy automatyczne jako sędziego pętli i pozwól agentowi pracować nocą nad odtwarzaniem funkcji; rano tylko przeglądasz wyniki.

Na co uważać: Niekontrolowana pętla to rosnące koszty tokenów — pilnuj budżetu i wyznacz punkty przerwania.

5.Jeden agent może dyrygować innymi na twoich maszynach

Na czym polega: Autor uruchamia GrokBota na swoim MacBooku, a ten otwiera sesje Claude Code na pozostałych komputerach sieci — VPS, dwóch MacBookach, laptopie Framework i maszynie z Linuksem — wybierając sprzęt bezczynny lub z największą ilością wolnej pamięci.

Jak stosować: Opisz swoją sieć w instrukcji (tzw. skillu) agenta orkiestrującego: jakie maszyny są dostępne, po czym poznać bezczynność i jakie build ma wymagania (np. kompilacja na macOS).

Na co uważać: Automat działający po sieci domowej to kwestie bezpieczeństwa — ograniczaj uprawnienia i monitoruj, co agent instaluje i gdzie.

6.Przenoś sprawdzone mechanizmy do produktów z klientami

Na czym polega: Dzięki REA autor odtworzył w Pluto sposób, w jaki GrokBot osiąga błyskawiczne odpowiedzi czatu, i wdrożył go przez scalony pull request z testami „przed i po”.

Jak stosować: Odtwarzaj pojedyncze mechanizmy, nie całe produkty; wdrażaj przez pull request z testami porównawczymi, które udokumentują zysk.

Na co uważać: W komercji implementuj własną wersję zaobserwowanego zachowania, a nie kopię cudzego, potencjalnie chronionego kodu.

7.Oddzielaj jednorazowe prototypy od poważnej pracy

Na czym polega: GrokBot z Claude służą autorowi do szybkiego wyrabiania projektów „na sprawdenie”; gdy praca wymaga pełnej koncentracji, sięga po T3 code.

Jak stosować: Dobieraj ścieżkę do stawki: eksperyment — luźna sesja agenta; produkt z użytkownikami — kontrolowany harness, plan i testy.

Na co uważać: Prototyp z jednego wieczoru nie jest utrzymywalny — nie opieraj na nim biznesu ani obietnic wobec użytkowników.

8.Nowa fosa konkurencyjna to dbałość o detal

Na czym polega: Skoro kod łatwo odtworzyć, wyróżnia się ten, kto dopracowuje interfejs, doświadczenie użytkownika i utrzymanie — kto sprawia, że klientowi „chce się zapłacić”.

Jak stosować: Inwestuj czas w to, czego agent nie skopiuje jednym promptem: spójny i dopracowany interfejs, kontakt z użytkownikami, rozwój produktu w czasie.

Na co uważać: Sama pasja nie wystarczy — autor utrzymuje tylko te własne narzędzia, które realnie wspierają jego zainteresowania; świadomie wybieraj, co rozwijać, a co porzucić.

9.Generyczne aplikacje użytkowe jako biznes umarły

Na czym polega: Według autora skończyły się czasy, w których wystawienie kolejnej listy zadań przynosiło użytkowników — większość prostych aplikacji da się dziś odtworzyć jako open source.

Jak stosować: Jeśli budujesz produkt, szukaj przewagi poza samą funkcjonalnością: dystrybucja, społeczność, integracje, dane, jakość obsługi.

Na co uważać: „Software umarł” to teza o przewagach, nie dosłowna recepta — sam autor nie zastępuje własnymi wytworami większości narzędzi, których używa.

10.Nie publikuj kodu, którego nie rozumiesz

Na czym polega: Autor przyznaje, że jego produkt Bezela powstał „na szybko” z AI i sam nie rozumiał go w całości — przed wystąpieniem na konferencji uratowała go wtyczka Scrimba „explain”, generująca trzyminutowe wideo wyjaśniające architekturę projektu.

Jak stosować: Zanim oddasz projekt innym (prelekcja, przekazanie zespołowi, audyt), wygeneruj dokumentację lub wideo z architekturą i zweryfikuj, czy oddaje rzeczywistość.

Na co uważać: To fragment sponsorski — traktuj narzędzie jako jedną z opcji. Sedno pozostaje: wysyłanie do produkcji kodu, którego nie rozumiesz, to ryzyko.

Redakcyjne tłumaczenie

Oprogramowanie umarło — i trudno się z tym spierać

Oprogramowanie umarło i nie da się tego dłużej udawać. Napisałem o tym na Twitterze i sporo ludzi się wściekło. Ale popatrzcie sami. W sieci ludzie przenoszą Minecrafta i GTA V na platformy, na których nigdy nie miały działać. Super Mario Bros chodzi na PC. A moim faworytem jest GTA V uruchomione na zwykłym iPhonie.

I nie chodzi tylko o gry — o cały software. Sam zbudowałem własnego Screen Studio (nazwałem go Glide), własnego TradingView (Terminal) oraz własny odpowiednik Paper (paper-rs). Wszystko napisane w Ruście, wszystko z pełnym interfejsem, wszystko w pełni sprawne. Nawet program, którym nagrywam ten film, stworzyłem sam — z pomocą AI.

Ale samo AI nie zrobiłoby tej roboty. Kluczem jest jedno, bardzo potężne repozytorium na GitHubie: REA, od „Reverse Engineer Anything” — „poddaj inżynierii wstecznej cokolwiek”. Jeśli wręczysz je swojemu ulubionemu agentowi kodującemu, w praktyce każde oprogramowanie na świecie staje się dla ciebie open source. W tym materiale pokażę, jak REA działa i jak ja z niego korzystam, żebyście i wy mogli. A na koniec odpowiem na pytanie, czym jest dziś prawdziwa fosa konkurencyjna — bo na pewno nie jest nią już kod.

(Informacja dodatkowa: Screen Studio to popularny na macOS program do nagrywania ekranu, znany z automatycznego przybliżania i wygładzania ruchu kursora.)

Czym jest REA i jak działa

REA to lokalny serwer MCP oraz narzędzie wiersza poleceń. Serwer wystawia agentowi trzy klasyczne narzędzia inżynierii wstecznej: Hoppera, Ghidrę i IDA. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to standard łączenia modeli językowych z zewnętrznymi narzędziami — serwer MCP „wydaje” agentowi konkretne umiejętności; Ghidra, IDA i Hopper to od lat podstawowy zestaw analityków do badania skompilowanych programów.)

Te narzędzia istnieją od dawna i od dawna służą do rozbierania oprogramowania na części pierwsze — tyle że robota z nimi była piekielnie czasochłonna. Teraz agenty AI używają ich przez REA i bez trudu kręcą pętlami: analizują, zgadują, budują, sprawdzają — aż odtworzą to, co dostały za zadanie.

Całość sprowadza się do jednego promptu: „Jak działa funkcja X? Zbuduj ją dla mnie.” Dokładnie tak skopiowałem pewną funkcję z GrokBota do mojej aplikacji Pluto — pokażę to na żywym przykładzie.

Kompilacja i dekompilacja jak dla pięciolatka

Żeby to zrozumieć, mam diagram, który wytłumaczy sprawę tak prosto, jakbyście mieli pięć lat. Wyobraźcie sobie, że piszecie kod. To przepis na ciasto. Kompilator bierze ten przepis i piecze ciasto — a dokładniej: zamienia kod na plik binarny, ciąg zer i jedynek. Właśnie ten plik uruchamia komputer. Kiedy pobieracie aplikację, nie dostajecie kodu źródłowego. Dostajecie ciasto — upieczone i gotowe do zjedzenia — a nie przepis.

REA z agentem odwracają ten proces. Ciasto już jest: próbujecie go kawałek po kawałku, zgadujecie składniki, pieczecie własną wersję według tych domysłów i porównujecie smak z oryginałem. I tak w kółko. Jak ujął to sam diagram: „REA podaje twojemu AI narzędzia. Pozwala agentowi z nich korzystać. Śledzi jedną funkcję i notuje wszystko, co odkrywa.” W końcu macie własne ciasto: agent pisze własny przepis, który robi to samo, testuje go wobec oryginału i poprawia, dopóki oba się nie zgadzają.

Dla człowieka to miesiące żmudnej pracy. Człowiek się męczy, musi spać, ma rodzinę — w końcu trzeba wyskoczyć po pieluchy. Agent nie ma emocji, nie zna zmęczenia i dysponuje nieograniczonymi tokenami. Po prostu buduje dalej.

Nie dostaniesz tego samego kodu — i to nie ma znaczenia

Używam słów „kompilacja” i „dekompilacja”, więc uporządkujmy trzy pojęcia. Kod źródłowy to kod pisany przez ludzi — kiedyś; dziś coraz częściej piszą go nasi agenci. To czytelny TypeScript, Rust i cała reszta tego, co lubimy, na przykład: „jeśli wynik przekracza 100, wywołaj funkcję zwycięstwa”. Kompilacja zamienia taki kod na zera i jedynki, które wykonuje komputer — moje wypociny stają się binarnym plikiem i to on naprawdę pracuje. Dekompilacja to droga powrotna: z zer i jedynek, iteracja po iteracji, odtwarzanie kodu źródłowego.

Tyle że oryginału nie dostaniecie. Jeżeli w źródle było 4 + 1 = 5, agent może dojść do wniosku, że chodziło o 3 + 2 = 5. Wynik ten sam, droga inna. I właśnie w tym tkwi siła REA: nie odtwarza kodu linia w linię — odtwarza zachowanie.

Przerywnik: gdy nie rozumiesz własnego produktu

(Informacja dodatkowa: poniższy fragment to sekcja sponsorska filmu, pozostawiona dla kompletności.)

Zostałem zaproszony na MCP Dev Summit w Toronto (5–6 października), gdzie opowiem o tym, jak zmęczyło mnie przełączanie się między osobistymi agentami — w efekcie zbudowałem własny serwer MCP o nazwie Bezela, z którego korzysta ponad 700 osób, i organizatorzy chcieli, żebym o tym opowiedział. Przyznam się bez owijania w bawełnę: całość napisałem „na szybko” z AI i nie rozumiem jej w pełni. I tu uratowała mnie wtyczka Scrimby „explain” dla Codexa — działa też z Claude Code. Wystarczy prompt „użyj generatora wideo explain”, wyszukujesz Scrimbę na liście wtyczek i już działa.

Obejrzyjcie fragment, który wygenerowała. „Bezela łączy twoje dotychczasowe agenty AI z narzędziami, którymi sam zarządzasz.” Nie będziemy oglądać całości — wystarczy, że wiecie: wtyczka rozebrała cały projekt na czynniki pierwsze. Pokazała architekturę, pokazała, jak to działa, w trzech minutach wideo, w całości wygenerowanego przez AI — a wyjaśniło to tak dobrze, że jestem w zasadzie gotowy do wystąpienia. Plugin znajdziecie na scrimba.com/explain, jako wtyczkę do Codexa albo przez stronę. Możecie też wybrać drogę męczenników i czytać kod wygenerowany przez AI. Wybór należy do was. Wracamy do tematu.

Jak agent dyryguje agentami: moja sieć maszyn

Pokażę, jak używam GrokBota i Claude Code do wyrabiania otwartych odpowiedników aplikacji, z których korzystam — na przykład TradingView. Repozytorium REA podałem agentowi; link będzie w opisie, a skoro jest teraz numerem jeden na GitHubie, łatwo je znajdziecie. GrokBot dostał polecenie: uruchamiaj na mojej sieci sesje Claude Code i przebuduj TradingView, Screen Studio, OBS oraz Paper.

W mojej sieci pracuje kilka maszyn: VPS, MacBook Pro, laptop Framework, komputer z Linuksem i drugi MacBook. GrokBot działa na moim osobistym MacBooku i ma dodatkową instrukcję — tzw. skill — z opisem sieci: wie, że może wybrać bezczynną maszynę albo tę z największą ilością wolnej pamięci. I właśnie to zrobił: uruchomił sesję Claude Code na jednym z komputerów. W logu widać: „Ustawiam to na maszynie z macOS — jest wolna, a ten build wymaga Maca”. A dalej: „Claude Code najpierw rozpisze wszystkie funkcje Screen Studio — autozoom, wygładzanie kursora, tła, nakładkę z kamerą, edytor osi czasu, eksporty — a potem zbuduje całość w Ruście na szybkim silniku nagrywania REC. Dam znać, gdy sesja ruszy.”

Efekt? Terminal — mój odpowiednik TradingView, w całości napisany w Ruście. Wszystkie te aplikacje są tak szybkie, tak płynne, że aż przyjemnie się ich używa. Za TradingView już nie zapłacę, bo mam własną wersję — a inwestowanie to moja pasja, więc tę aplikację faktycznie będę utrzymywał.

Glide narodziło się z wpisu na Twitterze: ktoś zapytał, czy zbuduję Screen Studio w Ruście. Odpowiedziałem „jasne” — kilka promptów z GrokBotem i Claude i gotowe. Interfejs nie jest tak ładny jak w oryginale, ale wszystko działa tak samo. REC, od „recording”, nagrywa właśnie ten film. A paper-rs to odpowiednik Paper z serwerem MCP, do którego podłącza się mój agent, żeby tworzyć projekty.

Prompt, którego użyłem, brzmiał — przyznaję, okropnie — mniej więcej tak: „Użyj REA i zrób inżynierię wsteczną Screen Studio. Chcę pełnej zgodności funkcji. Chcę w pełni otwartego, super szybkiego odpowiednika w Ruście. Weź Claude Code Opus w trybie extra high i użyj komendy /code, żeby to domknąć”. Nawet z takim promptem zadziałało. Wszystkie te aplikacje są open source na moim GitHubie — link w opisie.

REA w produktach, które mają klientów

Doprecyzujmy: nie buduję w ten sposób całego swojego oprogramowania. GrokBota i Claude traktuję jako sposób na jednorazowe projekty, które chcę szybko sprawdzić. Gdy pracuję na poważnie i muszę mieć głowę całkowicie w zadaniu, używam T3 code. (Informacja dodatkowa: T3 code to nadrzędny harness do sterowania agentami kodującymi, zbudowany przez Thea i Juliusa; autor zapowiada o nim osobny film.)

REA posłużyło mi niedawno w dwóch produktach, które mają klientów: w Pluto i w Bezeli. Bezela zarabia realne pieniądze, co jest fantastyczne. Funkcje z innych programów trafiły dzięki REA do produkcyjnego kodu, z którego korzystają ludzie.

Pierwszy przykład: GrokBot ma przepięknie zrobiony czat — strumieniowanie, tempo odpowiedzi. Patrzcie: wysyłam „cześć, co słychać?” i agent odpowiada błyskawicznie, właściwie bez strumieniowania, tak szybko to działa. Chciałem tego dla Pluto. Użyłem więc REA, żeby rozebrać, jak GrokBot to robi. Oto scalony pull request — a w nim testy „przed i po”: czas odpowiedzi spadł z 50–170 milisekund do 17–33. Ta poprawa jest szalona i zawdzięczam ją temu, że REA odtworzyło mechanizm GrokBota, a ja przeniosłem go do Pluto. Do tej pracy użyłem T3 code, mojego ulubionego harnessu — budowanego przez Thea i Juliusa; szykuje się o nim osobny film, więc kliknijcie subskrypcję.

Druga sprawa: pewną fajną funkcję z Pluto po prostu przekopiowałem do Bezeli. Pewnie wystarczyłoby dać agentowi dostęp do obu repozytoriów, ale tak było zabawniej — a zadziałało.

Sedno: REA to nie tylko zabawa w Minecrafta i Elden Ring. Widzisz funkcję w cudzej aplikacji i chcesz ją odtworzyć albo zrozumieć, jak działa i jak to zrobiono — repo REA to obowiązkowy punkt wyjścia.

Skoro kod nie jest fosą, co nią jest?

Moim zdaniem fosą jest dziś dbałość. Powiem szczerze, bez owijania w bawełnę: te wszystkie aplikacje, które zbudowałem? Za dwa, trzy tygodnie pewnie mi się znudzą. Nie będę ich utrzymywał ani dopracowywał. Jeśli jakaś aplikacja naprawdę wiele znaczy w moim życiu — jak Terminal — to tak, zajmę się nią. Ale nie zamierzam robić otwartych wersji każdego programu, którego używam.

Kiedy mówię „software umarł”, nie twierdzę, że odtąd wszyscy będziemy korzystać z własnych, wygenerowanych przez AI wersji wszystkiego. Chodzi o coś innego: skończyły się czasy, w których wystawiasz aplikację do listy zadań i faktycznie zdobywasz użytkowników. Takie aplikacje są skończone. Większość software’u może być open source.

Kto więc się dziś wyróżnia? Ludzie, którym naprawdę zależy. Ci, którzy dopracowują. Którzy spędzają czas przy interfejsie i doświadczeniu użytkownika, szlifują każdy detal tak, że po prostu chce mi się zapłacić. Dbałość ma znaczenie. Wykończenie ma znaczenie. To, jak coś wygląda i jak się tego używa, ma znaczenie. I to jest dziś fosa.

Jeśli więc coś budujesz — mam nadzieję, że ci na tym zależy. Bo jeśli nie, to my — chłopaki i dziewczyny — przychodzimy z repo REA i agentem kodującym. I robimy z twojej aplikacji open source.

Szok i szansa

To świetny czas, żeby żyć. Wiem, że dla wielu osób, zwłaszcza programistów, to czas stresu — wręcz cios w zawodową tożsamość. Ale jeśli zamiast szklanki do połowy pustej zobaczysz szklankę do połowy pełnej, zaczniesz dostrzegać, ile szans stoi przed tobą otwartych. Ja przynajmniej nie mogę się doczekać. Było świetnie. Nazywam się Ross. Dziękuję, że oglądaliście. Do zobaczenia w następnym filmie. Cześć.