O czym jest ten film
- Anthropic udostępnił Fable 5, a po około 48 godzinach rząd USA wymusił wycofanie modelu — w chwili nagrywania nadal nie da się z niego korzystać.
- Chris, twórca aplikacji produktywnościowych (Ellie — planowanie dnia, Amy — licznik kalorii), porównał go ze swoimi codziennymi narzędziami: Opusem 4.8 w trybie ultra oraz GPT 5.5 na ustawieniu extra high.
- Swój test opiera na stałej liście funkcji, z którymi wcześniej poległy wszystkie modele — każdy nowy model dostaje tę samą listę.
- Przeniesienie autorskiego systemu przeciągania z iPhone’a na iPada (wiele kolumn, ponad dziesięć przypadków brzegowych) Fable rozwiązał za pierwszym podejściem; Opus i GPT 5.5 wielokrotnie poległy.
- Funkcja przeciągania zadań z kalendarza z powrotem do tablicy Kanbana — w pięcioletniej, dziesięciotysięcznej linii ręcznie pisanego, kruchego kodu — wdrożona w dwóch zapytaniach; pięć godzin prób zepsucia nie wykazało błędów.
- Potwierdzenie z zewnątrz: usługa przeglądu kodu Greptile oceniała kod wytworzony przez Fable na 4–5 na 5 już przy pierwszym podejściu (własny kod autora zwykle dostaje trójkę).
- Test kreatywności w Amy: z mglistego polecenia model za jednym razem zbudował spadające emoji z poprawną fizyką i samodzielnie dobrał emotki związane z jedzeniem.
- Interpretacja autora: Opus i GPT „myślą” osiem kroków naprzód, Fable — około dwudziestu; różnica ujawnia się dopiero przy złożonych problemach oraz starych, kruchych bazach kodu.
- Haczyk: najwyższy tryb uruchamia podrzędne agenty, przez co pięciogodzinny limit sesji wyczerpywał się po około 45 minutach; próba przeniesienia Amy na Androida przerwała się w pół z braku limitu.
- Wniosek finansowy: drogi model opłaca się rezerwować dla garstki najtrudniejszych problemów, a o opłacalności decyduje pytanie „ile wart jest rozwiązany problem” — autor uważa rozgłos wokół modelu za uzasadniony.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Prowadź własną listę „pokonanych” problemów
Na czym polega: Autor nie testuje nowych modeli na wymyślonych zadaniach, lecz na stałej liście funkcji, z którymi wcześniej poległy wszystkie modele — dzięki temu porównania są powtarzalne i uczciwe.
Jak stosować: Zapisuj każde zadanie, którego nie udało się ukończyć (funkcja, refaktoryzacja, uciążliwy błąd), a po wypuszczeniu każdego nowego modelu przepuszczaj go przez tę samą listę w identycznych warunkach.
Na co uważać: Bez stałych warunków — te same ustawienia, ten sam kod, te same polecenia — porównanie pokazuje głównie szum.
2.O jakości modelu rozstrzygają przypadki brzegowe
Na czym polega: Przeciąganie zadań między kolumnami brzmi prosto, dopóki nie dochodzi ponad dziesięć wariantów: wiele kolumn, lista na pasku bocznym, blok czasu w kalendarzu. To właśnie na nich padały dotąd modele.
Jak stosować: Łącz w jednym zadaniu kilka mechanizmów naraz i obserwuj, czy model przewiduje konflikty między nimi z góry, czy łata je dopiero wtedy, gdy sam mu je wskażesz.
Na co uważać: Działająca pojedyncza ścieżka niczego nie dowodzi — sprawdź, czy naprawa jednego elementu nie psuje pozostałych.
3.Największa przewaga: stare, kruche bazy kodu
Na czym polega: Funkcja „przeciągnij z kalendarza do Kanbanu” blokowana była przez pięć lat przez dziesięć tysięcy linii ręcznie pisanego, wybitnie kruchego kodu i ponad pięćdziesiąt przypadków brzegowych — Fable wdrożył ją w dwóch zapytaniach.
Jak stosować: Jeśli masz kod historyczny, do którego nikt nie ma odwagi zajrzeć, zarezerwuj najmocniejszy dostępny model właśnie na niego.
Na co uważać: W nowych, małych projektach różnica względem tańszych modeli bywa niezauważalna — drogi model zużyjesz tam bez korzyści.
4.Nie ufaj pierwszemu podejściu — próbuj wynik zepsuć
Na czym polega: Autor nie uwierzył w sukces z dwóch zapytań i przez pięć godzin ręcznie szukał błędów oraz pominiętych wariantów. Dopiero bezskuteczność tych prób go przekonała.
Jak stosować: Po każdym zadaniu wykonanym przez model urządzić własną „sesję niszczenia”: rób rzeczy, których nie opisałeś w poleceniu, i sprawdzaj, czy mechanizm się wysypuje.
Na co uważać: Brak znalezionych błędów to nie dowód poprawności — to jedynie większa pewność, że nic oczywistego nie umknęło.
5.Dodaj niezależnego recenzenta kodu
Na czym polega: Automatyczny przegląd (tu: Greptile) oceniał kod z Fable na 4–5 na 5 już przy pierwszym podejściu, podczas gdy własny kod autora zwykle dostaje trójkę — to obiektywny sygnał jakości wyników modelu.
Jak stosować: Pracując samodzielnie, podłącz automatyczną recenzję każdego pull requesta i traktuj jej oceny jako miarę porównawczą jakości kodu z różnych modeli.
Na co uważać: Narzędzie ocenia kod, nie sens biznesowy zmiany — decyzja o wdrożeniu i tak zostaje przy tobie.
6.Koszt mierz w czasie sesji, nie tylko w dolarach
Na czym polega: W najwyższym trybie Claude Code uruchamia podrzędne agenty; pięciogodzinny limit sesji wyczerpywał się po 45 minutach, a jedno trudne zadanie potrafiło skonsumować go w całości.
Jak stosować: Zanim zaczniesz, oszacuj, ile takich zadań zmieści się w twoim limicie, i uruchamiaj je pojedynczo — równoległe wątki pochłaniają limit wielokrotnie szybciej.
Na co uważać: Testy odpalane „na zapas” mogą zostawić cię bez dostępu w połowie pracy.
7.Drogiego modela traktuj jak specjalistę od ostateczności
Na czym polega: Sam autor rezerwuje Fable dla „garstki brutalnych problemów”, z którymi najpewniej nie poradzą sobie Opus ani GPT — reszta pracy przechodzi przez tańsze modele.
Jak stosować: Podziel zadania na dwa strumienie: codzienne (tańszy model) i „niemożliwe” (najdroższy, używany świadomie i oszczędnie).
Na co uważać: Pokusa „niech zrobi to najlepszy” przy każdym zadaniu po prostu przepala budżet.
8.O opłacalności decyduje wartość rozwiązania
Na czym polega: Przy rozliczeniu API pytanie przestaje brzmieć „czy stać mnie na abonament”, a zaczyna „czy zapłacę X dolarów za wdrożenie tej funkcji”. Autor na swoje problemy odpowiada: tak, bo zmarnował na nie już grubo ponad tysiąc dolarów własnego czasu.
Jak stosować: Dla każdego zadania z listy oszacuj wartość (zaoszczędzony czas, przychód, oczekiwania użytkowników) i porównaj ją z prognozowanym kosztem zapytań.
Na co uważać: W projektach hobbystycznych, które nie zarabiają, próg opłacalności wygląda zupełnie inaczej — licz go osobno.
9.Mglisty prompt jako test inicjatywy
Na czym polega: Polecenie „logo ma być przyciskiem, a emoji mają spadać i odbijać się od paska” nie wskazywało ani emotek, ani klimatu — model z własnej inicjatywy dobrał emoji związane z jedzeniem, pasujące do aplikacji o kaloriach.
Jak stosować: Przy zadaniach kosmetycznych czy „fajerwerkach” zostaw celowo pewną swobodę i sprawdź, czy model dopełnia sens produktu, czy wymusza dookreślenia.
Na co uważać: W zadaniach krytycznych taka swoboda oznacza dodatkowe iteracje — tam precyzuj od razu.
10.Różnice między modelami widać dopiero nad progiem trudności
Na czym polega: Dla zadań wymagających trzech–pięciu kroków naprzód Opus i GPT 5.5 spisują się doskonale — stąd głosy, że „różnicy nie widać”. Fable odskakuje dopiero przy problemach z dwudziestoma krokami i dziesiątkami przypadków brzegowych.
Jak stosować: Zanim sięgniesz po najdroższy model, oszacuj złożoność zadania — większość codziennej pracy spokojnie zostanie przy tańszych.
Na co uważać: Pierwsze wrażenie z prostego testu bywa mylące — w obie strony.
Redakcyjne tłumaczenie
Model, który zniknął po 48 godzinach
W zeszłym tygodniu Anthropic opublikował Fable 5 — model, o którym wielu mówi, że to jeden z najpotężniejszych, jakie kiedykolwiek powstały. Niecałe dwie doby później zniknął. Rząd Stanów Zjednoczonych doprowadził do jego wycofania i w chwili nagrywania wciąż nie da się z niego korzystać.
O modelu zrobiło się głośno, więc pytanie, które słyszę najczęściej, brzmi: czy jest naprawdę taki dobry? Używałem go intensywnie przez te 48 godzin i wypychałem na maksimum możliwości. I powiem szczerze: tak, to moim zdaniem najlepszy model do programowania, z jakim pracowałem.
Nie zamierzam jednak tego tylko deklarować — pokażę trzy rzeczy, które w ciągu tych dwóch dób wdrożyłem, a z którymi nie poradziły sobie ani Opus 4.8 w najwyższym trybie ultra, ani GPT 5.5 na ustawieniu extra high, czyli — w powszechnym mniemaniu — dwa najlepsze modele do kodowania. Rozbierzemy też na części haczyk związany z Fable 5, a jest on spory. I najważniejsze: czy model będzie wart pieniędzy, gdy nieuchronnie wróci — zwłaszcza jeśli zapłacić przyjdzie według cennika API.
Kto testuje i na czym porównuje
Jeśli trafiłeś tu po raz pierwszy: jestem Chris i buduję aplikacje zwiększające produktywność. Zwykle jeden film poświęcam jednej aplikacji, ale dziś wyjątkowo bohaterem jest sam model.
Dla kontekstu: w codziennej pracy opieram się na dwóch modelach — Opus 4.8 w trybie ultra oraz GPT 5.5 na ustawieniu extra high, w obu przypadkach na najwyższych dostępnych nastawach. To moje dwa konie robocze, więc wszystko, co zrobiłem z Fable, odnoszę właśnie do nich.
(Informacja dodatkowa: Claude Code to narzędzie Anthropic, dzięki któremu modele Claude mogą pisać i modyfikować kod bezpośrednio w projekcie, m.in. z poziomu terminala.)
Jak testuję każdą nowość
Metodę mam od lat tę samą. Prowadzę aktualizowaną na bieżąco listę ambitnych funkcji, których nie udało się wdrożyć żadnemu modelowi — problem po problemie. Gdy pojawia się nowy, po prostu wystawiam mu całą listę. Tak było i tym razem: Fable dostał moje najtrudniejsze zadania.
Pierwszy sprawdzian: przeciąganie na iPadzie
Pierwszy problem to dość złożona obsługa przeciągania na iPadzie. Jedna z moich aplikacji, Ellie, służy do planowania dnia. W wersji na iPhone’a obsługuje całkiem skomplikowane gesty: zadania można przestawiać w kolejności oraz przeciągać z listy prosto do kalendarza. Zbudowałem ten mechanizm od zera, z własnymi animacjami i interakcjami — i na telefonie działa znakomicie. Jeśli przyjrzeć się bliżej, widać, że elementy zamieniają się miejscami płynnie, a całość reaguje natychmiast.
Ellie ma też wersję na iPada, ale jeśli mam być szczery — nie jest ona specjalnie udana. Powód jest prosty: zamiast autorskiego systemu przeciągania oparłem ją na gotowych mechanizmach, które Apple dostarcza razem ze SwiftUI, a to oznacza niewielką kontrolę — choćby nad podglądem przeciąganego elementu czy animacjami zamiany miejsc. Postawione obok siebie obie wersje różni właśnie to „coś”: na iPadzie mechanizm jest odrobinę nie na miejscu.
Od dawna chciałem przenieść mój system z telefonu na tablet. Próbowałem już z wieloma modelami — bezskutecznie. Ktoś mógłby rzec: przecież to aplikacja w Swifcie, wystarczy przenieść kod. Niestety, jest bardziej złożenie. Na iPhone’u jest jedna kolumna; na iPadzie może być ich wiele. Gorzej: zadania da się przeciągać między kolumnami, wrzucać do listy na pasku bocznym, a także chwytać wprost i umieszczać w bloku czasu. (Informacja dodatkowa: blok czasu, ang. „time box”, to w aplikacjach do planowania konkretne okienko zarezerwowane w kalendarzu na dane zadanie.) Przez to dochodzi ponad dziesięć przypadków brzegowych, które trzeba obsłużyć — i właśnie to czyni zadanie praktycznie niewykonalnym w jednym czy dwóch zapytaniach. Model nie może tu po prostu rozpoznać wzorca: musi przewidywać dziesięć posunięć naprzód, żeby domknąć całość i zabezpieczyć każdy wariant.
Próbowałem tego z Opusem 4.8 w trybie ultra, gdy tylko się pojawił — po dziesięciu zapytaniach miałem chaos. GPT 5.5 na extra high też poległ. Co prawda odtworzył przestawianie zadań w obrębie pojedynczej kolumny, ale przy wielu kolumnach wszystko się sypało. Gdy naprawiłem obsługę wielu kolumn, przestawało działać wrzucanie do bloku czasu; gdy naprawiłem blok czasu, znów psuły się kolumny. Przy tylu pułapkach coś wciąż pękało, aż w końcu odkładałem problem z powrotem na półkę.
Ten sam problem dostał Fable 5. I rozwiązał go za pierwszym podejściem. Byłem szczerze zaskoczony i — póki co — pełen niedowierzania, więc bardzo dokładnie przejrzałem jego robotę. Tym razem naprawdę działało. Serce mi podskoczyło i pomyślałem: jedziemy dalej w dół listy, podamy coś jeszcze trudniejszego.
Drugi sprawdzian: dziesięć tysięcy linii kruchego kodu
W wersji webowej Ellie można przeciągnąć zadanie z tablicy Kanban po lewej stronie do bloku czasu po prawej. Już samo w sobie jest to bardzo złożone, bo napędzają ten mechanizm dwie osobne biblioteki — jedna odpowiada za animacje przeciągania, druga za obsługę kalendarza — a zmuszenie ich do współpracy to koszmar. Ale to, co czyni zadanie naprawdę ciężkim, to kod. Napisałem go jakieś pięć lat temu, jeszcze przed erą AI, ręcznie. Ma około dziesięciu tysięcy linii i, mówiąc szczerze, jest słaby. Wyjątkowo kruchy: jedna zmiana i bardzo prawdopodobne, że trzy inne rzeczy natychmiast przestaną działać. Są tam trzy różne integracje kalendarzowe, zadania cykliczne, listy — mnóstwo elementów do uwzględnienia w systemie, który na pierwszy rzut oka wydaje się prosty.
I od lat marzę o jednej funkcji, o którą wołają też liczni użytkownicy. Dziś przeciąga się zadania z Kanbanu do kalendarza, ale nie w drugą stronę — a ludzie chcą wlec zadanie z kalendarza z powrotem na tablicę. W teorii brzmi to banalnie, ale przez ten koszmar kodu i ponad pięćdziesiąt przypadków brzegowych nigdy nie zdołałem tego dokonać, niezależnie od modelu. Jeśli przenoszenie systemu przeciągania na iPada wymagało myślenia dziesięć kroków naprzód, to tu powiedziałbym: dwudziestu.
Fable uporał się z tym w dwóch zapytaniach. To nie miało dla mnie sensu. Nie ufałem wynikowi ani trochę, więc przez następne pięć godzin mozolnie próbowałem go złamać: szukałem przypadków brzegowych, pomyłek, czegokolwiek. I nie znalazłem niczego. Wszystko wyglądało na działające. I wtedy to do mnie dotarło: ten model jest naprawdę inny.
Drugi zestaw oczu: kontrola kodu przez Greptile
Nie polegałem przy tym wyłącznie na własnym nosie. Jeśli śledzisz kanał, wiesz, że cały mój kod przeglądam narzędziem Greptile — i tu wielkie podziękowania dla nich za sponsoring tego filmu. Ale nawet gdyby nie byli sponsorem, to właśnie tę usługę polecam do przeglądów kodu.
Greptile to serwis recenzowania kodu wspomagany przez AI. Podłączasz swoje repozytoria, włączasz usługę — i każda propozycja zmian jest automatycznie sprawdzana. Narzędzie patrzy na nowy kod w kontekście całej bazy i stara się wyłapać realne problemy: błędy, pominięte warianty, regresje — a swoje uwagi zostawia bezpośrednio przy zmianach. (Informacja dodatkowa: mowa o tzw. pull requestach, czyli propozycjach zmian w kodzie czekających na przyjęcie do głównego projektu.)
Dla mnie to sprawa pierwszej wagi, bo jako deweloper pracujący w pojedynkę nie mam nikogo, kto czytałby mój kod. Greptile zastępuje mi drugi zestaw oczu i świetnie wyłapuje problemy. Każda propozycja zmian dostaje ocenę w skali pięciu punktów. Gdy pcham własny kod, w dziewięciu przypadkach na dziesięć pierwsze podejście dostaje trójkę — i to dobrze, bo znaczy, że coś został wyłapane i naprawione, zanim trafi do użytkowników. Piątka za pierwszym razem to rzadkość.
Tymczasem wszystko, co wdrożyłem z Fable — w tym dwie opisane wyżej funkcje — dostawało minimum czwórkę, a najczęściej piątkę już przy pierwszym podejściu. To był kolejny dowód, że Fable gra w innej lidze: system przeglądu, na którym polegam, nie znajdował w jego kodzie poważnych usterek.
A wracając do Greptile: w moim obecnym stosie technologicznym to absolutna konieczność. Link zostawiam w opisie; usługa jest darmowa do wypróbowania i nie wymaga podawania karty. Sama świadomość, że ktoś — choćby maszynowy — pilnuje mojego kodu, jest według mnie warta tej ceny.
Trzeci sprawdzian: kreatywność na surowo
Pierwsze dwa zadania opierały się na czystej złożoności. Teraz chciałem sprawdzić coś innego: ile w modelu kreatywności.
Mam aplikację Amy — licznik kalorii stylizowany na Apple Notes. Jeden z użytkowników zgłosił prośbę: „Nie dałoby się coś zrobić z logo?”. Dziś po tapnięciu nie dzieje się nic; kilku innych dopisało się głosami na tablicy feedbacku. Pomyślałem: zobaczmy, co Fable z tym zrobi.
Dałem mu celowo dość mglisty opis: „Zrób z logo przycisk. Po tapnięciu emoji mają spadać jak deszcz, respektować fizykę i odbijać się od złotego paska na dole”. Spodziewałbym się, że Opus albo GPT 5.5 by to załatwiły — ale w pięciu, sześciu podejściach, zwłaszcza żeby fizyka poczuła się dobrze. Fable trafił za pierwszym razem: fizyka poprawna, odbicia działały bez zarzutu. Stuknąłem w logo na oczach widzów — emoji sypały się w dół i odbijały od paska. Robiło to naprawdę wrażenie.
Ale to, co najbardziej mnie ucieszyło: ani słowem nie napisałem, jakich emotek użyć — a model z własnej inicjatywy dobrał wyłącznie emoji związane z jedzeniem. Utrzymuję, że inne modele też by to osiągnęły, tylko zajęłoby im owe pięć–sześć podejść.
Skąd ta różnica — i dlaczego część osób jej nie widzi
Po kilku godzinach pracy próbowałem zrozumieć, czemu ten model wydaje się inny — i czemu inni tego nie czują, bo spotkałem się już z opiniami w stylu „nie widzę różnicy między nim a Opusem”.
Najlepiej ująłbym to tak: modele takie jak Opus 4.8 czy GPT 5.5 potrafią myśleć może osiem kroków naprzód — co samo w sobie jest niezłe. Fable sprawia wrażenie modelu myślącego dwadzieścia kroków naprzód. Jakby wyprzedzał kształt problemu, zanim zdążę mu go pokazać. I to ma znaczenie tylko przy określonym typie zadań: błyszczy, gdy problem jest naprawdę złożony, wymaga pomysłowości, a zwłaszcza gdy pracujesz w ogromnej, skomplikowanej bazie kodu albo w bardzo starej i kruchej — takiej jak moja, napisana jeszcze przed erą AI.
Kiedy ktoś mówi, że nie czuje różnicy między Opusem a Fable, to najpewniej dlatego, że rzuca na model zadania wymagające trzech–pięciu kroków naprzód. Co ma sens — z takimi zadaniami Opus i GPT 5.5 radzą się znakomicie. Daj mu jednak coś, gdzie trzeba przewidzieć dwadzieścia posunięć, a różnica stanie się wyraźnie widoczna.
Resztę czasu przeznaczyłem na przenoszenie kolejnych funkcji na iPada, na zaległą optymalizację wydajności Ellie i audyt najstarszych zakamarków mojego kodu. Poszło znakomicie — to właśnie typ pracy, do którego Fable pasuje jak ulał. W Amy nie robił już na mnie takiego wrażenia, bo to projekt nowszy i mniejszy. Im większy bałagan w kodzie albo bardziej złożony system, tym jaźniej widać przewagę Fable.
Haczyk: limit wyczerpany w 45 minut
Porozmawiajmy o tym haczyku, bo Fable to zdecydowanie nie jest model, który można rzucić na wszystko.
Pracowałem na trybie ultra — najwyższym dostępnym w Claude Code. Zwykle mój pięciogodzinny limit sesji wyczerpywał się całkowicie już po 45 minutach, a bywało, że szybciej, gdy robiłem kilka rzeczy naraz. Powód: przy włączonym trybie ultra Claude Code sięga czasem po tzw. workflowy — uruchamia całą chmarę podrzędnych agentów, które robią robotę w twoim imieniu, co ogromnie zwiększa zużycie limitu.
To zadanie z wersji webowej — przeciąganie z kalendarza do Kanbanu — wykonywało się około 45 minut i pod koniec pięciogodzinne okno użycia wyparowało w całości. Znalazły się też rzeczy, których nie skończyłem właśnie przez limit. Próbowałem na przykład przenieść Amy na Androida, ale po pół godziny sesja była zużyta, a pracy nie poszło daleko. Bardzo chciałem tego spróbować — i nie zdążyłem, bo model wycofano.
Tak więc — jak zresztą, sądzę, nas uprzedzano — to model wyjątkowo drogi. Nie wrzucałbym do niego każdego zadania. Zostawiłbym go dla garstki brutalnych problemów, o których podejrzewasz, że Opus ani GPT 5.5 sobie z nimi nie poradzą.
Przelicznik: ile wart jest rozwiązany problem
To zmienia sposób, w jaki myślę o płaceniu za taki model. Fable nieuchronnie wróci — ale prawdopodobnie wyłącznie w rozliczeniu API. I wtedy w mojej głowie pojawia się jedno pytanie: czy zapłaciłbym tysiąc dolarów za wdrożenie tej konkretnej funkcji?
Problem przeciągania z kalendarza do Kanbanu, nad którym się męczyłem latami i o który od dawna wołają użytkownicy — czy zapłaciłbym za niego tysiąc dolarów? Prawdopodobnie tak, bo własnego czasu zmarnowałem na niego już grubo ponad tysiąc, a aplikacja realnie zarabia. Z biznesowego punktu widzenia rachunek się zgadza. A lepsza obsługa przeciągania na iPadzie w Ellie? W moim przypadku też chyba tak.
Podchodząc więc do Fable po jego powrocie, zmieniam sposób myślenia. Nie pytam już tylko „czy stać mnie na subskrypcję Claude Code”, tylko „czy zapłacę X dolarów za rozwiązanie tego problemu”. W moim przypadku — bo na aplikacjach zarabiam — odpowiedź będzie zwykle twierdząca. I podejrzewam, że w wielu firmach będzie podobnie.
Szczerze: po 48 godzinach z Fable powrót do Opusa 4.8 i GPT 5.5 trochę boli. I utwierdza mnie w przekonaniu, że zapłaciłbym X, żeby te problemy znikały w jednym–dwóch podejściach. Mam wrażenie, że będę żałował tych słów, ale cóż — jest, jak jest.
Werdykt
Czy więc całe zamieszanie wokół Fable jest zasadne? Moim zdaniem — po raz pierwszy — tak. Trochę przykro mi ulegać emocjom, ale po postawieniu modelu przed prawdziwymi problemami w prawdziwym kodzie uważam, że rozgłos jest w pełni zasłużony.
Na pożegnanie
To były moje 48 godzin z Fable. Jeśli wróci, mam nadzieję, że ten film pomoże ci zdecydować, czy warto za niego zapłacić. Jeśli podoba ci się taki rodzaj treści, zajrzyj na mój Instagram i TikTok — piszę tam niemal co drugi dzień o budowaniu aplikacji produktywnościowych. I oczywiście zapisz się na kanał. Dziękuję bardzo za obejrzenie — do zobaczenia w następnym filmie.