Rozgrywka Jev w Pokémon Red zakończona w 37 godzin, ale Claude pomógł zbudować zwycięski system

Jev ukończył Pokémon Red w 37 godzin i 40 minut, kończąc rozgrywkę Jev w Pokémon Red, która wymagała 16 150 decyzji modelu. Wynik ten wypada imponująco na tle wcześniejszych eksperymentów z chatbotami, które przez tygodnie lub miesiące błądziły po podobnych grach. Pozorne zwycięstwo systemu niebędącego LLM-em wymaga jednak ważnego zastrzeżenia. Twórca twierdzi, że Claude Opus 5 pomógł diagnozować błędy i ulepszać środowisko decyzyjne otaczające Jev.

To rozróżnienie jest istotne, ponieważ Jev nie oglądał gry, nie pamiętał całej swojej podróży ani nie obsługiwał bezpośrednio kontrolera. Niestandardowa warstwa oprogramowania odczytywała wybrane dane z pamięci Game Boya, konstruowała dozwolone wybory i dodawała informacje o każdej opcji. Jev wybierał następnie spośród tych przygotowanych działań.

Claude miał działać na innym poziomie systemu. Analizował logi, znajdował sytuacje, w których Jev brakowało użytecznych informacji, i pomagał dopracowywać opcje oraz instrukcje przedstawiane modelowi decyzyjnemu. Rozgrywka podważa więc znane założenie dotyczące agentów AI, ale nie dowodzi, że niewielki model decyzyjny potrafi samodzielnie prześcignąć czołowy chatbot.

Rozgrywka Jev w Pokémon Red zakończyła się po 37 godzinach

Nagłośniony wynik jest realny w ramach opublikowanej przez twórcę konfiguracji, ale mierzy kompletny system programowy, a nie odizolowany model.

Christian Mathiesen, programista z Frigade, stworzył eksperyment open source i transmitował jego końcową rozgrywkę od 25 do 26 września 2026 roku. Opublikowane przez projekt dane z rozgrywki wskazują, że Jev ukończył Pokémon Red w 37 godzin i 40 minut.

Repozytorium odnotowuje 16 150 decyzji i około 39,2 mln tokenów wejściowych. Pojedyncza decyzja miała zajmować średnio około 0,4 sekundy. Jev poniósł 16 pełnych porażek drużyny, w tym 14 podczas prób pokonania Elite Four, i potrzebował 15 podejść do Elite Four przed ukończeniem gry.

W jego końcowej drużynie znalazły się Charizard na poziomie 83 oraz Graveler na poziomie 62. Grupę uzupełniali Nidoqueen, Beedrill, Haunter i Primeape. Szczegóły te pokazują, że system zrobił więcej niż tylko podążał krótką, z góry wyznaczoną trasą przez początkowe obszary.

Jev wybrał startera, zarządzał drużyną, łapał stwory, wybierał ataki, kupował przedmioty, leczył, trenował i decydował, dokąd podróżować. Obsługiwał też menu i odpowiadał na fabularne monity. Według repozytorium warstwa sterująca nie zapisywała bezpośrednio do pamięci gry ani nie zmieniała flag wydarzeń.

System otrzymał jednak znacznie więcej struktury niż człowiek trzymający Game Boya. Warstwa sterująca odczytywała z pamięci mapy, informacje o drużynie, warunki walki, ekwipunek i tekst wyświetlany na ekranie. Przekształcała ten stan w jawne wybory z dołączonymi użytecznymi informacjami.

W nawigacji zwykły kod realizował sprawdzanie kolizji i wyznaczanie tras metodą A*, czyli algorytmem obliczającym drogę do określonego celu. Jev nie decydował o każdym pojedynczym naciśnięciu przycisku kierunkowego na mapie. Wybierał cele wyższego poziomu, podczas gdy deterministyczne oprogramowanie obsługiwało dużą część ich fizycznej realizacji.

Warstwa sterująca zawierała także kamienie milowe fabuły opisujące kolejny cel i jego lokalizację. Postęp weryfikowano względem rzeczywistych flag wydarzeń w grze. Dawało to agentowi uporządkowaną reprezentację jego miejsca w fabule, choć ukryte przedmioty pozostawały niewidoczne.

