O czym jest ten film
- Od premiery GPT-6 Astra trwa spór, który poziom „wysiłku” (effort) daje najlepszy stosunek jakości do kosztów — w tokenach i czasie.
- Tibo, odpowiedzialny za kluczowe produkty OpenAI, twierdzi, że Astra na niskim poziomie pracuje lepiej niż poprzedni model — Soul — na wysokim.
- Użytkownicy skarżą się, że Astra kończy pracę za wcześnie i co chwilę prosi o pozwolenie; dokumentacja OpenAI przyznaje, że model celowo pyta zamiast zakładać.
- Autor przeprowadził kontrolowany eksperyment: siedem wątków (wszystkie poziomy Astry plus Soul na wysokim) dostało dokładnie to samo zlecenie badawczo-wykonawcze.
- Zadanie: znaleźć okazję do zbudowania SaaS-a dla małej firmy usługowej (2–20 pracowników), prześwietlić alternatywy na X i Reddicie, zaplanować biznes z „fosą” i przygotować stronę, notatki oraz prototyp.
- Kluczowe założenie promptu: konkurencja i klienci mają dostęp do tych samych modeli — pomysł musi być odporny na „vibe coding w weekend”.
- Wyniki bardzo się rozjeżdżają: od 30 do 46 minut i od 6 do 22 milionów tokenów, bez przejrzystej zależności od poziomu.
- Najlepszy stosunek jakości do kosztów wypadł na średnim poziomie; wysoki dał najczystszy przekaz i najwięcej dowodów, a Extra High, Max i Ultra nie wniosły proporcjonalnie nic.
- Kontrolny Soul na wysokim zużył tylko 6 mln tokenów w 32 minuty — starszy model wciąż się broni, choć strony generuje malowniczo brzydkie.
- Wniosek autora: na co dzień Astra Medium w trybie szybkim, wysoki — gdy trzeba podbić jakość; najwyższe poziomy prawie nigdy się nie zwracają.
Redakcyjne tłumaczenie
Dlaczego w ogóle wziąłem się za ten test
GPT-6 Astra jest z nami od jakiegoś czasu, a jednym z najgorętszych sporów — zarówno na YouTube, jak i na X — jest pytanie: na jakim poziomie wysiłku ten model daje najwięcej wartości za wydane tokeny? (Informacja dodatkowa: poziomy „wysiłku” (ang. effort) sterują tym, jak głęboko model pracuje nad zadaniem; Astra oferuje poziomy Low, Medium, High, Extra High, Max i Ultra.) Spotkałem się też z opinią, że Astra to model z natury leniwy: robi dokładnie to, o co poprosisz, ani o jotę więcej, a bywa, że nawet mniej. Postanowiłem więc sprawdzić, czy zmiana poziomu wysiłku zmienia to zachowanie. Każdy poziom dostał dokładnie to samo zadanie badawczo-wykonawcze, a jako punkt odniesienia dorzuciłem jeszcze Soul. Poniżej pokażę, co zwrócił każdy wątek, ile trwał, ile tokenów pochłonął i czy poziom wysiłku w ogóle na cokolwiek wpłynął. Po lekturze sami ocenicie, która konfiguracja pasuje do waszych codziennych projektów.
Bezpośrednim impulsem do eksperymentu był jeden wpis na X. Tibo, opiekun kluczowych produktów OpenAI — ten sam, o którym użytkownicy żartują, że resetuje im limity niemal co godzinę — rzucił odważną tezę: Astra na niskim poziomie daje lepsze wyniki niż Soul na wysokim. Soul to wcześniejszy model, który od premiery nowej, lśniącej nowinki popada w zapomnienie, choć dla wielu zadań wciąż wystarcza w zupełności. Kiedy jednak przejrzy się relacje użytkowników, zwłaszcza pracujących na niskim poziomie, słychać żale, że model kończy grubie za wcześnie i co pięć minut pyta o pozwolenie. Chciałem więc odpowiedzieć na dwa pytania. Po pierwsze: czy dodatkowy wysiłek modelu przekłada się na lepsze rezultaty? Po drugie: czy daje mu większą samodzielność — czy przestaje pytać o pozwolenie i przestaje być pozornie leniwy?
Co przyznaje oficjalna dokumentacja
W dokumentacji Openai czytamy, że model zaprojektowano jako skuteczniejszego współpracownika, który z tego względu częściej zadaje użytkownikowi pytania. Chwilę dalej pada zdanie jeszcze ważniejsze: model może się zatrzymać właśnie wtedy, gdy użytkownik spodziewałby się, że przyjmie rozsądne założenia sam. Dla porównania — modele pokroju Fable 5.1 dobrze radzą sobie, gdy dostają ogólny zarys celu, streszczenie tego, dokąd zmierzamy: nie tylko wyciągają wnioski, ale też przemyślanie dokładają własne kroki. Astra, przynajmniej na części poziomów, robi to najwyraźniej gorzej.
(Informacja dodatkowa: Soul to starszy model tej samej rodziny GPT-6, bezpośredni poprzednik Asty.)
Metodologia: sześć zmiennych pod kontrolą
Żeby eksperyment był przejrzysty i uczciwy, ująłem w kontrolę sześć rzeczy: ten sam kontekst dla wszystkich wątków, ten sam dostęp do narzędzi, MCP i umiejętności (skills), ten sam zakres budowy, identyczne warunki, osobne rozpatrzenie Ultra — bo Ultra potrafi uruchomić całą serię podagentów — oraz skrupulatną ewidencję czasu i tokenów każdego wątku. Za chwilę pokażę też mały trik, którym uruchomiłem cały zestaw konfiguracji jednym promptem.
Zadanie dla wszystkich wątków: znaleźć okazję na SaaS
Wszystkie siedem wątków dostało identyczne zlecenie — rozbiorę je teraz na części. Sednem było wysłanie każdego agenta w teren: miał zbadać wszystko, co da się znaleźć na X i Reddicie, czyli w dwóch świetnych miejscach na podsłuchiwanie głosów klientów. Grupa docelowa: właściciele małej firmy usługowej zatrudniającej od 2 do 20 osób. Nie wskazałem branży, problemu ani produktu. Poleciłem zacząć od bolączek klientów, rozważyć trzy okazje biznesowe i wybrać jedną. W części dowodowej agent miał przyjrzeć się na wspomnianych platformach trzem istniejącym alternatywom dla swojego pomysłu i przygotować krótką listę powtarzających się frustracji klientów, wymyślanych przez nich obejść, sygnałów wydatków oraz dowodów przeciwnych.
Najważniejsze zdanie całego promptu dotyczyło oceny okazji: „Załóż, że klienci i konkurencja mogą używać Asty, by szybko odtworzyć porządny software”. Czyli wprost: nie buduj SaaS-a, który ktoś wyklepie w weekend metodą vibe codingu. W idealnym modelu biznesowym powinna istnieć fosa — przewaga, której konkurencja nie skopiuje z dnia na dzień.
W części planistycznej chciałem, żeby każdy poziom samodzielnie tworzył pliki Excalidraw. Model generuje odpowiedni JSON i — inaczej niż wcześniej, gdy potrzebna była osobna umiejętność — teraz wystarczy prośba: zrób mi taki plik. To zresztą świetny sprawdzian organizacji myśli danej konfiguracji. (Informacja dodatkowa: Excalidraw to narzędzie do szybkiego szkicowania prostych, „odręcznych” diagramów; pliki zapisuje w formacie JSON.)
Jeśli chodzi o produkt główny, chciałem dopracowaną stronę internetową — bardzo podobną do tych, które sam składam na potrzeby filmów, żeby tłumaczyć widzom różne koncepcje. Miała to być witryna w duchu ChatGPT Sites, omawiająca cały plan budowy produktu po zakończonych badaniach. Na dokładkę, oprócz strony i pliku Excalidraw, każdy poziom miał zbudować działający prototyp tego, jak taki SaaS wyglądałby w praktyce. Podział zadania na te odcinki dawał każdej konfiguracji przestrzeń, żeby zabłysnąć — jeśli różnica między nimi naprawdę istnieje.
Ocena miała kilka płaszczyzn. Czy da się prześledzić argumentację, dlaczego to jest dobry pomysł na biznes? Po co ktokolwiek miałby płacić? Czy elementy się spinają: grupa docelowa, bolączka, którą deklarujemy, miejsce, w którym ma występować, produkt, przepływ pracy? Czy w ogóle ma sens, by to było SaaS-em? I wreszcie dowiezienie: czy agent skończył i zweryfikował własną pracę? Czy naprawdę się nad tym zastanowił?
Trik: siedem wątków jednym promptem
Oto wszystkie uruchomione wątki — i skłamałbym, twierdząc, że zakładałem je ręcznie, jeden po drugim. Wystarczy poprosić Codex, żeby utworzył serię wątków: przemianował je według poziomu wysiłku, przełączył poziom i przypiął wszystko do właściwego folderu. Prompt wygląda mniej więcej tak: „Weź dokładnie ten sam prompt — możesz sam go wymyślić, ma to być bardzo proste zadanie — i stwórz trzy realne wątki. Nazwij je tak, żeby łatwo było je odróżnić na pasku bocznym. Ustaw każdy na innym poziomie Astry: niskim, średnim i wysokim, i uruchom wszystkie dokładnie teraz, równolegle. Pilnuj postępów”. Ten mechanizm — nowość, która działa już i w Claude, i w Codexie — faktycznie podnosi wątki. Po wejściu w sekcję ostatnich widać, jak testowe wątki zaczynają się rozdzielać: medium, low, high — wszystkie pracują. Wewnątrz każdego czeka identyczne zadanie. I tak wygląda testowanie na skalę.
Wyniki poziom po poziomie
Efektem każdego wątku były: plik Canvas (rozbudowana notatka robocza w ChatGPT), jakaś forma strony internetowej, pełne omówienie oraz statystyki — czas, tokeny i wynik merytoryczny.
Astra Low. 37 minut pracy, niemal 15 milionów tokenów, osiem przejrzanych wątków na Reddicie — na X ani jednego — i 161 elementów w Canvas. Ostatnia liczba nie mierzy jakości, jedynie ilość wykonanej roboty. Pomysł, z którym wróciła: system śledzący pominięte prace sprzątania dzięki korekcie i ponownemu sprawdzeniu, dla właścicieli firm sprzątających biura w modelu cyklicznym. Proponowana fosa: indywidualne standardy klienta oraz historia napraw, które zadziałały. Brzmi ciekawie. Nie oceniam urody strony — oceniam koncepcję — ale impresji nie ma, choć może dałoby się z tego ugnieść biznes. Dwie poważne wady: zero dowodów z X i ani jednego kroku ponad to, o co poproszono.
Astra Medium. Tylko 30 minut, 10 milionów tokenów, sześć wątków z Reddita. Pomysł: wycena dodatkowych prac sprzątania i odnotowywanie akceptacji klienta, dla właścicieli firm pracujących na pisemnych umowach. Fosa: dokładne zapisy zakresu i szacunki doskonalone na realnych zleceniach — nie jestem pewien, czy to w ogóle fosa. Ciekawe jest co innego: znów trafiliśmy w branżę sprzątania, choć nic o niej w prompcie nie napisałem. Sądząc po grupie docelowej i zadanych warunkach, musi to być najdogodniejszy teren dla takiego pomysłu. Strona wygląda podobnie, ale po wejściu w plan w Canvasie czeka znacznie czystszy podział: kim jest klient, jakie są alternatywy, na czym polega okazja, jak wygląda droga właściciela firmy. Żeby ocenić model co do grosz, trzeba by przeczytać całość, ale pod względem jakości i różnorodności analizy średnia wyraźnie wyprzedza niską — i to w krótszym czasie, przy mniejszym zużyciu tokenów.
Astra High. Blisko 40 minut i 14 milionów tokenów; Reddita uzupełniła w końcu jedną serią wpisów z X, a Canvas jest najbardziej szczegółowy z dotychczasowych. Pomysł: przydzielanie wizyt na nowo, gdy ekipa sprzątająca nie może przyjść — chyba najprostsza jednozdaniowa definicja w całym teście, skierowana do właścicieli firm sprzątających mieszkania, którzy lawirują między ekipami a terminami. Fosa: ograniczenia i wyniki właściwe dla konkretnej firmy, doskonalące układanie grafiku. Ze wszystkich stron ta jest najczystsza i najjaśniejsza — widać wizję i widać bolączkę. Ta bolączka wygląda tak: „7:42 — furgonetka nie odpala”. Na grafiku dwie wizyty cykliczne, ktoś musi je przejąć, a wolny slot trzeba czymś zapełnić, bo inaczej firma traci pieniądze. Cały pomysł sprowadza się do minimalizowania przychodu, który przepada. Pytanie jednak brzmi: czy warto wydać 40 minut i 14 milionów tokenów, skoro można dać średniej 30 minut i dopracować prompt albo dorzucić jedno dopytanie — i dojść do tego samego punktu?
Astra Extra High. 45 minut, ale tokenów nieco mniej niż na wysokim — 12 milionów. I tu ciekawostka, która dla mnie dowodzi, że o AGI mowy nie ma i że spora część takich deklaracji jest mocno na wyrost: każdy poziom wysiłku powinien w jakimś sensie odzwierciedlać sprawność, a nie odzwierciedla. Wysoka pali blisko 14 milionów tokenów, niska również blisko 15, średnia około 10. Rozrzut jest duży i nieprzewidywalny. Gdybym powtórzył test, czasy pewnie wyszłyby podobne, ale zużycie tokenów — coraz trudniejsze do przewidzenia. Po raz pierwszy pomysł nie dotyczy sprzątania: przeprowadzanie dodatkowych prac remontowych od zatwierdzenia do rozliczenia, dla drobnych firm remontowych gubiących płatne dodatki. Fosa: kontrole zakresu szyte na miarę, oparte na tym, co zostało zatwierdzone, wykonane i opłacone — sama nazwa to dość gęsty skrót myślowy. Strona wygląda na poziomie wysokiej, ale pod maską jest gorsza. Podział podobny, te same cztery zakładki, Canvas otwiera się w nowej karcie, są filtry i przyciski nawigacyjne. Wersja wysoka miała jednak lepiej rozmieszczone i mniej ciasne elementy, a przy każdym z nich więcej dowodów — kliknięcie w „dowody klientów” prowadziło prosto do źródłowego wątku. W bezpośrednim zestawieniu Extra High wychodzi szara: mniej szczegółów, mniej odniesień, tylko nawigacja odrobinę lepsza. Za te 5–10 minut różnicy i ewentualne dodatkowe tokeny nie ma po co przepłacać względem średniej i wysokiej.
Astra Max. Zagadka: 46 minut pracy, ale tylko 10 milionów tokenów. Wydajna tokenowo, mniej wydajna czasowo. Pomysł: trzymanie zakresu, ceny i zatwierdzenia dodatkowych zleceń w jednym rekordzie — podejście zaciągnięte w stronę higieny danych — dla właścicieli firm remontujących domy z ekipami od 2 do 10 osób. Fosa: przyjęta rutyna pracy w zestawie narzędzi, konfiguracja z asystą i polecenia od księgowych. Ciekawe — model myśli o biznesie budowanym na poleceniach. Na uwagę zasługuje i to, że mimo najwyższego poziomu w wynikach nie ma śladu X, choć widzieliśmy go w wersji wysokiej. Kolejny dowód, że większy nakład nie daje automatycznie lepszych rezultatów — ani tu oszczędności, ani tam przewagi. Strona wygląda najczyściej i najbardziej dopracowanie, naprawdę przypomina gotowy produkt, lepiej niż wysoka i Extra High, i dobrze sprzedaje wizję oraz problem, który rozwiązuje. Tylko czy ktokolwiek dołożyłby te 10 minut, gdyby mógł zamiast tego dorzucić jedno-dwa dodatkowe prompty tańszemu poziomowi?
Astra Ultra. Najcięższe działo: 42 minuty, czyli krócej niż Max, ale aż 22 miliony tokenów. I to jest efekt za te 22 miliony: rejestrowanie i uzgadnianie dodatków remontowych jeszcze przed rozpoczęciem prac — w istocie automatyzacja tzw. change orders, czyli uzgodnień zmian zakresu — dla drobnych firm remontowych z częstymi dodatkami. Fosa: konfiguracja pod konkretny fach i wypróbowana rutyna doskonalona na realnych wynikach. Strona nie jest dziełem Leonarda: wygląda niemal identycznie jak wszystkie poprzednie, z drobnymi korektami odstępów i odrobiną poleru, który niczego nie wnosi. W dziale „okazja” czeka ładny, wytłoczony przycisk; Canvas to niemal kopia tego, co widzieliśmy wcześniej; źródła rozmieszczone dziwnie, bo każda bańka dostaje osobny zestaw. Czy to warte dodatkowego czasu i tokenów — dwudziestu milionów i całej machiny podagentów, które to uruchomiły?
Grupa kontrolna: Soul na wysokim. Jeśli wierzyć słowom Tibo, Astra na niskim ma dawać przeżycie równoważne. Tymczasem Soul uporał się w 32 minuty i zużył zaledwie 6 milionów tokenów. Jeśli o Soul zapomnieliście, jest powód, by go sobie przypomnieć: Astry nie należy używać do wszystkiego — nie każda sprawa wymaga strzelania z armaty do wróbla. Ciekawostka: Soul przejrzał sześć wątków na Reddicie i dwa na X. Ilość nie musi być miarą jakości, ale sam fakt, że te źródła sprawdził, robi różnicę. Pomysł: planowanie ratunku, gdy opóźnienia wywracają trasę serwisową — dla właścicieli-dyspozytorów powtarzalnych firm usługowych z personelem 2–20 osób. Fosa: wyniki naprawcze, utrzymywane reguły i wsparcie, za które ktoś odpowiada. A strona? Wybitnie brzydka — tak bardzo, że trudno na nią patrzeć bez przymrużenia oczu. Na pierwszej grafice model próbuje, jak rozumiem, naszkicować diagram modelu biznesowego. Bez wahania powiem: Astra jest nieporównanie lepsza w klepaniu szybkich, zgrabnych witryn. Ale zasadnicze pytanie brzmi: czy nie można było pobrać gotowej umiejętności do ładnej strony z porządnym odstępem i dalej pracować Soulem na wysokim albo średnim?
Werdykt: czego używać na co dzień
Z eksperymentu — i z własnej codziennej praktyki — wynika moja odpowiedź: ulubiona konfiguracja to Astra Medium w trybie szybkim. Z wszystkich wersji modeli w stylu Codex to mój faworyt: działa szybko, nie pochłania tokenów w alarmującym tempie i po prostu daje radę. Test to potwierdził — strona, struktura, plan biznesowy, model, Canvas wyglądały bardzo podobnie na średnim i wysokim poziomie. Jeśli komuś zależy na jednym skoku jakości, może przejść na wysoki i dopłacić parę tokenów. Ale do większości codziennych zadań — nawet biorąc pod uwagę, że Astry nie należy używać do wszystkiego — średnia wystarcza z zapasem.
Na podstawie tego testu i całej serii innych bardzo rzadko widzę sytuację, w której Max, Extra High albo Ultra zwracają dodatkowy czas, wysiłek i tokeny. Więcej testów opisałem w darmowym zestawieniu, do którego link czeka w opisie filmu — można je pobrać, wrzucić do własnego Codexa albo Claude’a i kazać sobie rozłożyć na czynniki pierwsze. A jeśli chcecie być o dziesięć kroków przed innymi w praktycznym stosowaniu AI — w pracy, biznesie, nauce czy zarabianiu — zajrzyjcie do mojej społeczności Early Adopters. Jeśli materiał był pomocny, polubienie i komentarz bardzo pomagają. Do zobaczenia w kolejnym odcinku.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Domyślny wybór: Astra Medium
Na czym polega: W teście średni poziom dał czystszą i bogatszą analizę niż niski, a różnica względem wysokiego była kosmetyczna — przy 30 minutach i 10 mln tokenów.
Jak stosować: Ustaw średni poziom wysiłku jako domyślną konfigurację do codziennych zadań; w parze z trybem szybkim dostajesz tanie, żwawe iteracje. Gdy potrzebujesz podbić jakość, doraźnie przełącz się na wysoki.
Na co uważać: Średnia potrafi pominąć całe platformy badawcze — w teście nie zajrzała na X. Źródła i zakres badania warto dopilnować jednym dopytaniem.
2.Liczba tokenów nie mierzy jakości
Na czym polega: Niska spaliła niemal 15 mln tokenów, średnia 10 mln, a rozrzut między poziomami był nieprzewidywalny — wyższy poziom nie gwarantuje ani lepszego wyniku, ani rozsądnego zużycia.
Jak stosować: Porównuj wątki po wartości merytorycznej wyniku, a nie po koszcie. Zanim dopłacisz za wyższy poziom, sprawdź, czego realnie brakuje w tańszym rezultacie — często wystarczy doprecyzowanie promptu.
Na co uważać: Przy planach z limitami tokenów jedno zadanie na Ultra zjadło 22 mln — bez proporcjonalnej wartości dodanej.
3.Model zapyta zamiast zakładać — wpisuj założenia wprost
Na czym polega: Dokumentacja OpenAI mówi wprost: Astra ma być współpracownikiem, który zadaje pytania i potrafi się zatrzymać tam, gdzie spodziewalibyśmy się rozsądnych domysłów.
Jak stosować: Zamiast walczyć z tym zachowaniem wyższym poziomem wysiłku, zapisuj założenia jawnie („jeśli brakuje danych, przyjmij X i idź dalej”), a decyzje wymagające faktycznie twojej uwagi oznaczaj jako jedyne punkty zatrzymania.
Na co uważać: To nie „lenistwo”, tylko zamierzona cecha modelu — podniesienie poziomu nie musi jej wyłączyć.
4.Zasada fosy: konkurencja też ma te same modele
Na czym polega: Najmocniejsze zdanie testowego zlecenia: załóż, że klienci i konkurencja mogą przy pomocy Asty szybko odtworzyć porządny software. To wymusza poszukiwanie pomysłów z trwałą przewagą, a nie „SaaS-a na weekend”.
Jak stosować: Przy każdym pomyśle na produkt zadaj kontrolne pytanie: co zajęłoby konkurencji odtworzenie tego w weekend? Jeśli nic — szukaj innej fosy: danych, historii relacji z klientem, wypracowanych rutyn, integracji.
Na co uważać: Modele chętnie proponują jako „fosę” rzeczy, które fosą nie są (jak „dokładne zapisy zakresu”) — każdą propozycję weryfikuj krytycznie, tak jak autor zrobił to z wynikiem średniego poziomu.
5.Nie używaj Astry do wszystkiego — starszy model wciąż daje radę
Na czym polega: Kontrolny Soul na wysokim poziomie skończył zadanie w 32 minuty na 6 mln tokenów i sprawdził więcej źródeł niż niejeden poziom Astry — jedynie prezentacja była szpetna.
Jak stosować: Do rutynowych zadań badawczych i analitycznych sięgaj po tańszy, starszy model; nowszy schowaj na to, w czym faktycznie błyszczy, np. szybkie, zgrabne witryny i prototypy.
Na co uważać: Słabość Soul leżała w opakowaniu, nie w analizie — zanim odrzucisz stary model, rozdziel „myślenie” od „wyglądu” (ten drugi można poprawić osobną umiejętnością).
6.Testowanie na skalę jednym promptem
Na czym polega: Zamiast ręcznie zakładać wątki, wystarczy poprosić Codex (mechanizm działa też w Claude), by utworzył wątki, nazwał je, ustawił różne poziomy wysiłku, przypiął do folderu, uruchomił równolegle i monitorował postępy.
Jak stosować: Wykorzystaj przy własnych porównaniach modeli i poziomów: jedno zlecenie, wiele konfiguracji, wspólny start — potem zestawiaj czasy, tokeny, źródła i jakość w tabeli.
Na co uważać: Równoległe wątki błyskawicznie zjadają limity — przy najwyższych poziomach sam test potrafi być kosztowny.
7.Kontroluj zmienne, zanim porównasz modele
Na czym polega: Wiarygodność testu oparła się na sześciu kontrolach: ten sam kontekst, dostęp do narzędzi, MCP i umiejętności, zakres budowy, warunki, osobne śledzenie Ultra (podagenty) oraz ewidencja czasu i tokenów.
Jak stosować: Przed własnym porównaniem wypisz zmienne i utrzymaj je identyczne we wszystkich wątkach; prowadź notatki z liczbami, żeby porównanie było powtarzalne.
Na co uważać: Jedno zadanie to jeden punkt danych — wnioski formułuj dopiero po serii testów na różnych typach zleceń, tak jak autor.
8.Zamiast Ultra — dopracowany prompt na średnim lub wysokim
Na czym polega: Najlepsza witryna i najbogatsze dowody wyszły na poziomie High (odnośnik do konkretnego wątku źródłowego przy każdym elemencie), a Extra High, Max i Ultra nie wnieśli nic proporcjonalnego do kosztu.
Jak stosować: Gdy wynik nie satysfakcjonuje, najpierw doprecyzuj zlecenie albo dorzuć dopytanie na średnim/wysokim poziomie; po najwyższe poziomy sięgaj dopiero na końcu.
Na co uważać: Wyższe poziomy potrafią wyglądać „bardziej dopracowanie” — poler, nowe karty, dodatkowe zestawy źródeł — bez realnej wartości merytorycznej. Oceniaj treść, nie wykończenie.
9.Podziel zlecenie na etapy — łatwiej ocenisz jakość
Na czym polega: Testowy prompt prowadził agenta krok po kroku: badania → trzy okazje → wybór jednej → dowody z alternatyw → plan → Excalidraw → strona → prototyp. Dzięki temu każdą płaszczyznę można ocenić osobno.
Jak stosować: W zleceniach dla agentów rozdzielaj badanie, ocenę okazji, planowanie i wykonanie, a na końcu wymagaj weryfikacji własnej pracy i odnośników do źródeł — to naturalny test „dowiezienia”.
Na co uważać: Nie oceniaj po jednym artefakcie: w teście bardzo podobne strony kryły zupełnie różną głębokość analizy.
10.Ilość źródeł to nie jakość dowodu
Na czym polega: Niska przejrzała osiem wątków z Reddita i nie zajrzała na X; wysokiej wystarczyła jedna seria wpisów z X, by zbudować najmocniejszą argumentację; Max — mimo najwyższego poziomu — pominął X zupełnie.
Jak stosować: W wynikach agenta sprawdzaj, czy dowody realnie podpierają tezy (frustracje, obejścia, sygnały wydatków, kontrargumenty), a nie ile ich nazbierano.
Na co uważać: Łatwo dać się nabrać na mnogość źródeł czy liczbę elementów notatki — to miara nakładu pracy, nie trafności.