Un LLM programo un jugador de Arkanoid y derroto al jefe en 10 de 10 partidas

Un problema habitual de los agentes de IA es el siguiente: el modelo escribe codigo con seguridad, lo ejecuta y anuncia que ha tenido exito, pero nadie puede demostrar que la tarea se haya resuelto realmente. Un experimento con el juego de DOS Arkanoid mostro este problema literalmente en pantalla. El LLM recibio el juego sin API ni acceso a la memoria del proceso: solo una imagen de 320 × 200 pixeles, controles de raton y teclado, y la posibilidad de volver a estados guardados. El jugador resultante derroto al jefe DOH en 10 de 10 partidas, con una media de 343.977 puntos.

Por que no funciono el entrenamiento

El primer intento siguio el enfoque habitual: el LLM ayudo al autor a escribir un sistema de aprendizaje por refuerzo. El agente realizo 17 millones de pasos durante aproximadamente 17 horas, pero se estanco en una puntuacion media de 7.000–8.000 puntos. Veia una imagen reducida, movia la pala en pequeños incrementos y recibia una recompensa basada en la puntuacion.

El problema se ocultaba en la mecanica del rebote. Si la pala golpeaba la pelota en distintos puntos dentro de una franja de aproximadamente 12 pixeles desde el centro, el angulo cambiaba desde una trayectoria suave hacia la izquierda hasta otra suave hacia la derecha. En la imagen reducida, la pelota se convertia en una mancha, mientras que los controles no permitian colocar rapidamente la pala en el punto necesario. El autor señalo esta relacion, pero la nueva ejecucion nunca llego a completarse.

Este era el enfoque de Software 2.0: una persona elegia la arquitectura, los datos, la recompensa y el metodo de entrenamiento, mientras el LLM ayudaba a construir el sistema dentro de esos limites. Aceleraba el trabajo, pero no decidia que metodo necesitaba la tarea.

Que cambio en el segundo intento

Despues se asigno un papel diferente al mismo LLM. En lugar de pedirle que escribiera un sistema de entrenamiento, se le dio acceso al emulador, al fotograma completo, a un control preciso del raton, a estados guardados para realizar experimentos repetibles y a un objetivo: comprender el juego de forma autonoma y escribir un programa jugador.

El modelo comenzo como investigador. Encontro los ajustes, aprendio a saltarse la introduccion, creo plantillas de digitos para leer la puntuacion y observo que podia desplazar la pala por todo el campo en un solo fotograma. Despues planteo un experimento: reprodujo varias veces el mismo instante, cambio el punto en el que la pala encontraba la pelota y midio la trayectoria. Asi aparecieron seis zonas de rebote. El jugador empezo a calcular el vuelo para cada zona y a elegir el golpe que destruyera los ladrillos con mayor rapidez.

Las primeras versiones cometian errores. La pala temblaba cerca del borde, la pelota quedaba atrapada en una de las rondas avanzadas y el jefe final disparaba proyectiles que el jugador no habia visto antes. El investigador examinaba los fotogramas anteriores a cada derrota, formulaba una hipotesis, modificaba el codigo y repetia la prueba. Para el jefe, añadio una prediccion del punto en el que el proyectil cruzaria la linea de la pala. Para los bucles, incorporo una regla que deja pasar deliberadamente la pelota y reinicia el saque.

Un detalle importante: el LLM no jugo las partidas finales. Escribio un programa determinista convencional que podia inspeccionarse y probarse. El modelo exploro un entorno desconocido, mientras que un codigo rapido ejecutaba la estrategia descubierta.

Que pueden aplicar los equipos de producto

La primera regla es proporcionar al agente un entorno aislado. Puede ser una copia de un CRM sin pagos reales, una base de datos de prueba o un emulador de un proceso de produccion. El agente debe poder equivocarse, repetir el experimento y volver a un estado anterior.

La segunda regla es diseñar la verificacion antes de automatizar. En el experimento, un evaluador independiente calculaba el resultado: iniciaba el juego con distintos retrasos, leia la puntuacion y confirmaba la pantalla final. El investigador no podia ponerse su propia nota. En una empresa, el equivalente seria una prueba automatizada, una conciliacion de saldos o un conjunto de casos de control.

La tercera regla es separar la investigacion de la ejecucion. Un LLM resulta util cuando hay que comprender una situacion nueva, diseñar un experimento y proponer una solucion. Es mejor delegar una operacion repetible a un programa convencional con entradas claras, un registro de acciones y pruebas.

El experimento no demuestra que un agente pueda manejar cualquier sistema: el juego esta acotado, la respuesta es rapida y las metricas publicadas proceden de un unico proyecto. Sin embargo, ilustra bien un principio arquitectonico. Un agente potente no es un chat situado junto a un proceso. Es un investigador dentro de un ciclo seguro: observacion, hipotesis, experimento, codigo y verificacion independiente.