Kolejną warstwę stanowiła ochrona przed zapętleniem. Wcześniej podejmowane wybory mogły otrzymywać ostrzeżenia, gdy nie przyniosły żadnej zmiany. Powtarzające się niepowodzenia mogły uruchomić wybór alternatywy. System mógł ostatecznie wczytać najnowszy punkt kontrolny kamienia milowego.

Interwencje te nie unieważniają rozgrywki. Każdy praktyczny agent AI zależy od otaczającego go oprogramowania, pamięci, narzędzi i logiki odzyskiwania po błędach. Oznaczają jednak, że istotnym osiągnięciem jest dobrze zaprojektowana architektura agenta, a nie surowy pojedynek jednego modelu z kartridżem.

Najbardziej uzasadniony wniosek jest wąski. Model decyzyjny, połączony ze środowiskiem zaprojektowanym do konkretnego celu i deterministycznymi mechanizmami sterowania, ukończył długą grę wymagającą tysięcy sekwencyjnych wyborów. Eksperyment nie pokazuje, jak Jev poradziłby sobie z pikselami, nieograniczoną przestrzenią działań lub bez zewnętrznego zarządzania stanem.

Dlaczego Pokémon wciąż ujawnia słabości agentów AI

Pokémon wydaje się prosty na poziomie pojedynczych tur, ale długie łańcuchy zależnych decyzji karzą słabą pamięć i kiepskie odzyskiwanie po błędach.

Oryginalny Pokémon Red jest turowy, wizualnie ograniczony i bardziej wybaczający niż szybka gra akcji. Mimo to wymaga od agenta utrzymywania celów przez wiele godzin. Gracz musi eksplorować mapy, czytać dialogi, budować drużynę, zarządzać zasobami i pamiętać, które przeszkody blokują dalszy postęp.

Jeden zły wybór w walce rzadko kończy całą grę. Powtarzające się drobne błędy mogą jednak wyczerpać przedmioty, osłabić drużynę lub odesłać gracza do centrum leczenia. Agent musi rozpoznać, że lokalnie atrakcyjny ruch może zaszkodzić jego długoterminowemu planowi.

To połączenie uczyniło Pokémon publicznym testem dla modeli AI ogólnego przeznaczenia. W lutym 2025 roku Anthropic wyposażył Claude 3.7 Sonnet w pamięć, zrzuty ekranu i narzędzia do naciskania przycisków. Badanie extended-thinking opisywało rozgrywkę trwającą dziesiątki tysięcy interakcji.

Eksperyment ujawnił słabości, które dopracowane rozmowy z chatbotami zwykle ukrywają. Model może brzmieć spójnie, jednocześnie tracąc orientację w swojej lokalizacji, powtarzając nieudaną trasę lub trzymając się nieaktualnego planu. Gra czyni te błędy widocznymi, ponieważ każda decyzja zmienia trwałe środowisko.

Inni twórcy później transmitowali systemy zbudowane wokół modeli Gemini, GPT i nowszych modeli Claude. Niektóre z nich ostatecznie ukończyły gry Pokémon, ale porównania nadal były trudne. Każdy projekt udostępniał inne informacje, korzystał z innych systemów pamięci i dopuszczał różne formy pomocy deweloperskiej.

Analiza agentów w grach ze stycznia 2026 roku opisała czołowe modele jako powolne, zdezorientowane i skłonne do nadmiernej pewności siebie podczas takich rozgrywek. Krytyka ta wskazała problem szerszy niż Pokémon. Modele ogólnego przeznaczenia potrafią wygenerować przekonujące uzasadnienie nawet wtedy, gdy ich wewnętrzny obraz środowiska jest niepełny.

Jev stosuje inne podejście. TypeSafe AI opisuje go jako model System One, co oznacza, że jest zoptymalizowany pod kątem szybkich, ograniczonych osądów, a nie rozbudowanego generowania tekstu. Przyjmuje kontekst i ukierunkowane pytania, a następnie zwraca wybory, oceny lub prawdopodobieństwa typu tak lub nie.

