La partita di Jev a Pokémon Red si è conclusa in 37 ore, ma Claude ha contribuito a costruire il sistema vincente

Jev ha completato Pokémon Red in 37 ore e 40 minuti, concludendo una partita che ha richiesto 16.150 decisioni del modello. Il risultato appare notevole se confrontato con precedenti esperimenti con chatbot, che hanno trascorso settimane o mesi a vagare in giochi simili. Eppure l'apparente vittoria di un sistema non-LLM richiede un'importante precisazione. Lo sviluppatore afferma che Claude Opus 5 ha contribuito a diagnosticare i problemi e a migliorare l'ambiente decisionale attorno a Jev.

La distinzione è importante perché Jev non osservava il gioco, non ricordava l'intero percorso né controllava direttamente un controller. Un'infrastruttura software personalizzata leggeva dati selezionati dalla memoria del Game Boy, costruiva scelte consentite e aggiungeva informazioni su ciascuna opzione. Jev selezionava quindi tra queste azioni predisposte.

Secondo quanto riferito, Claude operava a un altro livello del sistema. Esaminava i log, individuava le situazioni in cui Jev non disponeva di informazioni utili e contribuiva a perfezionare le opzioni e le istruzioni presentate al modello decisionale. La partita mette quindi in discussione una convinzione diffusa sugli agenti AI, ma non dimostra che un piccolo modello decisionale possa superare autonomamente il ragionamento di un chatbot di frontiera.

La partita di Jev a Pokémon Red si è conclusa dopo 37 ore

Il risultato principale è reale nell'ambito della configurazione pubblicata dallo sviluppatore, ma misura un sistema software completo anziché un modello isolato.

Christian Mathiesen, sviluppatore di Frigade, ha realizzato l'esperimento open source e ha trasmesso in streaming la sua partita conclusiva dal 25 al 26 settembre 2026. I dati pubblicati sulla partita del progetto indicano che Jev ha completato Pokémon Red in 37 ore e 40 minuti.

Il repository registra 16.150 decisioni e circa 39,2 milioni di token di input. Una decisione tipica richiedeva, secondo quanto riportato, circa 0,4 secondi. Jev ha subito 16 sconfitte totali della squadra, di cui 14 durante i tentativi contro i Superquattro, e ha avuto bisogno di 15 tentativi contro i Superquattro prima di concludere il gioco.

La squadra finale includeva un Charizard di livello 83 e un Graveler di livello 62. Nidoqueen, Beedrill, Haunter e Primeape completavano il gruppo. Questi dettagli mostrano che il sistema ha fatto più che seguire un breve percorso predeterminato attraverso le aree iniziali.

Jev ha scelto lo starter, gestito la squadra, catturato creature, selezionato attacchi, acquistato oggetti, curato, allenato e deciso dove viaggiare. Ha inoltre gestito i menu e risposto ai prompt narrativi. Secondo il repository, l'infrastruttura non scriveva direttamente nella memoria di gioco né modificava i flag degli eventi.

Tuttavia, il sistema riceveva molta più struttura di quella disponibile a una persona con in mano un Game Boy. L'infrastruttura leggeva dalla memoria mappe, informazioni sulla squadra, condizioni di battaglia, inventario e testo sullo schermo. Convertiva questo stato in scelte esplicite, corredate da informazioni utili.

Per la navigazione, codice convenzionale eseguiva il controllo delle collisioni e il pathfinding A*, un algoritmo che calcola un percorso verso una destinazione definita. Jev non decideva ogni singola pressione dei pulsanti direzionali lungo la mappa. Selezionava obiettivi di livello superiore, mentre software deterministico gestiva gran parte della loro esecuzione fisica.

L'infrastruttura includeva inoltre traguardi narrativi che descrivevano il prossimo obiettivo e la sua posizione. I progressi venivano verificati rispetto agli effettivi flag degli eventi del gioco. Questo forniva all'agente una rappresentazione strutturata del punto della storia in cui si trovava, pur lasciando nascosti gli oggetti segreti.

Un ulteriore livello era dato dalla protezione dai loop. Le scelte tentate in precedenza potevano ricevere avvisi quando non avevano prodotto alcun cambiamento. Fallimenti ripetuti potevano attivare una selezione alternativa. Il sistema poteva infine ricaricare il checkpoint dell'ultimo traguardo raggiunto.

