La partida de Jev en Pokémon Red terminó en 37 horas, pero Claude ayudó a construir el sistema ganador
Jev completó Pokémon Red en 37 horas y 40 minutos, poniendo fin a una partida de Jev en Pokémon Red que requirió 16.150 decisiones del modelo. El resultado llama la atención junto a experimentos anteriores con chatbots que pasaron semanas o meses deambulando por juegos similares. Sin embargo, la aparente victoria de un sistema que no es LLM tiene una salvedad importante. El desarrollador afirma que Claude Opus 5 ayudó a diagnosticar fallos y a mejorar el entorno de decisión de Jev.
La distinción importa porque Jev no observaba el juego, no recordaba todo su recorrido ni manejaba un controlador directamente. Un entorno de software personalizado leía datos seleccionados de la memoria de Game Boy, construía opciones legales y añadía información sobre cada una. Jev elegía entonces entre esas acciones preparadas.
Según los informes, Claude operaba en otro nivel del sistema. Revisaba registros, detectaba situaciones en las que Jev carecía de información útil y ayudaba a perfeccionar las opciones e instrucciones presentadas al modelo de decisión. Por tanto, la partida cuestiona una suposición habitual sobre los agentes de IA, pero no demuestra que un pequeño modelo de decisión pueda superar de forma independiente a un chatbot de frontera.
La partida de Jev en Pokémon Red terminó tras 37 horas
El resultado principal es real dentro de la configuración publicada por el desarrollador, pero mide un sistema de software completo, no un modelo aislado.
Christian Mathiesen, desarrollador de Frigade, creó el experimento de código abierto y transmitió su partida finalizada del 25 al 26 de septiembre de 2026. Los datos publicados de la partida del proyecto indican que Jev terminó Pokémon Red en 37 horas y 40 minutos.
El repositorio registra 16.150 decisiones y aproximadamente 39,2 millones de tokens de entrada. Según se informa, una decisión típica tardaba unos 0,4 segundos. Jev sufrió 16 derrotas completas del equipo, incluidas 14 al intentar superar al Alto Mando, y necesitó 15 intentos contra el Alto Mando antes de terminar.
Su equipo final incluía un Charizard de nivel 83 y un Graveler de nivel 62. Nidoqueen, Beedrill, Haunter y Primeape completaban el grupo. Estos detalles muestran que el sistema hizo más que seguir una ruta corta y predeterminada por las primeras zonas.
Jev eligió el inicial, gestionó el equipo, capturó criaturas, seleccionó ataques, compró objetos, se curó, entrenó y decidió adónde viajar. También manejó menús y respondió a indicaciones de la historia. Según el repositorio, el entorno no escribía directamente en la memoria del juego ni alteraba las banderas de eventos.
Sin embargo, el sistema recibió mucha más estructura de la que recibiría una persona con una Game Boy en las manos. El entorno leía la memoria para obtener mapas, información del equipo, condiciones de combate, inventario y texto en pantalla. Convertía ese estado en opciones explícitas con datos útiles asociados.
Para la navegación, código convencional realizaba comprobaciones de colisiones y búsqueda de rutas mediante A*, un algoritmo que calcula un camino hacia un destino definido. Jev no decidía cada pulsación individual de los botones direccionales en el mapa. Elegía objetivos de nivel superior, mientras que software determinista ejecutaba gran parte de su implementación física.
El entorno también incluía hitos de la historia que describían el siguiente objetivo y su ubicación. El progreso se verificaba frente a las banderas de eventos reales del juego. Esto proporcionaba al agente una representación estructurada de su posición en la historia, aunque los objetos ocultos seguían permaneciendo ocultos.
La protección contra bucles añadía otra capa. Las opciones intentadas anteriormente podían recibir advertencias cuando no habían producido cambios. Los fallos repetidos podían activar una selección alternativa. Con el tiempo, el sistema podía recargar su último punto de control de hito.
Estas intervenciones no invalidan la partida. Todo agente de IA práctico depende de software circundante, memoria, herramientas y lógica de recuperación. Sí implican que el logro relevante es una arquitectura de agentes bien diseñada, no una competencia directa entre un único modelo y un cartucho.
La conclusión más defendible es limitada. Un modelo de decisión, combinado con un entorno diseñado específicamente y controles deterministas, completó un juego largo que exige miles de elecciones secuenciales. El experimento no muestra cómo rendiría Jev con píxeles, un espacio de acciones sin restricciones o sin gestión externa del estado.
Por qué Pokémon sigue exponiendo las debilidades de los agentes de IA
Pokémon parece sencillo al nivel de los turnos individuales, pero sus largas cadenas de decisiones dependientes castigan la memoria débil y una recuperación deficiente.
El Pokémon Red original es por turnos, visualmente limitado y permisivo en comparación con un juego de acción rápido. Aun así, exige que un agente mantenga objetivos durante muchas horas. El jugador debe explorar mapas, leer diálogos, formar un equipo, gestionar recursos y recordar qué obstáculos bloquean el progreso posterior.
Una mala elección de combate rara vez termina toda la partida. Sin embargo, pequeños errores repetidos pueden agotar objetos, debilitar al equipo o devolver al jugador a un centro de curación. Un agente debe reconocer que un movimiento atractivo a nivel local puede perjudicar su plan a largo plazo.
Esa combinación convirtió a Pokémon en una prueba pública para modelos de IA de propósito general. En febrero de 2025, Anthropic equipó a Claude 3.7 Sonnet con memoria, capturas de pantalla y herramientas para pulsar botones. Su investigación sobre pensamiento extendido describió partidas que duraron decenas de miles de interacciones.
El experimento expuso debilidades que las conversaciones pulidas con chatbots suelen ocultar. Un modelo puede sonar coherente mientras pierde la noción de su ubicación, repite una ruta fallida o se compromete con un plan desactualizado. Un juego hace visibles esos errores porque cada decisión modifica un entorno persistente.
Más tarde, otros desarrolladores transmitieron sistemas construidos en torno a Gemini, GPT y modelos Claude más recientes. Algunos acabaron completando juegos Pokémon, pero las comparaciones siguieron siendo difíciles. Cada proyecto exponía información distinta, utilizaba sistemas de memoria diferentes y permitía distintas formas de asistencia del desarrollador.
Un análisis de agentes de juego de enero de 2026 describió a los principales modelos como lentos, confusos y propensos al exceso de confianza durante estas partidas. Esa crítica identificó un problema más amplio que Pokémon. Los modelos de propósito general pueden generar una justificación convincente incluso cuando su representación interna del entorno es incompleta.
Jev adopta un enfoque diferente. TypeSafe AI lo describe como un modelo de Sistema Uno, lo que significa que está optimizado para juicios rápidos y acotados, en lugar de para la generación de texto extensa. Acepta contexto y preguntas concretas, y luego devuelve opciones, puntuaciones o probabilidades de sí y no.
La empresa presenta esos resultados como componentes dentro de software convencional. Su introducción a Jev destaca la clasificación, el enrutamiento, la puntuación y las ramificaciones. No presenta a Jev como sustituto de todas las capacidades de un LLM.
Ese papel más limitado encaja sorprendentemente bien con Pokémon cuando el desarrollador reestructura el juego. En la mayoría de los momentos, el jugador no está escribiendo un ensayo ni inventando un plan abierto. Está seleccionando un ataque, eligiendo un destino, comprando un objeto o decidiendo si entrenar.
El desafío consiste en generar el conjunto adecuado de opciones y adjuntar la información correcta. Si el modelo ve todas las opciones relevantes, un motor de decisión rápido puede mantener el juego en marcha. Si el entorno oculta un dato crítico, la velocidad solo ayuda al agente a repetir antes el juicio equivocado.
Por eso el resultado de Jev presiona a los equipos que construyen agentes enteramente en torno a modelos conversacionales. Sugiere que muchos pasos recurrentes de los agentes no necesitan una respuesta costosa y abierta. Un modelo especializado puede manejar una decisión preparada, mientras que el código convencional se encarga de los cálculos exactos y la ejecución.
También cuestiona la idea de que un único modelo grande deba realizar percepción, memoria, planificación, juicio y control dentro de una conversación continua. La partida de Pokémon divide esas responsabilidades en componentes distintos. Esa separación parece ser la contribución más importante del experimento.
Jev frente a los chatbots es la comparación equivocada
La comparación relevante es la IA monolítica frente a un sistema dividido que asigna cada tarea al componente más adecuado para ella.
Un chatbot acepta indicaciones abiertas y produce lenguaje. Esa flexibilidad le permite explicar situaciones desconocidas, escribir planes, interpretar instrucciones ambiguas y recuperarse mediante la conversación. Esa misma flexibilidad puede generar latencia innecesaria y formatos poco fiables cuando el software solo necesita una selección.
Jev no puede redactar un nuevo documento de estrategia ni describir libremente la pantalla. Devuelve un juicio tipado a partir de preguntas y opciones proporcionadas por la aplicación. Esa restricción facilita que el código consuma su salida.
En el sistema de Pokémon, la división del trabajo era explícita. El emulador producía un estado legible por máquina. El entorno transformaba ese estado, calculaba rutas, estimaba resultados de combate y preparaba alternativas legales. Jev aportaba juicio allí donde las reglas rígidas habrían resultado incómodas.
Esta arquitectura se parece más a un flujo de trabajo de producción maduro que a una demostración de chatbot. Los sistemas fiables suelen separar las operaciones deterministas de las probabilísticas. El código debe calcular aritmética, aplicar permisos y validar esquemas. Los modelos deben abordar ambigüedades que las reglas fijas no pueden resolver limpiamente.
La partida también ilustra el valor de la memoria externalizada. Jev no necesitaba una transcripción conversacional creciente porque el entorno reconstruía una descripción del estado actual para cada decisión. El historial relevante debía ser almacenado por la aplicación e insertado cuando fuera necesario.
Ese diseño reduce el riesgo de que un contexto largo se llene de planes desactualizados. También obliga a los desarrolladores a decidir qué hechos importan. Esta claridad puede mejorar la fiabilidad, pero transfiere una responsabilidad significativa del modelo al diseñador del sistema.
Un chatbot de propósito general oculta gran parte de ese trabajo. Los desarrolladores pueden pasar una captura de pantalla, proporcionar un objetivo amplio y pedir al modelo que decida qué sucede a continuación. La interfaz parece sencilla, mientras el modelo absorbe la percepción, la interpretación, la planificación y la generación de respuestas.
La aparente sencillez conlleva costes más allá de la computación. Cuando algo falla, el desarrollador debe identificar si el problema provino de la visión, la memoria, el razonamiento, la selección de herramientas o una instrucción poco clara. Una respuesta larga en lenguaje natural puede ofrecer pistas, pero no garantiza un diagnóstico preciso.
Una canalización de decisiones tipadas expone evidencias diferentes. El proyecto Jev registró el estado completo, las opciones, las probabilidades y la latencia de cada llamada. Los desarrolladores podían inspeccionar qué opciones estaban disponibles y si el modelo expresaba incertidumbre.
Ese registro convierte el fallo de un agente en una pregunta de ingeniería más específica. ¿Eligió mal el modelo pese a contar con contexto suficiente? ¿Omitió el entorno una opción necesaria? ¿Una decisión correcta de alto nivel se convirtió en una mala secuencia de botones? Cada respuesta sugiere una reparación diferente.
Esto no significa que un modelo de decisión siempre gane. Los entornos abiertos introducen habitualmente eventos que los desarrolladores no anticiparon. Un modelo de opciones acotadas no puede elegir una acción que su aplicación nunca le ofreció.
Un chatbot a veces puede inventar un plan de recuperación para una situación desconocida. Puede interpretar texto inusual, explicar por qué las herramientas actuales son insuficientes o proponer una nueva secuencia de operaciones. La interfaz más limitada de Jev depende de otro componente para realizar ese trabajo.
Por tanto, el enfoque de Jev frente a los LLM oculta la arquitectura que realmente tuvo éxito. La ejecución completada combinó un modelo de decisiones rápido, un traductor detallado de estados, código de búsqueda de rutas, puntos de control, protección contra bucles y un modelo de frontera utilizado durante el desarrollo.
Esa pila no eliminó los modelos de lenguaje de gran tamaño. Reubicó a uno en un rol de supervisión.
Claude Opus 5 guio al sistema a través de callejones sin salida
La participación de Claude convierte el resultado de una sorpresa entre modelos en evidencia de una arquitectura de IA de dos niveles.
Según el relato del desarrollador difundido a través de Google News, Claude Opus 5 supervisó los registros y ayudó a ajustar las opciones y el texto proporcionados a Jev. Según se informa, ese trabajo fue importante cuando el modelo de decisiones llegó a callejones sin salida.
La intervención parece haberse producido mediante cambios durante el desarrollo, en lugar de que Claude seleccionara movimientos en cada turno de juego. Esa distinción preserva el papel de Jev en la toma de las decisiones registradas. Aun así, complica las afirmaciones de que un sistema sin LLM tuvo éxito de forma independiente allí donde fallaron los chatbots.
Un modelo solo puede elegir bien a partir del mundo que recibe. Supongamos que un agente camina repetidamente hacia una ruta bloqueada porque el prompt no identifica un objeto necesario. Reformular las opciones disponibles puede ayudar, pero la solución más profunda consiste en añadir el estado que falta.
Un modelo de frontera es adecuado para revisar este tipo de fallos. Puede leer una trayectoria larga, comparar intentos repetidos, inferir qué dato falta y proponer cambios en el arnés. Son tareas abiertas que implican diagnóstico y texto nuevo, precisamente los trabajos para los que Jev no está diseñado.
La disposición resultante se parece a la distinción entre pensamiento rápido y lento. Jev se ocupa de juicios frecuentes y acotados. Claude realiza análisis menos frecuentes cuando el sistema se comporta mal o encuentra una situación que sus diseñadores no lograron representar.
No se trata simplemente de un compromiso impuesto por las limitaciones de Jev. Puede ser un patrón útil para producción. La mayoría de los eventos de software son rutinarios, mientras que un subconjunto menor requiere una interpretación más profunda. Enviar cada evento al modelo más capaz puede desperdiciar recursos e introducir demoras adicionales.
En cambio, un modelo supervisor puede analizar casos inciertos, revisar lotes de fallos o reescribir la política de decisión. Sus mejoras pueden beneficiar después a miles de llamadas posteriores realizadas por el componente más rápido.
Sin embargo, el proceso de tutorización necesita una documentación más estricta antes de que los investigadores puedan considerar la ejecución como una comparación limpia. El resumen público no proporciona una línea base controlada de Jev en solitario con el arnés final. Tampoco cuantifica con qué frecuencia Claude modificó el sistema ni cuánto progreso siguió a cada cambio.
El historial del repositorio contiene cientos de commits, lo que en principio permite inspeccionar su evolución. Sin embargo, una secuencia de commits de desarrollo no equivale a un protocolo experimental. Una comparación adecuada congelaría el entorno, definiría reglas de intervención y realizaría múltiples ensayos con semillas controladas.
Existe otra fuente de ambigüedad. Todo benchmark de agentes incluye andamiaje, pero ese andamiaje puede incorporar un conocimiento sustancial de la tarea. El arnés de Jev conocía los hitos y las ubicaciones de la historia, calculaba rutas, estimaba el daño y preparaba acciones legales.
Una ejecución con un chatbot que recibe solo capturas de pantalla y herramientas amplias de botones afronta un problema diferente. Debe realizar más percepción y planificación dentro del modelo. Comparar el tiempo de finalización sin igualar esas interfaces corre el riesgo de atribuir al modelo ventajas proporcionadas por el arnés.
La interpretación justa no es ni el rechazo ni el triunfo. Jev tomó miles de decisiones consecuentes dentro de un sistema que finalmente completó el juego. Claude ayudó a los ingenieros a mejorar ese sistema. Juntos produjeron un resultado más rápido que varias demostraciones célebres de chatbots, pero no realizaron la misma prueba.
Lo que el resultado no demuestra
Una única partida completada con éxito no puede establecer que los modelos de decisión sean, en general, más inteligentes, autónomos o fiables que los agentes basados en LLM.
La mayor incertidumbre es la reproducibilidad. El resultado publicado describe una ejecución completada tras un desarrollo activo del sistema circundante. Pokémon contiene encuentros aleatorios, resultados inciertos en combate y muchas configuraciones posibles de equipo.
Una segunda ejecución podría seguir otra ruta o quedarse atascada en una ubicación distinta. Repetir el experimento revelaría si el sistema completa el juego de forma fiable o si se benefició de una trayectoria favorable.
La configuración tampoco cuenta con un competidor equivalente. Para comparar Jev con Claude de manera justa, ambos modelos necesitarían la misma representación del estado, opciones, navegación determinista, reglas de recuperación y puntos de control. De lo contrario, el benchmark mide dos combinaciones distintas de modelo y software.
Un experimento útil ejecutaría tres configuraciones. Una usaría Jev con el arnés congelado. Otra sustituiría Jev por un modelo de propósito general conservando todos los demás componentes. Una tercera usaría el sistema híbrido con un supervisor que revisara fallos seleccionados.
Los investigadores compararían entonces tasas de finalización, decisiones, recuentos de intervenciones, tiempo transcurrido y comportamiento de recuperación a lo largo de ensayos repetidos. Esas mediciones mostrarían dónde ayuda el modelo especializado y dónde sigue siendo necesario un modelo de frontera.
El uso de inspección de memoria por parte del desarrollador también limita las conclusiones más amplias. Leer el estado estructurado del juego elimina el problema de la percepción visual. Esa elección es razonable para probar decisiones, pero no establece que Jev pueda operar directamente en entornos visuales desordenados.
Las aplicaciones reales rara vez ofrecen listas perfectas de opciones legales. Un enrutador de soporte podría recibir una incidencia nueva que no encaja en ninguna categoría conocida. Un agente de navegador podría encontrarse con una página rediseñada. Un robot físico podría observar un objeto que su planificador nunca representó.
Los modelos acotados necesitan vías de escape seguras para esos casos. Los umbrales de confianza pueden enviar decisiones inciertas a una persona o a un modelo de propósito general. Las aplicaciones también necesitan una forma de detectar cuándo falta por completo la elección correcta.
La probabilidad por sí sola no resuelve ese problema. Un modelo puede expresar una confianza elevada entre alternativas malas porque todas las opciones disponibles son incorrectas. Los desarrolladores deben validar el conjunto de acciones y supervisar los resultados posteriores.
La protección contra bucles de Jev demuestra la necesidad de estas salvaguardas. El arnés etiquetó elecciones ineficaces, probó alternativas tras fallos repetidos y restauró puntos de control como último recurso. Estos mecanismos evitaron que un mal juicio atrapara al sistema para siempre.
También implican que la finalización no fue resultado exclusivamente de elegir correctamente en cada paso. El sistema toleró errores y se recuperó de ellos. La IA de producción necesita la misma cualidad, aunque los flujos de trabajo empresariales suelen carecer de un punto de control práctico que pueda revertir el daño.
Una acción equivocada en un juego puede costar minutos. Una eliminación, pago o respuesta a un cliente equivocados pueden tener consecuencias duraderas. Los desarrolladores que consideren una arquitectura al estilo Jev deben definir qué decisiones son reversibles y cuáles requieren aprobación.
El experimento también dice poco sobre seguridad. Un modelo que consume texto de fuentes externas puede encontrarse con instrucciones manipuladoras o contexto engañoso. Restringir la salida a elecciones tipadas reduce la superficie de acción, pero no garantiza una interpretación correcta.
Por último, Pokémon Red es un entorno conocido y estable. Sus mapas, mecánicas de combate, menús y estructura narrativa no cambian durante la ejecución. Esa estabilidad permite a los ingenieros construir un traductor de estado inusualmente detallado.
Muchos entornos empresariales cambian continuamente. Los documentos llegan en formatos nuevos, las políticas evolucionan y las herramientas devuelven datos incompletos. Cuanto más volátil es el entorno, más mantenimiento requiere el arnés.
Por tanto, la ejecución respalda una hipótesis de diseño, no una clasificación universal. Los modelos de decisión especializados parecen prometedores cuando las acciones están acotadas, el contexto puede estructurarse y un software determinista puede ejecutar el resultado. Los modelos de propósito general siguen siendo valiosos cuando el sistema debe interpretar novedades, generar planes o reparar su propia representación.
Tres señales mostrarán si el resultado de Jev importa
La siguiente prueba consiste en determinar si la arquitectura resiste la repetición, las comparaciones equivalentes y entornos que no se hayan preparado cuidadosamente a su medida.
En primer lugar, habrá que observar ejecuciones reproducibles de Pokémon con una versión congelada del arnés. Múltiples finalizaciones sin supervisión reforzarían la afirmación de que el sistema representa un ciclo de decisión fiable. Los fallos publicados serían igualmente valiosos, porque revelarían qué partes de la representación del estado siguen siendo frágiles.
La versión más útil incluiría trayectorias completas, versiones fijas de los modelos, registros de intervención y una definición clara de finalización. Debería separar la recuperación automatizada de los cambios humanos realizados entre ejecuciones. Sin esa separación, los desarrolladores no pueden determinar si las mejoras procedieron del modelo o del trabajo de ingeniería continuo.
En segundo lugar, busque una prueba equivalente de Jev frente a LLM. Ambos sistemas deberían recibir estado, elecciones, código de navegación y reglas de puntos de control idénticos. Eso convertiría el actual contraste arquitectónico en una comparación de modelos medible.
Una prueba equivalente podría mostrar que un LLM rinde de forma similar, pero responde más lentamente. Podría mostrar que Jev destaca en elecciones rutinarias, pero pierde ante situaciones poco frecuentes. También podría revelar que el arnés detallado elimina la mayor parte de la carga de inteligencia de cualquiera de los dos modelos.
En tercer lugar, habrá que observar aplicaciones fuera de los juegos en las que los resultados tengan etiquetas objetivas. El enrutamiento de tickets, las colas de moderación, la clasificación de documentos, la selección de herramientas y la priorización de alertas son candidatos plausibles. Estos flujos de trabajo generan decisiones repetidas que los equipos pueden auditar frente a resultados posteriores.
La evidencia más sólida no sería una demostración llamativa. Sería una precisión estable ante entradas cambiantes, calibración clara, bajas tasas de excepción y una escalada segura cuando ninguna de las elecciones preparadas encaja.
Para los desarrolladores, la lección inmediata es práctica. No pidan a un único modelo que desempeñe todas las funciones cognitivas simplemente porque una interfaz de chat hace que esa disposición parezca sencilla. Separen percepción, estado, juicio, ejecución, memoria y recuperación, y evalúen después cada límite.
Los equipos pueden aplicar la misma idea a sus propios flujos de trabajo de IA preservando el material fuente detrás de cada decisión. Una base de conocimientos de ingeniería con capacidad de búsqueda puede ayudar a los revisores a conectar el comportamiento del modelo con especificaciones, registros y correcciones anteriores.
El experimento de Jev con Pokémon Red importa porque hace visible la arquitectura. Un modelo enfocado gestionó miles de elecciones, el software convencional realizó operaciones exactas y, según se informa, Claude ayudó a rediseñar el sistema cuando su representación falló.
No es una victoria limpia sobre los LLM. Es un argumento a favor de usarlos con menos frecuencia y de forma más deliberada.
La siguiente pregunta es si los desarrolladores pueden reproducir esa división del trabajo sin meses de ajuste específico para cada tarea. Si equipos independientes pueden congelar el arnés, repetir la ejecución y trasladar el patrón a flujos de trabajo reales, Jev habrá demostrado algo más grande que una forma inusual de terminar Pokémon Red.