Firma pozycjonuje te wyniki jako komponenty zwykłego oprogramowania. Jej wprowadzenie do Jev podkreśla klasyfikację, routing, scoring i rozgałęzianie. Nie przedstawia Jev jako zamiennika każdej możliwości LLM-a.

Ta węższa rola zaskakująco dobrze pasuje do Pokémon, gdy twórca przeorganizuje grę. W większości momentów gracz nie pisze eseju ani nie wymyśla otwartego planu. Wybiera atak, cel podróży, kupuje przedmiot albo decyduje, czy trenować.

Wyzwanie polega na wygenerowaniu właściwego zestawu wyborów i dołączeniu odpowiednich informacji. Jeśli model widzi każdą istotną opcję, szybki silnik decyzyjny może utrzymać tempo gry. Jeśli warstwa sterująca ukrywa kluczowy fakt, szybkość jedynie pomaga agentowi szybciej powtarzać błędny osąd.

Dlatego wynik Jev wywiera presję na zespoły budujące agentów wyłącznie wokół modeli konwersacyjnych. Sugeruje, że wiele powtarzających się kroków agenta nie wymaga kosztownej, otwartej odpowiedzi. Wyspecjalizowany model może obsłużyć przygotowaną decyzję, podczas gdy konwencjonalny kod wykonuje precyzyjne obliczenia i realizuje działania.

Podważa też pogląd, że jeden duży model powinien realizować percepcję, pamięć, planowanie, osąd i kontrolę w ramach jednej ciągłej rozmowy. Rozgrywka Pokémon rozdziela te obowiązki między odrębne komponenty. To rozdzielenie wydaje się najważniejszym wkładem eksperymentu.

Jev kontra chatboty to niewłaściwy pojedynek

Istotnym pojedynkiem jest monolityczna AI kontra podzielony system, który przypisuje każde zadanie komponentowi najlepiej do niego dopasowanemu.

Chatbot przyjmuje otwarte prompty i generuje język. Ta elastyczność pozwala mu wyjaśniać nieznane sytuacje, tworzyć plany, interpretować niejednoznaczne instrukcje i odzyskiwać kontrolę poprzez rozmowę. Ta sama elastyczność może powodować niepotrzebne opóźnienia i zawodny format odpowiedzi, gdy oprogramowanie potrzebuje tylko jednego wyboru.

Jev nie potrafi napisać nowego dokumentu strategicznego ani swobodnie opisać ekranu. Zwraca typowany osąd na podstawie pytań i opcji dostarczonych przez aplikację. To ograniczenie ułatwia kodowi wykorzystanie jego wyniku.

W systemie Pokémon podział pracy był jawny. Emulator generował stan możliwy do odczytu przez maszynę. Warstwa sterująca przekształcała ten stan, wyznaczała ścieżki, szacowała wyniki walk i przygotowywała dozwolone alternatywy. Jev dostarczał osąd tam, gdzie sztywne reguły byłyby niewygodne.

Ta architektura przypomina dojrzały proces produkcyjny bardziej niż demonstrację chatbota. Niezawodne systemy często oddzielają operacje deterministyczne od probabilistycznych. Kod powinien wykonywać obliczenia arytmetyczne, egzekwować uprawnienia i walidować schematy. Modele powinny zajmować się niejednoznacznością, której stałe reguły nie potrafią czysto rozstrzygnąć.

Rozgrywka pokazuje też wartość pamięci zewnętrznej. Jev nie potrzebował rosnącego transkryptu rozmowy, ponieważ warstwa sterująca odtwarzała bieżący opis stanu dla każdej decyzji. Istotna historia musiała być przechowywana przez aplikację i wstawiana wtedy, gdy była potrzebna.

Taka konstrukcja zmniejsza ryzyko, że długi kontekst zostanie zaśmiecony nieaktualnymi planami. Zmusza też twórców do określenia, które fakty są istotne. Ta jasność może zwiększać niezawodność, ale przenosi znaczną odpowiedzialność z modelu na projektanta systemu.