Questi interventi non invalidano la partita. Ogni agente AI pratico dipende da software circostante, memoria, strumenti e logiche di recupero. Significano però che il risultato rilevante è un'architettura di agenti ben progettata, non un confronto puro tra un modello e una cartuccia.

La conclusione più difendibile è circoscritta. Un modello decisionale, abbinato a un ambiente progettato appositamente e a controlli deterministici, ha completato un gioco lungo che richiede migliaia di scelte sequenziali. L'esperimento non mostra come Jev si comporterebbe con i pixel, uno spazio d'azione illimitato o senza gestione esterna dello stato.

Perché Pokémon continua a mettere in luce le debolezze degli agenti AI

Pokémon sembra semplice a livello dei singoli turni, ma le sue lunghe catene di decisioni dipendenti penalizzano la memoria debole e le scarse capacità di recupero.

L'originale Pokémon Red è a turni, visivamente limitato e indulgente rispetto a un gioco d'azione veloce. Richiede comunque a un agente di mantenere gli obiettivi per molte ore. Il giocatore deve esplorare mappe, leggere dialoghi, costruire una squadra, gestire risorse e ricordare quali ostacoli impediscono i progressi successivi.

Una cattiva scelta in battaglia raramente pone fine all'intero gioco. Errori piccoli ma ripetuti possono comunque esaurire gli oggetti, indebolire la squadra o rimandare il giocatore a un centro di cura. Un agente deve riconoscere che una mossa localmente allettante può danneggiare il suo piano a lungo termine.

Questa combinazione ha reso Pokémon un test pubblico per i modelli AI generalisti. Nel febbraio 2025, Anthropic ha dotato Claude 3.7 Sonnet di memoria, screenshot e strumenti per premere i pulsanti. La sua ricerca sul ragionamento esteso descriveva sessioni di gioco durate decine di migliaia di interazioni.

L'esperimento ha messo in luce debolezze che le conversazioni curate con i chatbot tendono a nascondere. Un modello può apparire coerente pur perdendo il filo della propria posizione, ripetendo un percorso fallito o attenendosi a un piano superato. Un gioco rende visibili questi errori perché ogni decisione modifica un ambiente persistente.

In seguito, altri sviluppatori hanno trasmesso sistemi basati su Gemini, GPT e modelli Claude più recenti. Alcuni hanno infine completato giochi Pokémon, ma i confronti sono rimasti difficili. Ogni progetto esponeva informazioni differenti, utilizzava sistemi di memoria diversi e consentiva forme diverse di assistenza da parte degli sviluppatori.

Un'analisi degli agenti di gioco del gennaio 2026 descriveva i modelli principali come lenti, confusi e inclini all'eccessiva sicurezza durante queste partite. La critica individuava un problema più ampio di Pokémon. I modelli generalisti possono generare una motivazione convincente anche quando la loro rappresentazione interna dell'ambiente è incompleta.

Jev adotta un approccio diverso. TypeSafe AI lo descrive come un modello System One, ossia ottimizzato per giudizi rapidi e circoscritti anziché per la generazione di testo estesa. Accetta contesto e domande mirate, quindi restituisce scelte, punteggi o probabilità sì/no.

L'azienda posiziona questi output come componenti all'interno di software ordinario. La sua introduzione a Jev mette l'accento su classificazione, instradamento, scoring e diramazioni. Non presenta Jev come un sostituto di tutte le capacità di un LLM.

Questo ruolo più ristretto si adatta sorprendentemente bene a Pokémon, una volta che lo sviluppatore ristruttura il gioco. Nella maggior parte dei momenti, il giocatore non sta scrivendo un saggio né inventando un piano aperto. Sta selezionando un attacco, scegliendo una destinazione, acquistando un oggetto o decidendo se allenarsi.

La difficoltà consiste nel generare il giusto insieme di scelte e nell'associare le informazioni corrette. Se il modello vede ogni opzione rilevante, un motore decisionale rapido può mantenere il gioco in movimento. Se l'infrastruttura nasconde un fatto critico, la velocità aiuta soltanto l'agente a ripetere più rapidamente il giudizio sbagliato.

Ecco perché il risultato di Jev mette sotto pressione i team che costruiscono agenti interamente attorno ai modelli conversazionali. Suggerisce che molti passaggi ricorrenti di un agente non richiedono una risposta costosa e aperta. Un modello specializzato può gestire una decisione predisposta, mentre il codice convenzionale si occupa di calcoli ed esecuzione precisi.

