O czym jest ten film
- Dostęp do modelu Fable 5 w ramach standardowej subskrypcji Claude wkrótce się kończy, a późniejsze korzystanie z niego będzie bardzo kosztowne.
- Zamiast panicznie zużywać ostatnie tokeny albo w ogóle z niego nie korzystać, autor proponuje „trzeci ruch”: wyciągnięcie z Fable jego najcenniejszej wartości, by móc jej używać także później.
- Kluczowa idea: nie proś Fable o zwykłe plany — proś o „wargaming”, czyli symulację misji ruch po ruchu z uwzględnieniem błędów i przeciwdziałań.
- Przy tak zdolnym modelu ograniczeniem nie jest już inteligencja, lecz to, czego nie wie sam orkiestrator — zwłaszcza „nieznane nieznane”.
- Wargaming opiera się na pętli: akcja → reakcja (rzeczywistość rzuca błąd) → kontrakcja — czyli współczesna pętla agentowa.
- Efektem są „blueprinty”, które można podać tańszym modelom (Opus 4.8, GPT 5.5, GLM), by wykonały projekt pewniej, znając już zasymulowane scenariusze.
- Autor pokazuje konkretny szablon promptu „war-game order” i przykładowe misje (strona www, copywriting, lokalny setup AI, optymalizacja podatkowa itd.).
- Praktyczny workflow: folder z podfolderami (
tasks,wargames), plik kryteriów sukcesu i „ledger” na braki i niewiadome. - Wszystkie misje można uruchomić hurtowo, a następnie pętlą (
/loop) iteracyjnie dopracowywać, korzystając z równoległych agentów. - Można dodatkowo dostroić wargame do konkretnego modelu wykonawczego (np. Sonnet 5), używając subagentów przeglądających jego dokumentację.
Redakcyjne tłumaczenie
Kończy się dostęp do Fable 5 — i większość ludzi zrobi to źle
Jeśli płacisz teraz za Claude, zostało ci kilka dni na używanie Fable 5 w ramach istniejącej subskrypcji — przynajmniej na razie. Potem większość z nas będzie z niego korzystać rzadziej albo wcale, bo koszty są zabójcze. Widzę wokół dwie reakcje. Jedni panikują i przed upływem czasu rzucają setkami tysięcy tokenów na przypadkowe zadania. Drudzy wzruszają ramionami i i tak prawie z niego nie korzystają.
Celem tego materiału jest pokazanie trzeciego ruchu. Takiego, który bierze najcenniejszą rzecz, jaką znajduję w Fable 5, i pozwala z niej korzystać długo po tym, jak zniknie z twojej subskrypcji.
(Informacja dodatkowa: „Fable 5” to nazwa jednego z modeli z rodziny Claude; autor mówi o okresie, gdy droższy model przestaje być dostępny w cenie zwykłego abonamentu).
Wcześniej, zanim po raz pierwszy straciliśmy dostęp do Fable, opublikowałem film pokazujący, jak można przejrzeć wcześniejsze rozmowy i wyciągnąć z nich jego surową inteligencję. Ale dopóki wciąż go mamy, możemy go użyć w sposób, o którym praktycznie nikt nie mówi. I nie, nie chodzi o zbudowanie każdego pomysłu, jaki masz, ani o tworzenie prostych plików z planami. Chodzi o zbudowanie czegoś nieskończenie potężniejszego — czegoś, co daje niemal każdemu modelowi zdolność przejścia przez to, co zrobiłby Fable, i samodzielnego wykonania tego.
Jeśli więc chcesz spędzić ostatnie tokeny i czas z tym modelem w najlepszy możliwy sposób, zaczynajmy.
Dlaczego nie prosić Fable o planowanie
Jeśli przeczytasz oficjalne notatki wydania od Anthropic, przeczytasz, że Fable jest świetnym wykonawcą zadań o długim horyzoncie i że powinieneś dać mu plan przygotowany przez coś w rodzaju Opusa. Rzekomo nie powinieneś używać Fable do planowania, bo to marnowanie cennych tokenów.
I jeśli mówimy czysto o planowaniu, ta rada ma sens. To trochę tak, jakbyś przyprowadził najlepszego chirurga i poprosił go, żeby narysował ci schemat, jak zoperowałby pacjenta — zamiast po prostu pozwolić mu przeprowadzić operację.
Rozwiązaniem nie jest więc proszenie o lepsze plany. Rozwiązaniem jest niepytanie o plany w ogóle.
Nieznane nieznane — prawdziwe ograniczenie
Kilka dni temu jeden z czołowych inżynierów Anthropic opublikował cały artykuł o tym, jak używać modeli takich jak Fable, żeby zrozumieć niewiadome danego projektu. Główna myśl jest taka: przy tak zdolnym modelu nie ogranicza cię już surowa inteligencja. Ogranicza cię to, czego ty — jako orkiestrator, osoba dostarczająca instrukcje, plany i prompty — nie wiesz.
Kiedy zaczynamy projekt, zwykle całkiem nieźle ogarniamy „znane znane” oraz „znane nieznane”. Ale zwykle warto oprzeć się na inteligencji modeli takich jak Fable przy dwóch pozostałych kategoriach. Pierwsza to „nieznane znane” — wiedza ukryta (tacit knowledge), którą zakładasz, że model posiada, ale która przy całej jego inteligencji może nie sięgać twojego poziomu doświadczenia życiowego. Druga to „nieznane nieznane”, gdzie nawet nie wiesz, że dany obszar był wart zbadania czy zadania pytania.
Możesz więc w czasie, który ci pozostał, nakłonić modele takie jak Fable, by wydobyły te pytania i poprowadziły cię w miejsca, do których sam nigdy byś nie pomyślał zajrzeć.
(Informacja dodatkowa: podział „known knowns / known unknowns / unknown unknowns” to popularna rama analityczna spopularyzowana przez Donalda Rumsfelda; „unknown knowns” to autorskie rozszerzenie oznaczające wiedzę milczącą).
Czym jest „wargaming” zamiast planu
To jest sedno całego filmu — i nie zamierzam przejść przez to tylko koncepcyjnie. Pokażę praktycznie, jak to wdrożyć.
Zwykły plan, nawet stworzony przez model tak inteligentny jak Fable, zakłada liniowość — scenariusz „bezchmurnego nieba”. Rozbija zadanie na fazy w bardzo logiczny sposób. Wygląda tak, jakby miał wysoką szansę powodzenia. Ale w rzeczywistości nie pokazuje, co się stanie, gdy sprawy pójdą nie po myśli.
Cały sens wargamingu polega na tym, że AI rozkłada każdy kierunek działania ruch po ruchu i każdy możliwy scenariusz, jaki może napotkać, na podstawie swojego wcześniejszego doświadczenia. Możesz to sobie wyobrazić jako trzy główne elementy: akcja, reakcja i kontrakcja. AI wykonuje ruch, rzeczywistość sprowadza je na ziemię, rzucając jakiś błąd, a potem AI musi podjąć jakąś kontrakcję, żeby ten błąd rozwiązać. I to właśnie nazywamy współczesną pętlą agentową.
Żeby to unaocznić: powiedzmy, że zbudowałeś całą platformę i chciałeś użyć Fable do dołożenia nowej funkcji, która pozwoli użytkownikom uderzyć w endpoint API i pobrać jakieś dane. Zwykły plan po prostu rozpisałby, jak zbudować ten endpoint. Wargame natomiast powiedziałby: „Użyj tego planu, ale załóż, że na każdym rozgałęzieniu pojawi się kilka możliwych scenariuszy. Na podstawie swojego doświadczenia — jak byś je obsłużył?”.
Jeśli masz to wszystko udokumentowane, to gdy podasz ten sam plan czemuś takiemu jak Opus 4.8, GPT 5.5, a może nawet bardzo zaawansowanemu modelowi open source jak GLM, prawdopodobnie znacznie łatwiej połączy on swoją własną „uprząż” (harness) ze zrozumieniem wszystkich możliwych realiów, które Fable już zasymulował — i wykona zadanie znacznie pewniej.
Konsekwencje wyższych rzędów — gdzie postawić granicę
Jak w każdej symulacji, trzeba zdefiniować koniec. Lubię to nazywać konsekwencjami drugiego, trzeciego i czwartego rzędu. To rzeczy, które mogą się wydarzyć kilka warstw w głąb od pierwotnej akcji. Nie chodzi więc tylko o zbudowanie strony, ale o przemyślenie wszystkich problemów wynikających z budowania jej w ten konkretny sposób — może dwa czy trzy różne scenariusze, które mogą się pojawić. I tu wkraczasz ty, decydując, jak daleko rozegrać dany scenariusz.
Po jednej stronie masz to, co większość ludzi będzie miała 8 lipca, gdy tymczasowo straci dostęp do Fable: serię planów, które doprowadziły budowę mniej więcej w 80%, a potem trzeba wrócić do czegoś w rodzaju Opusa 4.8 albo innego modelu, żeby dokończyć te 20% — które, jak na ironię, zwykle są najtrudniejsze do zrobienia. Po drugiej stronie możesz mieć serię projektów i swoich najtrudniejszych pomysłów w pełni zasymulowanych i „rozegranych” do tego stopnia, że możesz je uruchamiać do woli, kiedy zechcesz.
To była część koncepcyjna. Teraz przejdźmy do praktyki.
Anatomia promptu „war-game order”
Powiedzmy, że mamy 10 solidnych, obszernych pomysłów i projektów, przy których marzylibyśmy o nieograniczonym paśmie i tokenach, żeby Fable zbudował je od początku do końca. Nie przejdę szczegółowo przez każdy prompt — wszystkie udostępnię w drugim linku pod filmem — ale pierwszy omówię dokładniej.
Prompt zaczyna się tak: „War-game order. Nie wykonujesz tej misji, jedynie ją rozgrywasz (war-gaming)”. Model rozumie różnicę między planem a wargame’em. Możemy też powiedzieć mu, że tańszy model wykonawczy uruchomi poniższy brief. To bywa pomocne, bo możesz w zasadzie napisać: „To wykona Opus, więc śmiało przejrzyj całą dokumentację Anthropic o Opusie i dostrój ten prompt i ten wargame tak, żeby dobrze współgrał z tym modelem”. To jest rdzeń szablonu, wspólny dla wszystkich promptów.
Dalej: „Rozegraj misję na papierze, ruch po ruchu, i zapisz ją do pliku wargames/website.markdown”. Kluczowe jest to, że nie chcę, żeby wykonywał każdą z tych rzeczy osobno. Możesz przygotować wszystkie pliki wargame — czyli swoje prompty — i pozwolić Claude/Fable wykonać je wszystkie naraz, a potem przejść pętlą, żeby je ponownie przejrzeć, zredagować i zoptymalizować. Pokazuję ci to po jednym promptcie naraz, ale docelowo zrobisz to, co pokażę za chwilę — uruchomiłem wszystkie te pomysły jednocześnie, hurtowo.
Kontynuując prompt: każdy ruch podaje swoją oczekiwaną obserwację — dokładnie to, co powinieneś zobaczyć, jeśli zadziałało, i odwrotnie, co zobaczysz, jeśli nie zadziałało. Każdy ruch niesie więc swoją najbardziej prawdopodobną porażkę, przyczynę, jej sygnały i kontrruch. Zakłada, co może się stać — scenariusz pesymistyczny i optymistyczny.
Tam, gdzie modele takie jak Opus 4.8 zawodzą, są krótkowzroczne. Patrzą może na garść problemów. Potem trzeba wprowadzić coś w rodzaju Codeksa, żeby zajrzał im przez ramię i upewnił się, że robią to dobrze i przyjmują właściwe założenia.
Bardzo podobnie do przechodzenia przez labirynt: każde rozgałęzienie dostaje wyzwalacz — „jeśli zaobserwujesz X, to pójdź tą drogą, jeśli stanie się to, a inną, jeśli tamto”. Mówimy też: założenia, których twój rekonesans czy due diligence nie zdołał rozstrzygnąć — po prostu je nam oznacz. I kończymy poleceniem: zakończ warunkami przerwania (abort conditions) — w którym momencie plan powinien przestać się wykonywać, jeśli natrafi na określony typ błędu. Powiedzmy, że nie ma dostępu do jakiegoś systemu — to byłby pełny bloker dla realnego wykonania planu.
Brief misji na przykładzie strony www
Pod tym briefem misji rozpisujesz dokładnie, co próbujesz zrobić. W tym przypadku, dla strony marketingowej, mówimy: „Przebudowuję stronę marketingową dla [nazwa firmy], bo obecna ma [taki a taki problem]; odwiedzający to [twoja grupa docelowa, ICP], a chcę [wezwanie do działania]. Zbuduj kompletną statyczną stronę w dowolnym frameworku, oto sekcje, których chcę, oto URL-e i opisy. Chcę podejście mobile-first, a gdy uznasz, że skończyłeś, zweryfikuj, zanim zaraportujesz: otwórz każdą stronę, sprawdź każdy link” i tak dalej. W zasadzie mówisz, jakie ścieżki testowe ten wargame/plan ma uwzględnić.
(Informacja dodatkowa: ICP — Ideal Customer Profile — to profil idealnego klienta).
Każdy inny prompt wyglądałby bardzo podobnie: ten sam szablon na górze, brief misji na dole. Dla copywritingu wystarczy uzupełnić pola: dla kogo piszesz, jaki jest ICP, jaki jest stan mentalny osoby czytającej ten tekst, jaki jest głos marki — a potem: „chcemy rozpisać każdą sekcję, nagłówek” i tak dalej.
Zaskakujące zastosowania: lokalny setup AI, podatki, oferty
Oto zastosowanie, o którym być może nie pomyślałeś. Co, jeśli użyjesz Fable 5, żeby zaplanować budowę całego swojego lokalnego setupu AI? Bo jest dość oczywiste, że w niedalekiej przyszłości będziemy przerzucać coraz więcej zadań na modele open source i bardzo tanie modele, zamiast użerać się z całą tą dramą wokół dostępności Fable.
Twój prompt mógłby brzmieć tak: „Chcę w pełni lokalny setup AI, open source, na tej maszynie — prywatny domyślnie, nic nie opuszcza tego komputera”. Potem możesz pozwolić AI przejść przez twój system i sprawdzić wszystkie elementy: system operacyjny, rodzaj procesora, RAM, obecność GPU, wolne miejsce na dysku. A następnie: „skonfiguruj stack pasujący do tej maszyny, nie generyczny poradnik — dobierz runtime, przejdź przez wszystko”. Możesz nawet wskazać mu coś w rodzaju LM Studio i kazać ustalić najlepsze modele dla twojego konkretnego systemu oraz ile tokenów na sekundę byś osiągnął.
(Informacja dodatkowa: LM Studio to aplikacja do uruchamiania lokalnych modeli językowych na własnym komputerze).
A dalej — na przykład podatki. Możesz kazać mu przejrzeć wszystkie optymalizacje podatkowe, które już zrobiłeś w swojej firmie lub w firmie, w której pracujesz, i z perspektywy księgowego wskazać wszystkie sposoby na dalsze optymalizacje. To samo możesz zrobić dla prowadzenia ofert. Jeśli masz istniejącą aplikację czy platformę czatbotową — a mamy różne w mojej społeczności — to jak je zoptymalizować i wdrożyć w sposób, w którym pojawia się jakieś samouczenie na wszystkich błędach z przeszłości.
Możesz to zastosować do wszelkich przypadków: poprawiania błędów, modeli finansowych, analizy modeli konkurencji, optymalizacji sposobu ich używania, a nawet prowadzenia „rady doradców”, gdzie mieszasz i dobierasz użycie Claude, Codeksa i modeli open source.
Struktura folderów i uruchomienie hurtowe
Masz oczywiście nieograniczoną liczbę zastosowań. Ale gdy masz już swoją listę najpilniejszych projektów i pomysłów, przechodzisz do kolejnego kroku.
Tworzysz nowy folder — możesz go nazwać na przykład „Ostatni tydzień Fable”. W środku dzielisz go na podfoldery: tasks, wargames, plik z kryteriami sukcesu i plik „ledger”.
Plik sukcesu zawiera twoje kryteria — wspomniane mimochodem w powyższym promptcie — czyli co uznajesz za udany wargame. W pliku success.md mógłby to być zestaw reguł; twój może mieć ich więcej lub mniej, bardziej lub mniej rygorystycznych, albo bardziej szczegółowych.
Sensem „ledgera” jest wskazywanie miejsc, gdzie coś jest zablokowane. Jeśli podczas wargamingu pojawia się jakaś niezdefiniowana zmienna, model powinien wstawić w nawiasie placeholder zmiennej — coś, do czego potrzebuje twojego wkładu.
Na końcu wykonujesz prompt, który uruchomiłem jeszcze przed nagraniem tego filmu: /goal. „Każdy plik misji w /tasks ma pierwszy szkic wargame’u. Przejdź przez każdy, w pętli, wykonaj misję rekonesansu dla każdej misji, zapisz plik wargame — i przygotuj wszystkie 10 szkiców, zanim zaczniesz cokolwiek dopieszczać”. A gdy masz już te szkice, możesz teoretycznie uruchomić /loop co 20 minut, przechodząc pętlą przez każdy pierwszy szkic, aż naprawdę wyciśniesz go do granic.
Gdy to uruchomisz, rozwinie się seria równoległych agentów, które wykonają każde z tych zadań jednocześnie — tak że milion tokenów później możesz mieć w pełni wypełniony folder wargames. Możesz mieć nawet plik z założeniami (assumptions). Znajdzie się tam pełny plik markdown rozkładający każdą część zakładanych danych wejściowych, potrzebnego rekonesansu, różnych dróg, ruchów i rozważań w całym procesie. Bardzo kompleksowo — każdy możliwy ruch oraz towarzysząca mu akcja, reakcja i kontrakcja.
Teoretycznie masz więc 10 różnych blueprintów, które możesz podać dowolnemu AI, żeby wykonało te projekty. Jeśli ledger jest z jakiegoś powodu zablokowany, będzie wyglądał mniej więcej tak: powie ci, jakie dane wejściowe są potrzebne, żeby go odblokować — na przykład dla jakiego rodzaju biznesu to jest, jaki problem rozwiązujemy, kto jest odbiorcą, wszystko, czego nie doprecyzowałeś. W moim przypadku, ponieważ pokazuję to jako demo, poprosiłem model, żeby przyjął różne wartości dla tych zmiennych.
Dostrojenie wargame’u pod konkretny model
Jak wspomniałem, możesz przenieść to na wyższy poziom, oznaczając agenta typu „Claude Code Guide” i mówiąc: „Chcę, żebyś dostroił ten wargame dokładnie do tego, jak wykonałby go Sonnet 5”. Bardzo dopasowane do jego konkretnego zachowania. To uruchomi subagenta lub subagentów, którzy przejdą przez całą dokumentację, może kartę systemową (system card) tego modelu, żeby wszystko było jak najlepiej pod niego dopasowane.
(Informacja dodatkowa: „system card” to publikowany przez producenta dokument opisujący możliwości, ograniczenia i zachowania danego modelu).
I to właściwie tyle. To nie jest fizyka jądrowa, ale to wzięcie paradygmatu planowania i doprowadzenie go do naturalnej skrajności — tak, żebyś mógł wziąć całą korzyść i surową inteligencję Fable, wyciągnąć z niego, jak zrobiłby daną rzecz, i po prostu odtworzyć to z istniejącymi, znacznie tańszymi modelami, które — miejmy nadzieję — nie znikną ot tak, za pstryknięciem palców.
Udostępnię ci pod filmem wszystkie pokazane prompty wraz z tą strukturą folderów, żebyś mógł ją odtworzyć, jeśli zechcesz.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zamień plany na „wargaming”
Na czym polega: Zamiast prosić model o liniowy plan, każ mu rozegrać misję ruch po ruchu, przewidując dla każdego kroku obserwacje sukcesu i porażki oraz kontrruchy. To przenosi wiedzę o możliwych błędach do dokumentu, zanim ktokolwiek zacznie budować.
Jak stosować: W promptcie wyraźnie napisz „nie wykonujesz tego, tylko rozgrywasz”, wymagaj dla każdego ruchu oczekiwanej obserwacji, najbardziej prawdopodobnej porażki, jej sygnałów i kontrruchu, oraz warunków przerwania na końcu.
Na co uważać: Wargame to nadal symulacja oparta na doświadczeniu modelu — nie jest gwarancją. Musisz sam zdecydować, jak głęboko rozgrywać scenariusze, bo w nieskończoność można rozgałęziać każdą ścieżkę.
2.Wyciągnij wartość z drogiego modelu, zanim stracisz dostęp
Na czym polega: Najcenniejsze w silnym modelu jest to, „jak” rozwiązałby problem, a nie sam gotowy artefakt. Zapisując tę wiedzę jako blueprint, korzystasz z niej także po utracie dostępu.
Jak stosować: Póki masz dostęp do mocnego modelu, użyj go do wygenerowania wargame’ów swoich najtrudniejszych projektów, a wykonanie zostaw tańszym modelom.
Na co uważać: Nie rzucaj tokenów na przypadkowe zadania „na zapas”. Najpierw ustal listę realnie pilnych projektów, a dopiero potem generuj blueprinty.
3.Twoim ograniczeniem jest wiedza orkiestratora, nie inteligencja modelu
Na czym polega: Przy bardzo zdolnych modelach wąskim gardłem staje się to, czego ty nie wiesz — zwłaszcza „nieznane nieznane” i wiedza milcząca, której model może nie posiadać.
Jak stosować: Proś model wprost o wypisanie założeń, których nie potrafi rozstrzygnąć, i pytań/obszarów, o których sam byś nie pomyślał. Traktuj to jako rekonesans niewiadomych.
Na co uważać: Model może z pewnością siebie „wypełnić luki” błędnymi założeniami. Wymagaj oznaczania niepewności (placeholdery, ledger), zamiast pozwalać mu zgadywać po cichu.
4.Buduj blueprinty przenośne między modelami
Na czym polega: Dobrze rozegrany wargame można podać innym modelom (Opus 4.8, GPT 5.5, GLM), które połączą swoją własną „uprząż” z gotową mapą scenariuszy i wykonają zadanie pewniej.
Jak stosować: Pisz wargame w neutralnym, wykonawczo-agnostycznym formacie (markdown z ruchami, obserwacjami, kontrruchami), tak by dowolny model mógł go użyć jako instrukcji.
Na co uważać: Modele różnią się zachowaniem i narzędziami. Blueprint zaprojektowany pod jeden harness może wymagać drobnej adaptacji pod inny — nie zakładaj pełnej przenośności bez sprawdzenia.
5.Zaplanuj przejście na tanie/lokalne modele już teraz
Na czym polega: Autor zakłada, że coraz więcej zadań będzie przechodzić do modeli open source i lokalnych, żeby uniezależnić się od dramy z dostępnością drogich modeli.
Jak stosować: Użyj mocnego modelu, by przygotował plan lokalnego setupu AI dopasowany do twojego sprzętu (CPU, RAM, GPU, dysk), a nie generyczny poradnik — łącznie z doborem modeli i szacunkiem tokenów na sekundę.
Na co uważać: Wydajność lokalnych modeli mocno zależy od sprzętu; szacunki „tokenów na sekundę” traktuj jako punkt wyjścia do własnych testów, nie jako pewnik.
6.Wymuś weryfikowalne obserwacje i warunki przerwania
Na czym polega: Każdy ruch ma zdefiniowane „co zobaczysz, jeśli zadziałało / jeśli nie”, a cały plan ma warunki przerwania — moment, w którym wykonanie należy zatrzymać.
Jak stosować: Zawrzyj w każdym kroku konkretny, obserwowalny sygnał sukcesu i porażki oraz jasne blokery (np. brak dostępu do systemu), przy których plan ma stanąć.
Na co uważać: Bez warunków przerwania model wykonawczy może brnąć dalej mimo krytycznego błędu. Świadomie wypisz to, co powinno wstrzymać cały proces.
7.Generuj wszystkie szkice, zanim cokolwiek dopieszczasz
Na czym polega: Workflow zakłada najpierw stworzenie pierwszych szkiców dla wszystkich misji (np. 10), a dopiero potem ich polerowanie w pętli.
Jak stosować: Uruchom prompt typu /goal przechodzący przez wszystkie pliki misji i tworzący szkice, a następnie iteruj /loop (np. co 20 minut), by je stopniowo doszlifować.
Na co uważać: Uruchamianie równoległych agentów i pętli „milion tokenów później” bywa kosztowne. Kontroluj zużycie i ustal, kiedy jakość jest „wystarczająco dobra”, zamiast pętlić bez końca.
8.Uporządkuj pracę w jasną strukturę folderów
Na czym polega: Autor używa folderu z podfolderami tasks i wargames oraz plików kryteriów sukcesu i „ledger” na braki i niewiadome.
Jak stosować: Zdefiniuj w success.md własne kryteria udanego wargame’u, a w ledgerze niech model zapisuje placeholdery zmiennych, których potrzebuje od ciebie.
Na co uważać: Kryteria sukcesu i placeholdery są tak dobre, jak je zdefiniujesz. Zbyt luźne reguły dadzą powierzchowne wargame’y; przejrzyj ledger, zanim uznasz projekt za gotowy do wykonania.
9.Dostrój wargame do konkretnego modelu wykonawczego
Na czym polega: Wargame można dopasować do zachowania konkretnego modelu (np. Sonnet 5), używając subagenta, który przejrzy dokumentację i kartę systemową tego modelu.
Jak stosować: Powiedz z góry, który model wykona plan, i poproś o dostrojenie briefu pod jego specyfikę; ewentualnie użyj subagentów przeglądających oficjalną dokumentację.
Na co uważać: Dokumentacja modeli szybko się zmienia. Upewnij się, że subagent korzysta z aktualnych materiałów, bo dostrojenie pod nieaktualne zachowanie może zaszkodzić.
10.Pamiętaj, że to nadal symulacja „na papierze”
Na czym polega: Wargame nie wykonuje projektu — jedynie odwzorowuje, jak mocny model by go wykonał, żeby tańszy model mógł to potem odtworzyć.
Jak stosować: Traktuj blueprint jako przewodnik zmniejszający liczbę niespodzianek podczas realnej realizacji, a nie jako gotowy produkt.
Na co uważać: Najtrudniejsze bywają właśnie ostatnie 20% wykonania. Blueprint zmniejsza ryzyko, ale wciąż potrzebujesz realnego uruchomienia i weryfikacji na żywym systemie.