Chatbot ogólnego przeznaczenia ukrywa dużą część tej pracy. Twórcy mogą przekazać zrzut ekranu, podać szeroki cel i poprosić model o decyzję, co ma wydarzyć się dalej. Interfejs wydaje się prosty, podczas gdy model przejmuje percepcję, interpretację, planowanie i generowanie odpowiedzi.

Pozorna prostota wiąże się z kosztami wykraczającymi poza obliczenia. Gdy coś zawodzi, twórca musi ustalić, czy problem wynikał z wizji, pamięci, rozumowania, wyboru narzędzia czy niejasnej instrukcji. Długa odpowiedź w języku naturalnym może dostarczyć wskazówek, ale nie gwarantuje precyzyjnej diagnozy.

Typowany potok decyzyjny ujawnia inne dowody. Projekt Jev rejestrował pełny stan, opcje, prawdopodobieństwa i opóźnienie dla każdego wywołania. Twórcy mogli sprawdzić, jakie wybory były dostępne i czy model wyrażał niepewność.

Takie logowanie przekształca awarię agenta w bardziej konkretne pytanie inżynieryjne. Czy model wybrał źle mimo odpowiedniego kontekstu? Czy warstwa sterująca pominęła konieczną opcję? Czy poprawna decyzja wysokiego poziomu przekształciła się w złą sekwencję przycisków? Każda odpowiedź sugeruje inną naprawę.

Nie oznacza to, że model decyzyjny zawsze wygrywa. Otwarte środowiska regularnie wprowadzają zdarzenia, których twórcy nie przewidzieli. Model ograniczony do zdefiniowanych wyborów nie może wybrać działania, którego aplikacja nigdy mu nie zaoferowała.

Chatbot może czasem wymyślić plan odzyskania kontroli w nieznanej sytuacji. Potrafi zinterpretować nietypowy tekst, wyjaśnić, dlaczego obecne narzędzia są niewystarczające, lub zaproponować nową sekwencję operacji. Węższy interfejs Jev zależy od innego komponentu wykonującego tę pracę.

Ujęcie „Jev kontra LLM” zaciera więc architekturę, która faktycznie odniosła sukces. Ukończony przebieg połączył szybki model decyzyjny, szczegółowy translator stanu, kod wyznaczający ścieżki, punkty kontrolne, ochronę przed pętlami oraz model frontierowy wykorzystywany podczas prac rozwojowych.

Ten zestaw nie wyeliminował dużych modeli językowych. Przeniósł jeden z nich do roli nadzorczej.

Claude Opus 5 Pomagał Systemowi Wychodzić ze Ślepych Zaułków

Zaangażowanie Claude’a zmienia wynik z niespodzianki modelowej w dowód na architekturę AI o dwóch poziomach.

Według relacji dewelopera opisanej przez Google News, Claude Opus 5 monitorował logi i pomagał dostosowywać wybory oraz sformułowania przekazywane Jevowi. Ta praca miała podobno znaczenie, gdy model decyzyjny trafiał w ślepe zaułki.

Interwencja najwyraźniej odbywała się poprzez zmiany wprowadzane podczas rozwoju systemu, a nie przez wybieranie ruchów przez Claude’a w każdej turze gry. To rozróżnienie zachowuje rolę Jeva w podejmowaniu zarejestrowanych decyzji. Mimo to komplikuje twierdzenia, że system niebędący LLM samodzielnie odniósł sukces tam, gdzie chatboty zawiodły.

Model może dobrze wybierać tylko na podstawie świata, który otrzymuje. Załóżmy, że agent wielokrotnie kieruje się w stronę zablokowanej ścieżki, ponieważ prompt nie wskazuje wymaganego przedmiotu. Przeformułowanie dostępnych opcji może pomóc, lecz głębszą naprawą jest dodanie brakującego stanu.

Model frontierowy dobrze nadaje się do analizowania takich porażek. Może przeczytać długą trajektorię, porównać powtarzające się próby, wywnioskować, którego faktu brakuje, i zaproponować zmiany w otoczeniu testowym. Są to otwarte zadania obejmujące diagnozę i tworzenie nowego tekstu — dokładnie te rodzaje pracy, do których Jev nie został zaprojektowany.