Mette inoltre in discussione l'idea che un unico modello di grandi dimensioni debba svolgere percezione, memoria, pianificazione, giudizio e controllo all'interno di una singola conversazione continua. La partita a Pokémon divide queste responsabilità in componenti distinti. Questa separazione sembra essere il contributo più importante dell'esperimento.

Jev contro i chatbot è il confronto sbagliato

Il confronto significativo è tra un'AI monolitica e un sistema suddiviso che assegna ogni compito al componente più adatto.

Un chatbot accetta prompt aperti e produce linguaggio. Questa flessibilità gli consente di spiegare situazioni sconosciute, scrivere piani, interpretare istruzioni ambigue e recuperare attraverso la conversazione. La stessa flessibilità può creare latenza superflua e formattazione inaffidabile quando il software necessita soltanto di una selezione.

Jev non può scrivere un nuovo documento strategico né descrivere liberamente lo schermo. Restituisce un giudizio tipizzato a partire da domande e opzioni fornite dall'applicazione. Questa limitazione rende il suo output più semplice da utilizzare per il codice.

Nel sistema Pokémon, la divisione del lavoro era esplicita. L'emulatore produceva uno stato leggibile dalla macchina. L'infrastruttura trasformava quello stato, calcolava percorsi, stimava gli esiti delle battaglie e preparava alternative consentite. Jev forniva il giudizio nei punti in cui regole rigide sarebbero state poco pratiche.

Questa architettura assomiglia più a un flusso di lavoro di produzione maturo che a una dimostrazione di chatbot. I sistemi affidabili spesso separano le operazioni deterministiche da quelle probabilistiche. Il codice dovrebbe calcolare l'aritmetica, applicare le autorizzazioni e validare gli schemi. I modelli dovrebbero affrontare le ambiguità che le regole fisse non riescono a risolvere in modo netto.

La partita illustra anche il valore della memoria esternalizzata. Jev non aveva bisogno di una trascrizione conversazionale in continua crescita, perché l'infrastruttura ricostruiva una descrizione dello stato attuale per ogni decisione. La cronologia rilevante doveva essere memorizzata dall'applicazione e inserita quando necessario.

Questo design riduce il rischio che un contesto lungo si riempia di piani superati. Costringe inoltre gli sviluppatori a decidere quali fatti siano importanti. Questa chiarezza può migliorare l'affidabilità, ma trasferisce una responsabilità significativa dal modello al progettista del sistema.

Un chatbot generalista nasconde gran parte di questo lavoro. Gli sviluppatori possono passare uno screenshot, fornire un obiettivo generale e chiedere al modello di decidere cosa fare dopo. L'interfaccia sembra semplice, mentre il modello assorbe percezione, interpretazione, pianificazione e generazione della risposta.

L'apparente semplicità comporta costi che vanno oltre il calcolo. Quando qualcosa fallisce, lo sviluppatore deve identificare se il problema deriva dalla visione, dalla memoria, dal ragionamento, dalla selezione dello strumento o da un'istruzione poco chiara. Una lunga risposta in linguaggio naturale può offrire indizi, ma non garantisce una diagnosi precisa.

Una pipeline decisionale tipizzata espone prove diverse. Il progetto Jev registrava lo stato completo, le opzioni, le probabilità e la latenza per ogni chiamata. Gli sviluppatori potevano verificare quali scelte fossero disponibili e se il modello esprimesse incertezza.

Questa registrazione trasforma il fallimento di un agente in una domanda ingegneristica più specifica. Il modello ha scelto male nonostante un contesto adeguato? L'infrastruttura ha omesso un'opzione necessaria? Una decisione corretta di alto livello si è trasformata in una cattiva sequenza di pulsanti? Ogni risposta suggerisce una correzione diversa.

Ciò non significa che un modello decisionale vinca sempre. Gli ambienti aperti introducono regolarmente eventi che gli sviluppatori non avevano previsto. Un modello a scelta delimitata non può selezionare un'azione che la sua applicazione non ha mai offerto.

Un chatbot può talvolta inventare un piano di recupero per una situazione sconosciuta. Può interpretare testo insolito, spiegare perché gli strumenti attuali sono insufficienti o proporre una nuova sequenza di operazioni. L'interfaccia più ristretta di Jev dipende da un altro componente per svolgere questo lavoro.

