Un comedor de puntos amarillo sirve ahora como prueba de fuego para la inteligencia artificial. Pac-Bench pide a cada modelo una sola cosa: crear un Pac-Man completo en una única página HTML, sin segundas oportunidades. El resultado se puede jugar, así que no hay que fiarse de gráficas. Basta con abrir el navegador y comprobar si los fantasmas persiguen bien, si los giros responden y si el laberinto tiene sentido. Los modelos más potentes, con el razonamiento al máximo, salen bastante bien parados. El resto produce juegos rotos o raros. Y hay un detalle curioso: casi ninguno imita el aspecto de píxel grueso del original. Repasamos qué mide esta prueba, qué dicen los resultados y qué conclusiones podemos sacar.

Un examen fácil de enunciar y difícil de aprobar

La idea de Pac-Bench es muy simple. Cada modelo recibe una única instrucción: crear un Pac-Man en una sola página HTML. No hay mensajes de corrección ni ayudas posteriores. Lo que genera a la primera es lo que se evalúa. La tabla de resultados recoge la plataforma, el modelo, el tiempo empleado, los tokens consumidos y el coste de cada intento. Todo esto se puede consultar en la página del proyecto donde además se pueden jugar las versiones generadas.

Esa jugabilidad es la gran ventaja. Muchos tests de IA acaban en una cifra que nadie puede verificar a simple vista. Aquí basta con jugar un minuto para detectar fallos. Una pared mal colocada, un fantasma que atraviesa el muro o una puntuación que no sube se ven al instante.

Qué hay que programar de verdad

Pac-Man parece trivial, pero no lo es. El original tiene 244 elementos comestibles: 240 puntos pequeños de 10 unidades y cuatro píldoras de energía de 50. Al comerse una píldora, los fantasmas se vuelven vulnerables y la cadena de capturas suma 200, 400, 800 y 1600 puntos, es decir, 3000 por píldora si se atrapa a los cuatro. La variante Ms. Pac-Man, que se usa con frecuencia en investigación, tiene 174 puntos por laberinto y arranca con tres vidas, según describe un artículo de arXiv sobre aprendizaje basado en instancias.

El modelo debe encargarse además de la lógica de los cuatro fantasmas. En el juego clásico, cada uno calcula su objetivo con una regla distinta. Uno persigue directamente a Pac-Man. Otro apunta a unas casillas por delante de él. Un tercero combina la posición de dos personajes. El último alterna entre perseguir y huir. Reproducir eso exige entender el diseño original, no solo dibujar un laberinto con bolitas.

A esto se suman los detalles de control. El original trabaja con una rejilla de 28 por 36 casillas y una resolución de 224 por 288 píxeles, a unos 60 fotogramas por segundo. Los giros se almacenan en una memoria intermedia para que el jugador pueda anticipar la dirección antes de llegar a la esquina. Si el modelo no lo implementa, el control se siente rígido, aunque el resto funcione.

Quién sale bien parado

Según el texto de Boing Boing que originó esta nota, Grok y GPT lo hicieron bastante bien. GPT, además, lo resuelve por unos céntimos. Pero la imagen general es menos optimista: en cuanto se sale de los modelos de frontera con razonamiento alto o máximo, los resultados se vuelven extraños y se rompen con facilidad.

Los comentarios en Hacker News ayudan a matizar. Un usuario revisó todos los resultados y concluyó que Opus 5.5 con esfuerzo alto era claramente superior al resto. Destacó el control con memoria de giros, una inteligencia de persecución distinta para cada fantasma y las transiciones entre niveles. Otro modelo de OpenAI completó el encargo, pero con huecos en las tuberías del laberinto y sin la pausa que el juego original hace al comerse un fantasma.

También se critica el estilo propio de algunas propuestas. Los modelos de GPT y Astra tienden a añadir textos de relleno poco afortunados y un aspecto visual personal que no tiene que ver con el juego. Astra, según los comentarios, rodeó el juego de elementos decorativos innecesarios. Es un recordatorio de que cumplir el enunciado no es lo mismo que acertar con el espíritu del original.

El problema del píxel

Hay un detalle que llamó la atención del autor del artículo original. Incluso los resultados más precisos no reproducen el arte de baja resolución de Pac-Man. Algunos añaden líneas de barrido para simular una pantalla antigua, pero los sprites salen suavizados y no con el píxel marcado de 1980.

El autor plantea dos explicaciones posibles. La primera tiene que ver con los datos de entrenamiento. Pac-Man es uno de los juegos más comentados de la historia, pero casi siempre en textos de los años ochenta. Aquellos libros de trucos describían con enorme detalle las mecánicas observando la pantalla, sin hablar de la tecnología ni del código. El autor recuerda uno de su infancia, de Craig Kubey, que detallaba hasta los valores de las frutas. Un modelo entrenado con ese material sabe mucho sobre cómo se juega, pero poco sobre cómo se programa.

La segunda explicación apunta a cómo se construyen los modelos. Si el entrenamiento premia lo que se ve limpio y moderno, el estilo pixelado puede quedar penalizado. No hay forma de confirmar ninguna de las dos hipótesis con esta prueba, pero ambas son razonables y merecen investigación.

Pac-Bench como herramienta

Conviene no sobrevalorar este test. Es una prueba de nicho, de un solo intento y con un solo juego. No dice nada sobre cómo se comporta un modelo programando una aplicación de gestión o depurando un servidor. Pero precisamente por ser tan concreta, tiene valor. Obliga a juntar varias habilidades a la vez: recordar reglas, escribir código coherente, gestionar el estado del juego y cuidar la presentación.

Su punto fuerte es la verificación inmediata. Cualquiera puede comparar dos resultados en un minuto y formarse una opinión propia. Es un tipo de evaluación muy cercano al uso real, donde lo que importa es si el programa funciona al ejecutarlo.

Reflexiones adicionales

Lo más interesante de Pac-Bench no es quién gana, sino lo que revela sobre el conocimiento de los modelos. Saben mucho del juego, pero ese saber se apoya en descripciones externas, no en el código original. Por eso aciertan en reglas y puntuaciones, y fallan en detalles visuales que nadie documentó con precisión.

También deja una lección práctica. El razonamiento alto marca la diferencia en tareas con muchas piezas que encajar. Un modelo ligero puede dar una respuesta rápida y barata, pero en un proyecto con lógica, controles y diseño suele quedarse corto. Para quien use IA a diario para programar, conviene elegir el nivel de esfuerzo según la complejidad real de la tarea.

Por último, queda una pregunta abierta: qué ocurriría con un segundo intento. La prueba actual premia el primer disparo, pero en el trabajo real se itera. Medir cuántas correcciones necesita cada modelo para llegar a un resultado jugable sería un complemento muy útil.