Powstały układ przypomina rozróżnienie między szybkim a wolnym myśleniem. Jev obsługuje częste, ograniczone osądy. Claude wykonuje rzadszą analizę, gdy system zachowuje się nieprawidłowo lub napotyka sytuację, której jego projektanci nie potrafili przedstawić.

Nie jest to jedynie kompromis wymuszony ograniczeniami Jeva. Może to być użyteczny wzorzec produkcyjny. Większość zdarzeń w oprogramowaniu jest rutynowa, podczas gdy mniejsza część wymaga głębszej interpretacji. Przepuszczanie każdego zdarzenia przez najwydajniejszy model może marnować zasoby i wprowadzać dodatkowe opóźnienia.

Model nadzorczy może zamiast tego analizować niepewne przypadki, przeglądać partie niepowodzeń albo przepisywać politykę decyzyjną. Jego ulepszenia mogą następnie przynosić korzyści tysiącom kolejnych wywołań wykonywanych przez szybszy komponent.

Proces coachingu wymaga jednak ściślejszej dokumentacji, zanim badacze będą mogli traktować ten przebieg jako czyste porównanie. Publiczne podsumowanie nie przedstawia kontrolowanej wartości bazowej Jev-only z użyciem finalnego harnessu. Nie określa też ilościowo, jak często Claude zmieniał system ani jaki postęp następował po każdej zmianie.

Historia repozytorium zawiera setki commitów, co zasadniczo pozwala prześledzić ewolucję. Sekwencja commitów rozwojowych nie jest jednak tym samym co protokół eksperymentalny. Właściwe porównanie wymagałoby zamrożenia środowiska, zdefiniowania zasad interwencji i przeprowadzenia wielu prób z kontrolowanymi seedami.

Istnieje jeszcze jedno źródło niejednoznaczności. Każdy benchmark agentów obejmuje scaffolding, lecz może on zawierać znaczną wiedzę o zadaniu. Harness Jeva znał kamienie milowe fabuły i lokalizacje, wyliczał ścieżki, szacował obrażenia oraz przygotowywał dozwolone działania.

Przebieg chatbota, który otrzymuje jedynie zrzuty ekranu i ogólne narzędzia przycisków, mierzy się z innym problemem. Musi wykonywać więcej percepcji i planowania wewnątrz modelu. Porównywanie czasu ukończenia bez dopasowania tych interfejsów grozi przypisaniem modelowi przewag dostarczonych przez harness.

Uczciwa interpretacja nie jest ani odrzuceniem, ani triumfem. Jev podjął tysiące istotnych decyzji w systemie, który ostatecznie ukończył grę. Claude pomógł inżynierom ulepszyć ten system. Razem osiągnęli szybszy wynik niż kilka znanych demonstracji chatbotów, ale nie przeprowadzili tego samego testu.

Czego Wynik Nie Dowodzi

Jedno udane przejście gry nie pozwala stwierdzić, że modele decyzyjne są ogólnie inteligentniejsze, bardziej autonomiczne lub bardziej niezawodne niż agenci LLM.

Największą niewiadomą jest odtwarzalność. Opublikowany wynik opisuje jedno ukończone przejście po aktywnym rozwoju otaczającego systemu. Pokémon zawiera losowe spotkania, niepewne wyniki walk i wiele możliwych konfiguracji drużyny.

Drugie przejście mogłoby obrać inną trasę lub utknąć w innym miejscu. Powtórzenie eksperymentu pokazałoby, czy system niezawodnie kończy grę, czy też skorzystał z korzystnej trajektorii.

W konfiguracji brakuje też dopasowanego konkurenta. Aby uczciwie porównać Jeva z Claude’em, oba modele potrzebowałyby tej samej reprezentacji stanu, opcji, deterministycznej nawigacji, zasad odzyskiwania oraz punktów kontrolnych. W przeciwnym razie benchmark mierzy dwie różne kombinacje modelu i oprogramowania.

Użyteczny eksperyment obejmowałby trzy konfiguracje. Jedna wykorzystywałaby Jeva z zamrożonym harnessem. Druga zastąpiłaby Jeva modelem ogólnego przeznaczenia przy zachowaniu wszystkich pozostałych komponentów. Trzecia używałaby systemu hybrydowego z modelem nadzorczym analizującym wybrane niepowodzenia.