L’inquadramento Jev contro LLM oscura quindi l’architettura che ha effettivamente avuto successo. L’esecuzione completata ha unito un modello decisionale rapido, un traduttore dettagliato dello stato, codice di pathfinding, checkpoint, protezione dai loop e un modello di frontiera usato durante lo sviluppo.

Quella stack non ha eliminato i large language model. Ne ha spostato uno in un ruolo di supervisione.

Claude Opus 5 ha guidato il sistema oltre i vicoli ciechi

Il coinvolgimento di Claude trasforma il risultato da un colpo di scena tra modelli in una prova a favore di un’architettura AI a due livelli.

Secondo il resoconto dello sviluppatore riportato tramite Google News, Claude Opus 5 ha monitorato i log e contribuito ad adattare le scelte e le formulazioni fornite a Jev. Questo lavoro sarebbe diventato importante quando il modello decisionale ha raggiunto dei vicoli ciechi.

L’intervento sembra essere avvenuto attraverso modifiche durante lo sviluppo, anziché con Claude che selezionava le mosse in ogni turno di gioco. Questa distinzione preserva il ruolo di Jev nell’assumere le decisioni registrate. Tuttavia, complica le affermazioni secondo cui un sistema non-LLM avrebbe avuto successo in autonomia dove i chatbot hanno fallito.

Un modello può scegliere bene solo in base al mondo che riceve. Si immagini un agente che cammina ripetutamente verso un percorso bloccato perché il prompt non identifica un oggetto necessario. Riformulare le opzioni disponibili può aiutare, ma la correzione più profonda consiste nell’aggiungere lo stato mancante.

Un modello di frontiera è adatto a esaminare simili fallimenti. Può leggere una lunga traiettoria, confrontare i tentativi ripetuti, dedurre quale fatto manca e proporre modifiche all’harness. Si tratta di compiti aperti che implicano diagnosi e nuovo testo, proprio i lavori per cui Jev non è progettato.

L’assetto risultante ricorda la distinzione tra pensiero rapido e lento. Jev gestisce giudizi frequenti e circoscritti. Claude svolge analisi meno frequenti quando il sistema si comporta male o incontra una situazione che i suoi progettisti non hanno saputo rappresentare.

Non si tratta solo di un compromesso imposto dai limiti di Jev. Potrebbe essere un utile schema di produzione. La maggior parte degli eventi software è ordinaria, mentre una quota minore richiede un’interpretazione più approfondita. Inviare ogni evento al modello più capace può sprecare risorse e introdurre ulteriore latenza.

Un modello supervisore può invece analizzare i casi incerti, esaminare gruppi di fallimenti o riscrivere la politica decisionale. I suoi miglioramenti possono poi avvantaggiare migliaia di chiamate successive effettuate dal componente più rapido.

Tuttavia, il processo di coaching richiede una documentazione più rigorosa prima che i ricercatori possano considerare l’esecuzione un confronto pulito. Il riepilogo pubblico non fornisce una baseline controllata con il solo Jev e l’harness finale. Inoltre, non quantifica con quale frequenza Claude abbia modificato il sistema né quanti progressi siano seguiti a ciascuna modifica.

La cronologia del repository contiene centinaia di commit, rendendo l’evoluzione ispezionabile in linea di principio. Eppure una sequenza di commit di sviluppo non equivale a un protocollo sperimentale. Un confronto adeguato dovrebbe congelare l’ambiente, definire regole di intervento ed eseguire più prove con seed controllati.

Esiste un’altra fonte di ambiguità. Ogni benchmark per agenti include scaffolding, ma lo scaffolding può incorporare una conoscenza sostanziale del compito. L’harness di Jev conosceva le tappe della storia e le località, calcolava i percorsi, stimava i danni e preparava azioni legali.

Un’esecuzione con chatbot che riceve solo screenshot e strumenti generici per i pulsanti affronta un problema diverso. Deve svolgere più percezione e pianificazione all’interno del modello. Confrontare i tempi di completamento senza allineare queste interfacce rischia di attribuire al modello vantaggi forniti dall’harness.

