O czym jest ten film
- Repozytorium reverse-engineer-anything bije rekordy popularności na GitHubie (192 tys. gwiazdek i rośnie na oczach); Matthew Berman podsumował nastrój żartobliwym „software jest skończony”.
- Idea narzędzia: agent bada funkcję istniejącej aplikacji i odtwarza ją we własnym projekcie, korzystając z gotowych ram postępowania.
- Teza autora: koncepcja nie jest nowa — on sam od dawna „dekompiluje” efekty końcowe; AI nie wymyśla od zera, ale znakomicie odwzorowuje jasno pokazany wzorzec.
- Przykład własny: skill do montażu rolek na Instagramie, wytrenowany na trzydziestu najlepszych filmach analizowanych klatka po klatce — efekt niemal identyczny z montażem ręcznym.
- Zasada nadrzędna: pokazane przykłady działają jak bardzo szczegółowy dokument wymagań (PRD); agent z ogólnym celem zwróci ogólny wynik.
- Zbudowane z repozytorium: funkcjonalny klon Looma (bez kopiowania interfejsu), własna wersja Sandcastles oraz studio do ewaluacji automatyzacji inspirowane Langfuse.
- Metafora ciasta z piekarni: dekompilacja to rozkładanie gotowego efektu na części i iterowanie, aż trafi się w rezultat.
- Pięć kroków pracy: wybierz funkcję, dopasuj ścieżkę do technologii, najpierw podsumowanie, rozróżniaj widziane/wywnioskowane/nieznane, odbuduj i przetestuj.
- Ograniczenia: nie kopiuj kodu ani zasobów, badaj tylko to, co dostępne; efekt zależy od modelu — ale raz wykonana analiza pozwala tańszemu modelowi dokończyć budowę.
- Wniosek szerszy: odwrotną inżynierię stosuj też do procesów i umiejętności — znajdź sprawdzony wzór, zrozum, dlaczego działa, i przenieś mechanikę do własnego kontekstu.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Pokaż wzór zamiast opisywać efekt słowami
Na czym polega: AI słabo radzi sobie z wymyślaniem od zera, ale świetnie odwzorowuje konkretny przykład. Autor zbudował skill montujący jego rolki, każąc agentowi obejrzeć trzydzieści najlepszych filmów i przeanalizować je klatka po klatce — wynik był niemal nie do odróżnienia od montażu ręcznego.
Jak stosować: zanim poprosisz agenta o cokolwiek twórczego, zbierz 3–5 wzorów oczekiwanego efektu i każ je rozłożyć na czynniki pierwsze: co się dzieje, w jakiej kolejności i dlaczego to działa.
Na co uważać: opis w stylu „ma mieć taki klimat i takie przejścia” nic nie da — bez wzorca dostaniesz wynik bez wyrazu.
2.Wskazany wzorzec to gotowy dokument wymagań
Na czym polega: pokazanie agentowi konkretnej aplikacji, raportu czy strony zastępuje wypisywanie szczegółowej specyfikacji (PRD). Wzór staje się specyfikacją: „patrz na tę aplikację — to twoje zadanie”.
Jak stosować: zamiast pisać wymagania, wskaż materiał odniesienia: „przeanalizuj te pięć raportów / ten landing / tę funkcję i odtwórz jej mechanikę”.
Na co uważać: agent przeniesie z wzorca wszystko, także rozwiązania przypadkowe — warto rozumieć wzór na tyle, by odrzucić to, co nie pasuje do twojej sytuacji.
3.Klonuj funkcjonalność, nie interfejs
Na czym polega: klon Looma zbudowany z REA wygląda zupełnie inaczej niż oryginał, ale odwzorowuje mechanikę: przesuwalny dymek kamery, odliczanie, zmianę rozmiaru okna w trakcie nagrywania. Nagrania lądują lokalnie zamiast w chmurze.
Jak stosować: wypisz funkcje, które naprawdę cenisz w narzędziu, każ je zbadać osobno, a wygląd zaprojektuj od nowa pod siebie.
Na co uważać: wierna kopia interfejsu, grafik i zasobów może naruszać prawa autorskie i znaki towarowe; bezpieczniejsza jest rekonstrukcja mechaniki.
4.Celuj w pojedyncze funkcje, nie w całą aplikację
Na czym polega: polecenie „oddaj mi całość Looma” jest za szerokie. Łatwiej wytypować kilka najlepszych funkcji — jak przy przebudowie CRM-a na bazie tego, co cenimy w Salesforce — i każdą zbadać osobno.
Jak stosować: posługuj się narzędziem przez jakiś czas, zanotuj funkcje, bez których nie chcesz się obejść, i tylko te przekaż agentowi do dekompilacji.
Na co uważać: analizowanie wszystkiego naraz rozdmuchuje kontekst i koszty, a wynik robi się przypadkowy.
5.Dopasuj sposób analizy do technologii, w której zbudowano aplikację
Na czym polega: REA zakłada tzw. routing według budowy — to, czym i gdzie aplikacja jest zbudowana (lokalnie, w chmurze, na jakim stacku), przesądza o narzędziach, jakimi agent powinien ją badać.
Jak stosować: nie musisz znać tych zależności sam — wystarczy zaznaczyć w prompcie: „uwzględnij technologię budowy i dobierz do niej metodę analizy”.
Na co uważać: bez takiej wskazówki agent może badać wszystko jedną, przypadkową ścieżką i przeoczyć istotne pliki.
6.Najpierw podsumowanie, potem zejście w szczegóły
Na czym polega: pełna analiza Looma zajęła ponad gigabajt. REA zamienia ją w czytelne streszczenie (co działa, jak i czego nie rozszyfrowano), a dopiero potem schodzi do modułów i śladów wykonania (traces). Wynik zapisuje lokalnie.
Jak stosować: wymagaj streszczenia przed budowaniem i pracuj na nim; po szczegóły sięgaj punktowo, tylko tam, gdzie trzeba.
Na co uważać: łatwo wpaść w kółko ponownego generowania całej analizy — pilnuj, by agent korzystał z wersji już zapisanej.
7.Rozdzielaj ustalenia: widziane, wywnioskowane, nieznane
Na czym polega: przy badaniu agent powinien oznaczać każdy wniosek jako „widziane” (znalezione i potwierdzone — jak 11 natywnych dodatków w Loomie), „wywnioskowane” (domniemania z kodu i danych) albo „nieznane” (tego, czego widać się nie da).
Jak stosować: każ przypisywać kategorie przy każdym ustaleniu i traktuj „wywnioskowane” jak hipotezy do zweryfikowania testem.
Na co uważać: jeśli zbudujesz na domniemaniach jak na faktach, błąd przejdzie w głąb projektu i wyjdzie w najmniej spodziewanym momencie.
8.Odbudowa to budowanie i testowanie, nie jednorazowe „wygląda na skończone”
Na czym polega: ostatni krok REA to iteracyjne stawianie własnej wersji na zebranych ustaleniach — z uruchamianiem przypadków testowych i poprawianiem tego, co nie działa.
Jak stosować: przed startem budowy przygotuj listę testów funkcjonalnych i wymagaj, by agent je wykonał oraz naprawił znalezione błędy.
Na co uważać: oddanie produktu po pierwszym działającym demo to najczęstsza pułapka — „zadziałało raz” nie znaczy „działa”.
9.Koszt da się obniżyć: badanie droższym modelem, budowa tańszym
Na czym polega: efekt końcowy zależy od modelu, który czyta i pisze kod, więc samo repozytorium nie czyni cudów. Ale raz przeprowadzone śledztwo to gotowa wiedza — tańszy model może na niej dokończyć budowę.
Jak stosować: rozdziel fazy — drogim modelem przeprowadź analizę, tańszym iteracyjną budowę i testy.
Na co uważać: przy złożonych funkcjach zejście za tanio zwykle kończy się debuggingiem, który pochłania całą oszczędność.
10.Odwrotna inżynieria dotyczy też procesów i umiejętności
Na czym polega: autor sprowadza całą sprawę do zasady szerszej niż oprogramowanie: znajdź kogoś, kto robi coś świetnie i ma na to dowody, zrozum, dlaczego to działa, i przenieś mechanikę do własnych procesów — raportów, montażu, codziennych skillów.
Jak stosować: w codziennej pracy z agentami pokazuj wzorcowy efekt (raport, film, wiadomość), zamiast opisywać ideał.
Na co uważać: mechanika przenosi się lepiej niż styl — to, co działa w cudzym kontekście, wymaga przystosowania do twoich danych i odbiorcy.
Redakcyjne tłumaczenie
Viralowe repozytorium i żart o końcu software’u
GitHubowe repozytorium reverse-engineer-anything właśnie wybucha popularnością. Matthew Berman streścił panujący nastrój krótko: „software jest skończony”. Powiedział to z przymrużeniem oka — narracja o końcu klasycznego programowania krąży w branży od ponad roku, odkąd na dużą skalę rozpowszechnił się vibe coding (Informacja dodatkowa: vibe coding — tworzenie oprogramowania niemal wyłącznie przez rozmowę z modelem AI, bez ręcznego pisania kodu). Ale w tym żarcie jest sporo prawdy.
Idea jest prosta: widzisz w jakiejś aplikacji funkcję, która ci się podoba, i twoje agenty — korzystając z ram opisanych w repozytorium — rozumieją, jak ona działa, a potem po prostu ją odtwarzają. Chcę dziś pokazać, jak to działa w praktyce i dlaczego moim zdaniem nie ma w tym nic odkrywczego. A skoro nie ma — jak tego używać i z jakim nastawieniem, żeby budować znacznie lepsze rzeczy.
Testy: gry, narzędzia, aplikacje
Spędziłem z tym repozytorium sporo czasu. Budowałem gry, oprogramowanie, różne narzędzia i aplikacje — potrafi robić wrażenie. W trakcie jednak doszedłem do wniosku, że niczego nowego nie odkrywa: robimy to od dawna, a ja z całą pewnością.
Patrzę na to tak: sztuczna inteligencja nie jest specjalnie kreatywna i nie umie wyjść poza utarte schematy. Jeśli jednak dostanie bardzo wyraźną wizję, wykona ją znakomicie. Przykłady, które zbudowałem na długo przed powstaniem tego repozytorium, pokazują, o co chodzi.
Dekompilacja własnego stylu montażu
Po lewej stronie ekranu moje rolki montowane ręcznie — obejrzyjcie ten klimat: przebitki, różne kolory czcionek, animowane poświaty, różne typy animacji. Żeby powstał skill, który dziś montuje moje rolki na Instagramie, kazałem agentowi obejrzeć trzydzieści moich najlepiej działających filmów. Po prawej efekt: praktycznie nie do odróżnienia — te same kolory, czcionki, animacje — a całość mieści się dziś w jednym skillu (Informacja dodatkowa: skill — pakiet instrukcji i procedur, które agent AI wykonuje jak przepis; termin spopularyzowany przez tzw. Claude Skills).
Sedno w tym, że nie powiedziałem: „zbuduj mi skill do montażu z takim klimatem i takimi przejściami”. Powiedziałem: „obejrzyj te filmy, przeanalizuj je klatka po klatce i zrozum, co siedzi pod maską”. W praktyce zdekompilowałem własny, ludzki styl montażu.
Przypadek Jordana Watkinsa
Kolejny przykład, tym razem z animacją. Jordan Watkins opublikował rewelacyjnie zrobiony film i skomentował: „Chętnie zobaczyłbym, jak AI spróbuje to odtworzyć”. Pomyślałem — sprawdźmy. Pobrałem nagranie, podałem je Opusowi i zleciłem: przeanalizuj klatka po klatce, zrozum, jak to działa i dlaczego właśnie tak, zbuduj na tym skill i pokaż, że potrafisz zmontować podobny film. Oryginał nadal wygrywa — w animacji i w oprawie dźwiękowej wciąż jest odrobinę lepszy. Ale Opus sam z siebie nigdy by na to nie wpadł. To zbyt oryginalny projekt, żeby wymyśliło go AI — Claude czy cokolwiek innego. Skoro pokazałem, czego chcę, i każałem to przeanalizować, wynik wyszedł o niebo lepszy.
Pokaż przykład, zamiast go opisywać
Od dawna powtarzam to samo, ilekroć mowa o budowaniu najlepszych skillów: trzeba robić odwrotną inżynierię efektu końcowego. Chcesz raportu piątkowego? Niech agent obejrzy pięć dobrych raportów piątkowych — i od razu wie dokładnie, czego od niego chcesz. Komunikowanie intencji musi być konkretne: agent z ogólnym celem zwróci ogólny wynik.
Cała idea reverse-engineer-anything — wskazania aplikacji do odtworzenia i skopiowania z niej funkcji — jest po prostu znacznie bardziej konkretna. W istocie wręczasz agentowi bardzo szczegółowy dokument wymagań produktowych (PRD), z tą tylko różnicą, że zamiast wypisywać specyfikację, mówisz: „patrz na tę aplikację — to jest twoja specyfikacja”.
Robiłem tak z landingami — zabierając elementy, animacje czy rozwiązania projektowe z cudzych stron; przykład zbudowany w Glide (Informacja dodatkowa: Glide — platforma no-code do szybkiego budowania aplikacji). Robiłem też z aplikacjami.
Klon Looma — funkcjonalność bez kopiowania wyglądu
Na ekranie mój klon Looma (Informacja dodatkowa: Loom — popularne narzędzie do nagrywania ekranu i szybkiego udostępniania nagrań), zbudowany właśnie z tego repozytorium. Kazałem agentowi obejrzeć Looma i zrozumieć, jak działa ruchomy dymek. Odliczanie przed nagraniem działa — kamerka nie pokaże nagrania twarzy, bo używam jej właśnie do tego odcinka, więc odpalam gotowy fragment. Pauzuję nagranie, wznawiam, przesuwam dymek, w trakcie nagrywania zmieniam jego rozmiar. Całkiem nieźle. Zatrzymajmy i zobaczmy, co z tego wychodzi.
Najważniejsze jest jednak to, że nie sklonowaliśmy Looma. Ta aplikacja wygląda zupełnie inaczej — nie skopiowaliśmy interfejsu ani elementów graficznych. Sklonowaliśmy funkcjonalność: jak działa dymek, jak się go przesuwa, jak zmienia się rejestrowane okno. Loom zapisuje nagrania w swojej chmurze; moja wersja trzyma pliki lokalnie, w aplikacji o nazwie Herc Recorder.
To samo zrobiłem z Sandcastles: kazałem agentowi obejrzeć funkcjonalność, zbadać, jak narzędzie działa i co robi — i dostałem własną wersję, do której wystarczyło podpiąć klucz API. Pomaga mi analizować treści na Instagramie, w tym moje własne. Podobnie powstało nasze AI SE Eval Studio do oceny automatyzacji: dużo czerpaliśmy z Langfuse (Informacja dodatkowa: Langfuse — platforma open source do śledzenia i ewaluacji aplikacji opartych na dużych modelach językowych) — rozgryźliśmy, jak działają, jak prezentują dane, jak uruchamiają procesy — i mamy własną wersję. Nie jest kalką; wybraliśmy najlepsze funkcje i zrozumieliśmy, jak oraz dlaczego działają.
Krótka wstawka: Scrollcraft
Wtrącę reklamę: rozdaję za darmo skill do projektowania stron. Korzystam z niego przy każdej witrynie, jaką buduję, łącznie z naszą stroną AI Automation Society, którą uwielbiam. Nazywa się Scrollcraft — rozumie animacje sterowane przewijaniem i pracę w warstwach, a do tego ma w sobie gust: typografię, odpowiednie odstępy, głębię. Po prostu bardzo dobry skill do projektowania stron, w całości darmowy. Link w opisie filmu. Wróćmy jednak do tematu.
Ciasto z piekarni, czyli istota dekompilacji
Wyjaśnijmy prosto, czym to właściwie jest. REA — reverse engineer anything — pomaga agentowi zbadać coś, a potem to zbudować. Najlepiej tłumaczy to przykład z piekarnią. Wyobraź sobie ciasto, które uwielbiasz i kupujesz co tydzień. Chciałbyś poznać przepis, ale on jest firmową tajemnicą piekarni — jej własnością intelektualną, której nie wydaje nikomu. Kupujesz więc ciasto: piekarnia oddaje ci efekt końcowy wytworzony według zamkniętego przepisu. A ty we własnej kuchni możesz ciasto rozkroić, posmakować, obejrzeć pod mikroskopem — i próbujesz odtworzyć przepis z gotowego wypieku.
To właśnie dekompilacja: degustacja, oględziny, rozbieranie na części, żeby ustalić, z jakich „bloków” i „liter” składa się ciasto. Potem zaczyna się seria prób i poprawek: pieczesz, porównujesz, poprawiasz — aż trafisz w efekt końcowy.
Przeniesione na Looma: mówisz agentowi „użyj reverse engineer anything i ustal, jak działa dymek kamery w Loomie, żebyśmy wpleśli to we własną aplikację do nagrywania ekranu”. Agent przegląda pliki i funkcjonalność, rozpatruje zebrane tropy, buduje własną wersję — a wy iterujecie, dopóki funkcjonalność się nie zgadza. I wychodzi to tak dobrze właśnie dlatego, że celujesz w konkretny efekt. Nie mówisz przecież „upiecz mi ciasto”, tylko „upiecz mi to konkretne ciasto — o takim smaku, takiej gęstości, z tym kremem i taką liczbą warstw”. To po prostu znacznie precyzyjniejsze zlecenie.
Nie cała aplikacja — pojedyncza funkcja
Dokument omawiający całą ideę udostępniam za darmo w naszej społeczności; podobnie drugi — o tym, jak wycisnąć z repozytorium najwięcej. Bo po zbudowaniu wielu rzeczy wiem jedno: trudno powiedzieć „zrób odwrotną inżynierię Looma”. Dużo łatwiej wybrać funkcje. Posługujesz się Loomem i w pewnym momencie myślisz: chcę to zbudować sam — które jego funkcje lubię najbardziej? Albo: przebudowuję CRM — które funkcje Salesforce naprawdę cenię? I to właśnie te wybrane funkcje agent bada, dekompiluje i przenosi do naszej aplikacji.
Niech agent zbada samo REA
Z ciekawości kazałem Claude Code, uzbrojonymu w ten framework, przeprowadzić odwrotną inżynierię samego repozytorium — żebym lepiej rozumiał, jak ono działa, lepiej nim kierował i lepiej instrukował agentów. Oto wynik: pięć kroków, o których warto myśleć, sięgając po REA.
1. Wybierz funkcję. O tym już mówiliśmy: nie celujemy w całą aplikację, lecz w konkretne zachowanie i funkcjonalność.
2. Dopasuj ścieżkę do budowy (route by build). Chodzi o to, czym aplikacja jest zbudowana — i o dobór narzędzi do tego, co zastaliśmy. Gdy już wiadomo, z jakim rodzajem oprogramowania mamy do czynienia i jak ono istnieje, można zmienić sposób, w jaki agent do niego podchodzi, tak by używał właściwych metod. Ja tych zależności nie znam na pamięć — po prostu dbam, by agent dostał w prompcie kontekst: „o stacku technologicznym musisz pomyśleć w takich kategoriach”.
3. Najpierw podsumowanie. REA analizuje całą aplikację i składa raport. Pełna analiza Looma zajęła ponad gigabajt — dlatego zamienia się ją w krótsze streszczenie, które Claude jest w stanie przeczytać w całości: co działa, jak dany element robi to, co robi, i czego jeszcze nie udało się rozgryźć. Dopiero potem analiza schodzi niżej, do modułów i śladów wykonania. Ważne: nie trzeba tego streszczenia generować od nowa — jest zapisane lokalnie w projekcie. To pułapka, w którą łatwo wpaść przy nieostrożnym instrukowaniu.
4. Widziane — wywnioskowane — nieznane. Gdy agent zaczyna drążyć, powinien oznaczać ustalenia jedną z trzech kategorii. „Widziane” to rzeczy faktycznie znalezione i potwierdzone — na przykład w Loomie jedenaście własnych, natywnych dodatków: agent je znalazł i rozumie, jak działają. „Wywnioskowane” to rzeczy, na które wskazują dane i kod, ale to w gruncie rzeczy przypuszczenie — nie mamy pewności. Ta kategoria jest kluczowa: jeśli przyjmiemy takie domysły za fakty i zbudujemy na nich dalej, możemy wpaść w niezłe tarapaty. Wreszcie rzeczy „nieznane” — tego, czego nie widać w natywnym rejestratorze ani w samej badanej aplikacji. I właśnie ten poziom porządku odróżnia pracę z REA od rzucenia agentowi: „Claude, obejrzyj tę aplikację, zbadaj ją i zbuduj taką”. Różnica w profesjonalizmie i uporządkowaniu procesu jest ogromna.
5. Odbuduj i przetestuj. Najważniejsza część każdego budowania. Bierzemy zebrane ustalenia i stawiamy na nich własną wersję — ale nie tylko stawiamy: iterujemy i testujemy. Agent ma uruchamiać przypadki testowe i faktycznie przetwarzać dane. Produkt nie jest „zbudowany i oddany”, tylko uruchomiony, sprawdzony i poprawiony — a nie wysłany raz, bo wydaje się skończony.
Granice prawne i praktyczne
Kilka uwag na koniec. Po pierwsze: nigdy nie kopiuj dosłownego kodu ani zasobów. Przy tak głębokiej inspekcji obowiązują granice prawne. Po drugie — i to wiele łagodzi — agent analizuje wyłącznie to, co już istnieje i co można legalnie pozyskać. Nikt nie każe mu włamywać się na serwery Looma czy do cudzej, zamkniętej bazy kodu; zresztą pewnie i tak by się nie dostał. Agent bada to, co widzi w twoich lokalnych plikach albo co udostępnia API — po prostu ogląda, jak coś działa i co już tam jest. Dekompilacją ludzie zajmują się od dawna, bo te rzeczy są publiczne i leżą w zasięgu ręki. Tylko człowiek robi to znacznie wolniej niż agent — a szczerze mówiąc, większość ludzi (ja z pewnością) nie przeczytałaby całego kodu i wszystkich śladów, a już na pewno nie zbudowałaby na tym własnej aplikacji.
Po trzecie: różne aplikacje wymagają różnego przygotowania — zależnie od tego, gdzie „mieszkają” i na jakim są stacku. Po czwarte wreszcie: efekt zależy od modelu, który czyta i pisze kod. Nie można zakładać, że samo podpięcie repozytorium sprawi, że AI zbuduje wszystko magicznie. Ale jest w tym i dobra wiadomość. Załóżmy, że budowałeś coś w Opusie 5.5 i chciałbyś spróbować z tańszym Sonnetem 5.5, na co wcześniej było go nie stać. Jeśli Sonnet dostanie całą wiedzę zgromadzoną podczas śledztwa, może teraz zbudować to samo — a wychodzi to dużo taniej niż praca wyłącznie na Opusie.
Wolniej, ale o niebo lepiej
Ciekawostka: dałem dwóm agentom ten sam prompt — jeden z repozytorium, drugi bez. Ten bez zawsze kończył pierwszy. Ten z repozytorium pracował dłużej, ale wyniki miał o wiele lepsze, bo korzystał z ramek, które lepiej rozbierają problem na części. Ten cały śledczy charakter REA — to on czyni projekt tak popularnym. Repozytorium bije rekordy: 192 tysiące gwiazdek. Odświeżam stronę — 195? 196 tysięcy? A ostatni raz patrzyłem jakieś pół godziny temu.
I jeszcze jedno: agenty kodujące będą w tym po prostu coraz lepsze. Skoro framework robi furorę na X, nic mnie nie zdziwi, gdy kolejne wersje Opusa, Fable, Astry, Soula i pozostałych modeli będą miały coś podobnego wbudowane od razu.
Podsumowując: bardzo porządne narzędzie. Realnie pomaga ludziom bez formalnego przygotowania inżynierskiego budować rzeczy, które robią wrażenie profesjonalnych. A sama koncepcja nie jest nowa — najpewniej stosujesz ją w swojej pracy, nawet o tym nie wiedząc. Dajemy agentom znacznie dokładniejszy PRD bez bolesnego wypisywania dokumentacji, bo mamy pod ręką wzór: „to właśnie chcemy — teraz budujmy”.
Szersza lekcja: procesy, nie tylko aplikacje
Mam nadzieję, że po tym odcinku spojrzysz na odwrotną inżynierię szerzej. Nie chodzi tylko o odtwarzanie aplikacji — chodzi o procesy, umiejętności i wszystko, co dzieje się na co dzień w twojej firmie. Znajdź kogoś, kto robi coś naprawdę dobrze i ma na to dowody; zrozum, dlaczego mu to wychodzi; i przenieś tę mechanikę do własnego kontekstu, do własnych przepływów pracy.
Wszystkie materiały udostępniam w darmowej społeczności, a link do repozytorium znajdziesz w opisie filmu — można je też po prostu wyszukać w Google, na pewno wyskoczy jako pierwszy wynik. Jeśli wszystko miało sens, daj like’a — bardzo mi pomaga. Dzięki, że dotrwaliście do końca. Do zobaczenia w następnym odcinku.