Badacze porównaliby następnie wskaźniki ukończenia, decyzje, liczbę interwencji, czas rzeczywisty i zachowanie podczas odzyskiwania w powtarzanych próbach. Te pomiary pokazałyby, gdzie pomaga model wyspecjalizowany i gdzie model frontierowy nadal pozostaje potrzebny.

Wykorzystanie przez dewelopera inspekcji pamięci również ogranicza szersze wnioski. Odczytywanie ustrukturyzowanego stanu gry usuwa problem percepcji wizualnej. Jest to rozsądny wybór do testowania decyzji, ale nie dowodzi, że Jev może działać bezpośrednio w chaotycznych środowiskach wizualnych.

Rzeczywiste zastosowania rzadko oferują doskonałe listy dozwolonych opcji. Router zgłoszeń wsparcia może otrzymać nowy problem, który nie pasuje do żadnej znanej kategorii. Agent przeglądarkowy może natrafić na przeprojektowaną stronę. Fizyczny robot może zaobserwować obiekt, którego jego planer nigdy nie uwzględnił.

Modele ograniczone potrzebują bezpiecznych ścieżek wyjścia dla takich przypadków. Progi pewności mogą przekazywać niepewne decyzje człowiekowi lub modelowi ogólnego przeznaczenia. Aplikacje potrzebują też sposobu wykrywania sytuacji, w których właściwego wyboru całkowicie brakuje.

Samo prawdopodobieństwo nie rozwiązuje tego problemu. Model może wyrażać wysoką pewność wśród złych alternatyw, ponieważ każda dostępna opcja jest nieprawidłowa. Deweloperzy muszą walidować zestaw działań i monitorować rezultaty dalszych etapów.

Ochrona Jeva przed pętlami pokazuje potrzebę takich zabezpieczeń. Harness oznaczał nieskuteczne wybory, próbował alternatyw po powtarzających się niepowodzeniach i w ostateczności przywracał punkty kontrolne. Mechanizmy te zapobiegały uwięzieniu systemu na zawsze przez jeden błędny osąd.

Oznaczają też, że ukończenie nie było wyłącznie wynikiem poprawnego wyboru na każdym kroku. System tolerował błędy i potrafił się z nich odzyskać. Produkcyjna AI potrzebuje tej samej cechy, choć przepływy pracy w biznesie często nie mają wygodnego punktu kontrolnego, który mógłby odwrócić szkody.

Błędne działanie w grze może kosztować kilka minut. Błędne usunięcie danych, płatność lub odpowiedź dla klienta mogą mieć trwałe konsekwencje. Deweloperzy rozważający architekturę w stylu Jeva muszą określić, które decyzje są odwracalne, a które wymagają zatwierdzenia.

Eksperyment niewiele mówi także o bezpieczeństwie. Model przetwarzający tekst z zewnętrznych źródeł może napotkać manipulacyjne instrukcje lub wprowadzający w błąd kontekst. Ograniczenie wyjścia do typowanych wyborów zawęża powierzchnię działań, lecz nie gwarantuje poprawnej interpretacji.

Wreszcie Pokémon Red jest znanym, stabilnym środowiskiem. Jego mapy, mechanika walk, menu i struktura fabuły nie zmieniają się podczas przebiegu. Ta stabilność pozwala inżynierom zbudować wyjątkowo szczegółowy translator stanu.

Wiele środowisk przedsiębiorstw zmienia się nieustannie. Dokumenty przychodzą w nowych formatach, polityki ewoluują, a narzędzia zwracają niepełne dane. Im bardziej zmienne środowisko, tym więcej utrzymania wymaga harness.

Przebieg wspiera więc hipotezę projektową, a nie uniwersalny ranking. Wyspecjalizowane modele decyzyjne wyglądają obiecująco, gdy działania są ograniczone, kontekst można ustrukturyzować, a deterministyczne oprogramowanie może wykonać wynik. Modele ogólnego przeznaczenia pozostają wartościowe, gdy system musi interpretować nowości, tworzyć plany lub naprawiać własną reprezentację.