L’interpretazione corretta non è né il disconoscimento né il trionfalismo. Jev ha compiuto migliaia di scelte consequenziali all’interno di un sistema che alla fine ha completato il gioco. Claude ha aiutato gli ingegneri a migliorare quel sistema. Insieme hanno prodotto un risultato più rapido di varie celebri dimostrazioni con chatbot, ma non hanno svolto lo stesso test.

Cosa il risultato non dimostra

Un singolo playthrough riuscito non può stabilire che i modelli decisionali siano generalmente più intelligenti, più autonomi o più affidabili degli agenti LLM.

La maggiore incertezza riguarda la riproducibilità. Il risultato pubblicato descrive un’esecuzione completata dopo uno sviluppo attivo del sistema circostante. Pokémon contiene incontri casuali, esiti incerti delle battaglie e molte possibili configurazioni della squadra.

Una seconda esecuzione potrebbe seguire un altro percorso o bloccarsi in una località diversa. Ripetere l’esperimento rivelerebbe se il sistema completa il gioco in modo affidabile oppure se ha beneficiato di una traiettoria favorevole.

L’assetto manca inoltre di un concorrente comparabile. Per confrontare Jev con Claude in modo equo, entrambi i modelli avrebbero bisogno della stessa rappresentazione dello stato, delle stesse opzioni, della navigazione deterministica, delle regole di recupero e dei checkpoint. Altrimenti, il benchmark misura due combinazioni diverse di modello e software.

Un esperimento utile eseguirebbe tre configurazioni. Una userebbe Jev con l’harness congelato. Un’altra sostituirebbe Jev con un modello general-purpose preservando ogni altro componente. Una terza userebbe il sistema ibrido con un supervisore che esamina fallimenti selezionati.

I ricercatori confronterebbero quindi tassi di completamento, decisioni, numero di interventi, tempo reale e comportamento di recupero in prove ripetute. Queste misurazioni mostrerebbero dove il modello specializzato è utile e dove rimane necessario un modello di frontiera.

L’uso dell’ispezione della memoria da parte dello sviluppatore limita anche conclusioni più ampie. Leggere lo stato strutturato del gioco elimina il problema della percezione visiva. Questa scelta è ragionevole per testare le decisioni, ma non dimostra che Jev possa operare direttamente in ambienti visivi disordinati.

Le applicazioni reali raramente offrono elenchi perfetti di opzioni legali. Un router di assistenza potrebbe ricevere un nuovo problema che non rientra in nessuna categoria nota. Un agente per browser potrebbe imbattersi in una pagina ridisegnata. Un robot fisico potrebbe osservare un oggetto che il suo pianificatore non ha mai rappresentato.

I modelli delimitati necessitano di vie d’uscita sicure per questi casi. Le soglie di confidenza possono inviare decisioni incerte a una persona o a un modello general-purpose. Le applicazioni necessitano inoltre di un modo per rilevare quando manca del tutto la scelta corretta.

La probabilità da sola non risolve il problema. Un modello può esprimere grande fiducia tra alternative sbagliate perché ogni opzione disponibile è errata. Gli sviluppatori devono convalidare l’insieme delle azioni e monitorare gli esiti a valle.

La protezione dai loop di Jev dimostra la necessità di tali salvaguardie. L’harness etichettava le scelte inefficaci, campionava alternative dopo fallimenti ripetuti e ripristinava checkpoint come ultima risorsa. Questi meccanismi hanno impedito che un singolo giudizio errato intrappolasse il sistema per sempre.

Significano anche che il completamento non è stato esclusivamente il risultato di scelte corrette a ogni passaggio. Il sistema tollerava gli errori e si riprendeva da essi. L’AI in produzione necessita della stessa qualità, anche se i flussi di lavoro aziendali spesso non dispongono di un comodo checkpoint in grado di annullare i danni.

Un’azione sbagliata nel gioco può costare minuti. Un’eliminazione, un pagamento o una risposta a un cliente errati possono avere conseguenze durature. Gli sviluppatori che prendono in considerazione un’architettura in stile Jev devono definire quali decisioni sono reversibili e quali richiedono approvazione.

L’esperimento dice anche poco sulla sicurezza. Un modello che acquisisce testo da fonti esterne può incontrare istruzioni manipolative o contesto fuorviante. Limitare l’output a scelte tipizzate restringe la superficie d’azione, ma non garantisce una corretta interpretazione.

