O czym jest ten film
- Autor dał modelowi Claude Fable jeden „goal prompt” z poleceniem zbudowania kompletnej firmy od zera — i dostał gotowy pakiet startowy.
- Efektem był landing page, działający produkt, dwa wideo launchowe, wideo od założyciela, biznesplan, badanie rynku i brand guidelines.
- Fable pełniło rolę wyłącznie menedżera-orkiestratora: planowało, delegowało i recenzowało, a całą pracę wykonywały setki podagentów (Opus/Sonnet).
- Kluczem był akapit prompta o „orkiestracji”: równoległy research, turnieje konkurujących pomysłów, panele sędziowskie, agenci-sceptycy i krytyk kompletności.
- Cały proces zjadł tylko ~500 tys. tokenów budżetu Fable, bo drogie „workery Fable” nie były użyte — pracowały tańsze modele.
- Firma nazywa się Counterbrief — narzędzie dla sklepów Shopify do wygrywania chargebacków realnymi dowodami zamiast szablonów.
- Powstanie produktu przebiegło w dziewięciu fazach: od polowania na ból rynku, przez turniej pomysłów, po red team i spakowanie.
- Model sam zweryfikował dostępność domeny, wygenerował logo w pętli krytyki, zaciągnął awatar i klon głosu autora do wideo.
- Całość zajęła 3–4 godziny — praca, która autorowi zajęłaby tygodnie.
- Wniosek autora: modele zbudują dziś prawie wszystko, o ile dostaną dobry pomysł i jasną definicję jakości; największy nacisk warto położyć na walidację samego pomysłu.
Redakcyjne tłumaczenie
Jeden prompt, cała firma
Dałem modelowi Claude Fable jeden „goal prompt” i kiedy skończył, miałem gotową firmę. Uruchomił setki agentów, przeprowadził mnóstwo weryfikacji i researchu, zrobił wideo, a na końcu dostałem landing page, produkt, wideo launchowe, biznesplan, badanie rynku, brand guidelines — masę rzeczy potrzebnych, żeby postawić biznes na nogi. Przejdę przez to wszystko i wyjaśnię prompt, ale najpierw rzućmy okiem na landing page.
Kiedy go otwieram, widać: Counterbrief — „win the disputes, templates lose” (Informacja dodatkowa: chargeback / dispute to sporne obciążenie zwrotne — reklamacja, w której klient żąda od banku zwrotu pieniędzy za transakcję kartą). Sam landing page nie jest niczym nadzwyczajnym, ale niektóre elementy są całkiem fajne. Spójrzcie na to wideo launchowe, które model dla mnie zrobił.
Ta dubstepowa końcówka jest trochę zaskakująca, ale fajne jest to, że interfejs, który widzieliście, wyglądał, jakby lekko synchronizował się z muzyką — miły akcent. I to jest realny produkt, który model zbudował. To Counterbrief — dashboard, na którym widać poszczególne spory, można je otwierać, sprawdzić, czy warto walczyć, czy odpuścić, przejrzeć wszystkie dowody.
To mówi mi, że Fable musiało wejść do tego produktu, poklikać, sprawdzić, że działa, ale też nagrywało ekran albo przynajmniej robiło zrzuty, a potem skleiło to wszystko z muzyką, grafiką w ruchu, kursorem myszy i efektami dźwiękowymi — i stworzyło nam to demo.
Wideo „od założyciela” — z moim awatarem i głosem
Schodząc niżej, po sekcji cennika, jest komunikat „dlaczego to istnieje” — notka od założyciela. Oczywiście tego nie nagrywałem. Treść brzmi mniej więcej tak: „Cześć, jestem Nate. Ciągle widziałem, jak właściciele sklepów Shopify przegrywają chargebacki, które powinni wygrać, bo narzędzie, za które płacą, wysyła bankowi tylko szablon. Więc zbudowałem Counterbrief. Wyciąga prawdziwe dowody z twojego sklepu — dane śledzenia przesyłki, maile, historię zamówień — i sam czytasz dokładny pakiet, zanim zrobi to bank. 19 dolarów, płaska stawka. Zatrzymujesz wszystko, wygrywasz”.
Fajne jest to, że model potrafił przejrzeć mój projekt, sprawdzić, co mam dostępne, jakie klucze API — i zaciągnął mój awatar Hen oraz mój klon głosu z 11 Labs, a potem zrobił z tego wideo od założyciela.
Stworzył też drugie wideo launchowe. Jedno nazwał „wiralowym” — to szybsze, bardziej jak demo produktu SaaS. Drugie było wolniejsze, oparte na lektorze: „Chargeback właśnie trafił do twojego sklepu. Bank już wierzy klientowi, a większość narzędzi odpowiada szablonem. Counterbrief zamiast tego buduje sprawę. Dane śledzenia, analiza fraudu, historia zamówień, własne maile klienta — złożone w dowody, które czytasz, zanim zrobi to bank. Zatwierdzasz. 19 dolarów płasko. Zatrzymujesz wszystko, wygrywasz”.
Prompt: „zbuduj mi całą firmę od zera”
Prompt, który mu dałem, brzmiał: „Przeczytaj ten plik i wykonaj wszystko poniżej linii podziału jako swój cel. Ten plik to twój pełny zestaw instrukcji — misja, guardraile, fazy, deliverables, definicja ukończenia. Trzymaj się go dokładnie, łącznie z regułą »nigdy nie pytaj«. Nie raportuj mi, dopóki definicja ukończenia nie jest spełniona. Zaczynaj”.
Zrobiłem to tak, bo — jeśli nie wiedzieliście — komenda /goal ma limit ok. 4000 znaków. Jeśli masz więcej, wrzucasz to do pliku i każesz modelowi go przeczytać. Wtedy praktycznie nie ma limitu znaków.
W samym pliku napisałem: „Zbuduj mi kompletną firmę od zera. Zacznij od niczego poza otwartym internetem. Znajdź prawdziwy, bolesny, niedostatecznie obsłużony problem, na który realni ludzie właśnie teraz narzekają, i zaprojektuj wokół niego biznes. Zbuduj produkt, markę i stronę, i wręcz mi gotowy pakiet, który mógłbym w tym miesiącu wprowadzić na rynek. Potem udowodnij mi, dlaczego to zadziała. To test tego, jak daleko potrafisz zajść sam. Nie będę odpowiadał na pytania w trakcie. Każdą decyzję podejmij sam, zapisz dlaczego i idź dalej w ramach guardraili. Masz pełną swobodę twórczą. Zaskocz mnie. Chcę zobaczyć twoją najlepszą pracę, nie najbezpieczniejszą”.
Dałem mu guardraile: żadnych nowych wydatków; to, co jest w kluczach API i w moim projekcie, jest do użycia; niczego nie publikuj — twórz wszystko lokalnie; niczego nie wymyślaj — musisz zrobić research i zweryfikować każdy fakt i każdą statystykę; pracuj w tym projekcie i nigdy o nic mnie nie pytaj.
Sekcja o orkiestracji zrobiła najwięcej
Zdefiniowałem też, co znaczy „orkiestrować”: agresywnie używać wieloagentowych workflowów. Rozdzielać równoległych researcherów po różnych źródłach i kątach. Prowadzić turnieje, w których niezależni agenci proponują konkurencyjne pomysły biznesowe, a panele sędziowskie je oceniają. Adwersaryjnie weryfikować każdą ważną tezę agentami-sceptykami, których jedynym zadaniem jest ją obalić. Używać krytyka kompletności, zanim uznasz jakąkolwiek fazę za skończoną. „Te wzorce to podłoga, nie sufit”.
Naprawdę uważam, że ten akapit zrobił najwięcej roboty. Po tym, jak to puściłem i obejrzałem na końcu, okazało się, że ledwie ruszyło mój limit Fable. Zużyło około 500 tys. tokenów — bo każdy podagent, którego uruchomiło, był modelem Opus albo Sonnet. I to jest w tym najfajniejsze.
(Informacja dodatkowa: autor odsyła do swojego wcześniejszego materiału o tym, „jak sprawić, by Opus myślał jak Fable” — chodzi o przeniesienie zasad orkiestracji na tańsze modele.)
Fable było menedżerem — orkiestratorem, który mówi: „Opus, zrób to i to, a jak skończysz, sprawdzę. Jeśli nie będzie wystarczająco dobre, każę ci poprawić”. I w ten sposób Fable zorkiestrowało to wszystko, zużywając może 15% mojego tygodniowego budżetu Fable i nie uruchamiając żadnych „workerów Fable”. Zjadło za to porządny kawałek limitu 5-godzinnego — pewnie 30–40% w moim planie Max za 200 dolarów miesięcznie. Nie twierdzę więc, że to było supertanie, ale jest imponujące, jeśli wziąć pod uwagę, że Fable samo niczego nie zbudowało. Fable tylko planowało, delegowało i recenzowało. Byłoby jeszcze lepiej, gdyby każdy worker też był modelem Fable — ale to byłoby 100 razy droższe.
Łuk narracyjny i definicja ukończenia
W prompcie zarysowałem też „łuk”: znajdź ból, wybierz zwycięzcę, zaprojektuj biznes, zbuduj markę, zbuduj produkt, zrób wideo launchowe, zrób wideo od założyciela, spróbuj to zabić, a potem spakuj. I znów — to podłoga, nie sufit. Definicja ukończenia była subiektywna: nieznajomy powinien móc otworzyć podsumowanie HTML, zrozumieć biznes, obejrzeć wideo, uruchomić stronę, przeklikać demo. „A teraz zbuduj mi firmę”.
Co faktycznie powstało
Podsumowanie HTML to główny deliverable, z resztą podlinkowaną na dole. Model wymyślił firmę Counterbrief, zaprojektował brand guidelines i logo. Produkt jest dla sklepów Shopify z co najmniej trzema sporami miesięcznie, w cenie 19 dolarów płasko za zatwierdzoną odpowiedź, bez success fee — zatrzymujesz 100% wygranych.
Od otwartego internetu do pakietu launchowego przeszło w dziewięciu fazach:
- Polowanie na ból. 10 agentów researchowych przeczesało Reddit, Hacker News, G2 i inne. Znaleźli 35 surowych problemów, scalili je w 18 kandydatów, a 18 niezależnych weryfikatorów ponownie pobrało każdy kluczowy cytat. Wszystkie 18 przetrwało.
- Turniej. Pięć person sędziowskich oceniło 18 okazji według bólu, pilności, dostępności klienta, gotowości do zapłaty, budowalności i słabości zasiedziałych graczy. Cztery najlepsze dostały po adwokacie i sceptyku. Trzech nowych sędziów zagłosowało i „chargeback evidence” wygrało 3:0.
- Projektowanie. Researcherzy przeanalizowali cenniki konkurencji, dokumentację platform, PDF-y z regułami Visy i referencje API.
- Marka. Sprawdzono, że counterbrief.com jest wolne (bez zakupu) i czyste kolizyjnie. Logo przeszło sześć generacji AI i pętlę krytyki, a zwycięzca został ręcznie zwektoryzowany — ostre od favikony po billboard. „Serif niesie argument, mono niesie dowody”.
- Build i wideo. Landing page z ofertą, potem oba wideo.
- Red team. Sześciu agentów-sceptyków zaatakowało wielkość rynku i inne założenia. Werdykt: „wykonalne z poprawkami”. Zero zabójstw, 38 ataków rozstrzygniętych, każda poprawka wdrożona do planu i strony. Na koniec — artefakty uczciwości i spakowanie całości.
W eksploratorze plików widać cały eksperyment: master prompt, „run one”, a w nim marka (lektor, skrypt, loga, brand guidelines, awatar, kandydaci na logo, eksporty w różnych rozmiarach), research (projekt biznesu, kandydaci, red team, turniej — wewnętrzne eksperymenty) oraz gotowe deliverables: biznesplan, launch plan, badanie rynku.
Biznesplan przechodzi przez problem, profil idealnego klienta, produkt, ofertę i cennik, ekonomię jednostkową, model biznesowy, kanały, pozycjonowanie, fosę i ryzyka — poszło całkiem głęboko. Badanie rynku pokazuje wszystkich kandydatów, dowody i ścieżkę zawężania do zwycięzcy.
Wniosek: dziś liczy się pomysł i definicja jakości
Najważniejsze, co chciałem pokazać: to zajęło trochę ponad 3–4 godziny. W 3–4 godziny doszliśmy do miejsca, które mnie samemu zajęłoby tygodnie. Patrząc wstecz, większy nacisk położyłbym pewnie na sam pomysł z przodu — na to, jak bardzo jest wykonalny, i na porządne stress-testowanie go, zanim wszystko zbudujemy. Bo chyba się zgadzamy: jesteśmy w punkcie, w którym Fable, a nawet Opus czy GPT 5.5 — jeśli użyjesz ich dobrze — zbudują ci praktycznie wszystko, o ile masz dobry pomysł i potrafisz jasno zdefiniować, co znaczy „dobre”.
Zaimponowała mi kreatywność i dokładność, oraz to, jak model potrafił zrozumieć ten dość niejednoznaczny cel z równie niejednoznaczną definicją ukończenia — i sam wyznaczyć drogę do celu. Ważne, żebyśmy pozwolili modelowi być kreatywnym i zeszli mu z drogi, żeby robił to, co robi naprawdę dobrze.
Wiem, że to szybszy film i nie super praktyczny tutorial — chodzi bardziej o eksperymentowanie z takimi rzeczami i wyciąganie z tego lekcji o tym, co jest możliwe. Jest tu mnóstwo rzeczy, które bym poprawił, ale funkcjonalnie działa to całkiem nieźle. Nie podoba mi się wygląd — i landing page, i produkt można mocno dopracować — ale wideo launchowe było naprawdę imponujące, tak jak pomysły i research z przodu. Może jesteśmy w 50% drogi i możemy dalej iterować. Co, gdybym po V1 zrobił kolejny goal prompt, wszedł w „run two”, dał modelowi cały feedback z pierwszego przebiegu i powiedział: „OK, teraz zrób to lepiej”? Na tym dziś skończymy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Model jako orkiestrator, nie wykonawca
Na czym polega: Najdroższy model (Fable) pełni tylko rolę menedżera: planuje, deleguje i recenzuje, a właściwą pracę wykonują liczne, tańsze podagenty (Opus/Sonnet). Dzięki temu cały projekt zjadł ok. 500 tys. tokenów budżetu głównego modelu.
Jak stosować: Projektuj workflow tak, by drogi model rozdzielał zadania i sprawdzał wyniki, a masę wykonawczą przenieś na tańsze modele. To radykalnie obniża koszt bez utraty jakości koordynacji.
Na co uważać: Jakość końcowa zależy od tego, jak dobrze orkiestrator recenzuje. Autor przyznaje, że gdyby workery też były Fable, wynik byłby lepszy — ale ~100× droższy. To świadomy kompromis koszt/jakość, nie darmowy obiad.
2.Akapit definiujący „orkiestrację” niesie najwięcej wartości
Na czym polega: Autor przypisuje sukces jednemu akapitowi: równoległy research, turnieje konkurencyjnych pomysłów, panele sędziowskie, agenci-sceptycy obalający tezy i krytyk kompletności przed zamknięciem fazy.
Jak stosować: Wpisz do prompta konkretne wzorce wieloagentowe zamiast ogólnego „użyj agentów”. Nazwij role: researcher, sędzia, adwokat, sceptyk, krytyk kompletności — model odtworzy tę strukturę.
Na co uważać: Zaznacz, że wzorce to „podłoga, nie sufit”, by nie ograniczyć modelu. Bez adwersaryjnej weryfikacji (sceptycy, którzy mają obalać) łatwo dostać ładny, ale niesprawdzony wynik.
3.Obejście limitu znaków prompta przez plik
Na czym polega: Komenda /goal ma limit ok. 4000 znaków. Autor wrzucił pełny brief do pliku i w krótkim prompcie kazał go przeczytać i wykonać wszystko poniżej linii podziału.
Jak stosować: Długie, złożone instrukcje trzymaj w pliku (misja, guardraile, fazy, deliverables, definicja ukończenia) i wskazuj na niego z prompta. Praktycznie znosi limit znaków.
Na co uważać: Plik musi być jednoznaczny i uporządkowany — model wykona go dosłownie, łącznie z regułami typu „nigdy nie pytaj”. Błąd w briefie propaguje się na cały przebieg.
4.Reguła „nigdy nie pytaj” wymusza autonomię
Na czym polega: Autor jawnie zabronił zadawania pytań w trakcie i kazał modelowi podejmować każdą decyzję samemu, zapisując uzasadnienie i idąc dalej.
Jak stosować: Gdy chcesz przebieg bez nadzoru, dodaj regułę „nie pytaj, decyduj sam i dokumentuj decyzje”. Poproś o zapis uzasadnień, żeby móc je potem zweryfikować.
Na co uważać: Autonomia działa tylko w mocnych guardrailach (żadnych wydatków, nic nie publikuj, tylko lokalnie, weryfikuj każdy fakt). Bez nich model może podjąć nieodwracalne lub kosztowne decyzje.
5.Adwersaryjna weryfikacja i turnieje pomysłów
Na czym polega: Pomysły przeszły turniej: pięć person sędziowskich oceniło 18 okazji według jasnych kryteriów, a finaliści dostali adwokata i sceptyka, zanim padł werdykt. Osobny red team przeprowadził 38 ataków na gotowy plan.
Jak stosować: Zamiast prosić o „najlepszy pomysł”, każ modelowi wygenerować wiele opcji, ocenić je wg zdefiniowanych kryteriów i skonfrontować adwokata ze sceptykiem. Kryteria (ból, pilność, gotowość do zapłaty, budowalność) podaj wprost.
Na co uważać: Weryfikacja jest tak dobra, jak kryteria i jak realne źródła. „Zero zabójstw, wykonalne z poprawkami” to werdykt modelu o samym sobie — nie zastępuje niezależnej walidacji rynkowej z prawdziwymi klientami.
6.Model wykorzystuje zasoby, które już masz w projekcie
Na czym polega: Fable przejrzało projekt, znalazło dostępne klucze API oraz awatar autora i klon głosu z 11 Labs, i użyło ich do zbudowania wideo od założyciela.
Jak stosować: Udostępnij w projekcie zasoby, których model ma użyć (klucze, awatary, głosy, materiały marki) i pozwól mu je odkryć. Zyskujesz spersonalizowany output bez ręcznego podawania każdego elementu.
Na co uważać: To samo odkrywanie zasobów jest ryzykiem bezpieczeństwa — model widzi wszystkie klucze i dane w projekcie. Ograniczaj zakres i dbaj o zasadę „nic nie publikuj”, by uniknąć wycieków lub niechcianych akcji.
7.Weryfikuj fakty i zakazuj zmyślania
Na czym polega: Guardrail „niczego nie wymyślaj — zrób research i zweryfikuj każdy fakt i statystykę” doprowadził do tego, że 18 niezależnych agentów ponownie pobrało każdy kluczowy cytat, a domenę sprawdzono pod kątem dostępności i kolizji.
Jak stosować: Wpisz jawny zakaz konfabulacji i wymóg weryfikacji ze źródłami. Dla twierdzeń krytycznych dodaj osobny krok ponownego sprawdzenia przez niezależnego agenta.
Na co uważać: Weryfikacja podnosi wiarygodność, ale nie jest gwarancją — źródła jak Reddit czy blogi bywają zawodne. Kluczowe liczby (wielkość rynku, cennik) i tak sprawdź samodzielnie przed decyzjami.
8.Realny koszt: to nie jest tanie
Na czym polega: Przebieg zużył ~15% tygodniowego budżetu Fable i 30–40% limitu 5-godzinnego w planie Max za 200 dolarów miesięcznie. Autor wprost mówi, że „nie było to supertanie”.
Jak stosować: Planując wieloagentowe eksperymenty, licz się z realnym zużyciem limitów. Rezerwuj takie przebiegi na zadania o dużej wartości (research, prototyp całego produktu), nie na drobiazgi.
Na co uważać: Koszt rośnie gwałtownie, jeśli podniesiesz model workerów. Zanim skalujesz, oszacuj, ile faz naprawdę wymaga najdroższego modelu, a ile obsłuży tańszy.
9.Wynik jest szkicem w 50%, nie produktem końcowym
Na czym polega: Autor jest zadowolony z funkcjonalności, ale krytyczny wobec wyglądu landing page’a i produktu; szacuje, że jest „w 50% drogi” i planuje kolejny przebieg z feedbackiem.
Jak stosować: Traktuj taki output jako bogaty punkt startowy do iteracji, nie gotowy launch. Zaplanuj „run two”: zbierz uwagi z V1 i podaj je jako wejście do kolejnej rundy poprawek.
Na co uważać: Efektowne demo (wideo, brand) może maskować słabości (design, realna wykonalność biznesu). Nie myl imponującej prezentacji z gotowością rynkową.
10.Największa dźwignia to walidacja pomysłu, nie budowa
Na czym polega: Wniosek autora: modele zbudują dziś prawie wszystko, o ile masz dobry pomysł i jasno zdefiniujesz, co znaczy „dobre”. Patrząc wstecz, więcej wysiłku włożyłby w stress-testowanie pomysłu przed budową.
Jak stosować: Zanim zlecisz budowę całości, poświęć osobną, intensywną fazę na weryfikację samego pomysłu — dowody popytu, gotowość do zapłaty, słabość konkurencji. Dopiero potem buduj.
Na co uważać: Łatwość budowy usypia czujność: skoro można zbudować wszystko, rośnie ryzyko dopracowania złego pomysłu. Definicja „dobrego” i definicja ukończenia muszą być konkretne, bo niejednoznaczny cel daje niejednoznaczny wynik.