Trzy Sygnały Pokażą, Czy Wynik Jeva Ma Znaczenie

Kolejnym testem jest to, czy architektura wytrzyma powtórzenia, dopasowane porównania i środowiska, które nie zostały starannie przygotowane specjalnie pod nią.

Po pierwsze, warto obserwować odtwarzalne przebiegi Pokémon z wykorzystaniem zamrożonego wydania harnessu. Wielokrotne ukończenia bez nadzoru wzmocniłyby twierdzenie, że system tworzy niezawodną pętlę decyzyjną. Opublikowane niepowodzenia byłyby równie wartościowe, ponieważ pokazałyby, które elementy reprezentacji stanu pozostają kruche.

Najbardziej użyteczne wydanie zawierałoby pełne trajektorie, stałe wersje modelu, logi interwencji i jasną definicję ukończenia. Powinno oddzielać automatyczne odzyskiwanie od zmian wprowadzanych przez człowieka między przebiegami. Bez tego rozdzielenia deweloperzy nie mogą ustalić, czy ulepszenia wynikały z modelu, czy z dalszej pracy inżynieryjnej.

Po drugie, należy szukać dopasowanego testu Jev kontra LLM. Oba systemy powinny otrzymać identyczny stan, wybory, kod nawigacji oraz zasady punktów kontrolnych. To przekształciłoby obecny kontrast architektoniczny w mierzalne porównanie modeli.

Dopasowany test mógłby wykazać, że LLM działa podobnie, ale odpowiada wolniej. Mógłby też pokazać, że Jev celuje w rutynowych wyborach, lecz przegrywa w rzadkich sytuacjach. Może również ujawnić, że szczegółowy harness usuwa większość obciążenia związanego z inteligencją z obu modeli.

Po trzecie, warto obserwować zastosowania poza grami, w których wyniki mają obiektywne etykiety. Wiarygodnymi kandydatami są kierowanie zgłoszeń, kolejki moderacyjne, klasyfikacja dokumentów, wybór narzędzi i priorytetyzacja alertów. Te przepływy pracy tworzą powtarzalne decyzje, które zespoły mogą audytować względem późniejszych wyników.

Najsilniejszym dowodem nie byłaby spektakularna demonstracja. Byłaby nim stabilna dokładność przy zmieniających się danych wejściowych, wyraźna kalibracja, niski wskaźnik wyjątków oraz bezpieczna eskalacja, gdy żadna z przygotowanych opcji nie pasuje.

Dla deweloperów natychmiastowa lekcja ma praktyczny charakter. Nie należy zlecać jednemu modelowi wykonywania każdej funkcji poznawczej tylko dlatego, że interfejs czatu sprawia, iż taki układ wydaje się łatwy. Należy oddzielić percepcję, stan, osąd, wykonanie, pamięć i odzyskiwanie, a następnie ocenić każdą granicę.

Zespoły mogą zastosować tę samą ideę w swoich przepływach AI, zachowując materiał źródłowy stojący za każdą decyzją. Przeszukiwalna baza wiedzy inżynieryjnej może pomóc recenzentom łączyć zachowanie modelu ze specyfikacjami, logami i wcześniejszymi poprawkami.

Eksperyment Jev Pokémon Red ma znaczenie, ponieważ uwidacznia architekturę. Skupiony model obsłużył tysiące wyborów, zwykłe oprogramowanie wykonywało precyzyjne operacje, a Claude miał podobno pomóc przeprojektować system, gdy jego reprezentacja zawiodła.

Nie jest to czyste zwycięstwo nad LLM. To argument za używaniem ich rzadziej i bardziej rozważnie.

Kolejne pytanie brzmi, czy deweloperzy potrafią odtworzyć ten podział pracy bez miesięcy dostrajania specyficznego dla zadania. Jeśli niezależne zespoły będą w stanie zamrozić harness, powtórzyć przebieg i przenieść ten wzorzec do rzeczywistych przepływów pracy, Jev pokaże coś większego niż nietypowy sposób ukończenia Pokémon Red.