Infine, Pokémon Red è un ambiente noto e stabile. Le sue mappe, le meccaniche di battaglia, i menu e la struttura narrativa non cambiano durante l’esecuzione. Questa stabilità consente agli ingegneri di costruire un traduttore dello stato insolitamente dettagliato.

Molti ambienti aziendali cambiano continuamente. I documenti arrivano in nuovi formati, le policy evolvono e gli strumenti restituiscono dati incompleti. Quanto più volatile è l’ambiente, tanta più manutenzione richiede l’harness.

L’esecuzione sostiene quindi un’ipotesi progettuale, non una classifica universale. I modelli decisionali specializzati appaiono promettenti quando le azioni sono delimitate, il contesto può essere strutturato e il software deterministico può eseguire il risultato. I modelli general-purpose restano preziosi quando il sistema deve interpretare novità, generare piani o riparare la propria rappresentazione.

Tre segnali mostreranno se il risultato di Jev conta

Il prossimo test è verificare se l’architettura regge alla ripetizione, ai confronti comparabili e ad ambienti che non sono stati accuratamente preparati attorno ad essa.

Per prima cosa, occorre osservare esecuzioni riproducibili di Pokémon con una versione congelata dell’harness. Più completamenti non assistiti rafforzerebbero l’affermazione che il sistema rappresenti un ciclo decisionale affidabile. I fallimenti pubblicati sarebbero altrettanto preziosi, perché rivelerebbero quali parti della rappresentazione dello stato restano fragili.

La pubblicazione più utile includerebbe traiettorie complete, versioni fisse dei modelli, log degli interventi e una definizione chiara del completamento. Dovrebbe separare il recupero automatizzato dalle modifiche umane effettuate tra un’esecuzione e l’altra. Senza questa separazione, gli sviluppatori non possono stabilire se i miglioramenti siano derivati dal modello o dal lavoro ingegneristico continuo.

In secondo luogo, occorre cercare un test comparabile tra Jev e LLM. Entrambi i sistemi dovrebbero ricevere stato, scelte, codice di navigazione e regole di checkpoint identici. Ciò trasformerebbe l’attuale contrasto architetturale in un confronto misurabile tra modelli.

Un test comparabile potrebbe mostrare che un LLM ha prestazioni simili ma risponde più lentamente. Potrebbe mostrare che Jev eccelle nelle scelte di routine ma perde nelle situazioni rare. Potrebbe anche rivelare che l’harness dettagliato rimuove la maggior parte del carico di intelligenza da entrambi i modelli.

In terzo luogo, occorre osservare applicazioni fuori dai giochi in cui gli esiti abbiano etichette oggettive. Instradamento dei ticket, code di moderazione, classificazione dei documenti, selezione degli strumenti e prioritizzazione degli avvisi sono candidati plausibili. Questi flussi di lavoro producono decisioni ripetute che i team possono verificare rispetto agli esiti successivi.

L’evidenza più solida non sarebbe una dimostrazione eclatante. Sarebbe un’accuratezza stabile con input mutevoli, una calibrazione chiara, bassi tassi di eccezione e un’escalation sicura quando nessuna delle scelte predisposte è adatta.

Per gli sviluppatori, la lezione immediata è pratica. Non chiedete a un singolo modello di svolgere ogni funzione cognitiva solo perché un’interfaccia chat rende semplice tale assetto. Separate percezione, stato, giudizio, esecuzione, memoria e recupero, quindi valutate ogni confine.

I team possono applicare la stessa idea ai propri flussi di lavoro AI conservando il materiale sorgente alla base di ogni decisione. Una base di conoscenza ingegneristica ricercabile può aiutare i revisori a collegare il comportamento del modello con specifiche, log e correzioni precedenti.

L’esperimento Jev su Pokémon Red conta perché rende visibile l’architettura. Un modello mirato ha gestito migliaia di scelte, il software ordinario ha eseguito operazioni precise e Claude avrebbe aiutato a riprogettare il sistema quando la sua rappresentazione falliva.

Non è una vittoria netta sugli LLM. È un argomento a favore di usarli meno spesso e in modo più deliberato.

La domanda successiva è se gli sviluppatori possano riprodurre questa divisione del lavoro senza mesi di ottimizzazione specifica per il compito. Se team indipendenti riusciranno a congelare l’harness, ripetere l’esecuzione e portare il modello in flussi di lavoro reali, Jev avrà dimostrato qualcosa di più grande di un modo insolito per completare Pokémon Red.