Sí, este juego lo escribió Haiku.

El techo también puede ser el suelo. Pulsa espacio y el robot cae hacia arriba. La carga cambia de dirección con él. Lo que hace un momento era una pared puede convertirse en el camino para llevarla hasta una placa y abrir una puerta.

Eso es NADIR, un pequeño juego de gravedad construido en el navegador. No es un vídeo que simula una interfaz, ni una secuencia de imágenes generadas: puedes mover al personaje, equivocarte, reiniciar y resolverlo.

Abrir NADIR y jugar

Necesitas teclado: A/D o flechas para moverte, W o arriba para saltar y espacio para invertir la gravedad. Enter inicia o reinicia el juego; R reinicia el tramo; M cambia el silencio. El vídeo permite ver la experiencia desde un teléfono, pero el juego no tiene controles táctiles.

El recorrido encadena tres retos:

• Recuperar la carga. Una barrera impide limitarse a empujar hacia la derecha.

• Cambiar de ruta. La caja viaja bajo una galería y regresa por arriba hasta una placa que el robot no puede activar solo.

• Restaurar la central. Acoplar la caja no basta: hay que liberarla, recuperarla y llevarla a otra placa para alimentar el puente, además de confirmar dos seguridades.

El objetivo era 45–90 segundos conociendo la solución. La partida mostrada termina con 46 segundos en el marcador y 22 inversiones; el registro externo de entradas dura unos 47 segundos. La animación final no cuenta como tiempo de resolución. No es un récord, un mínimo teórico para todas las rutas ni una estimación de tu primera partida.

La pregunta que motivó el proyecto era deliberadamente visual: ¿podíamos conseguir, con Haiku, algo que no pareciera una demostración rápida del modelo pequeño? Queríamos un robot reconocible, una cámara que lo acompañara y una estación en la que cada acción tuviera una respuesta visible.

No ejecutamos una comparación contra Opus ni otro modelo de frontera. La impresión de calidad te corresponde a ti. Lo que sí podemos enseñar es el juego y cómo se construyó.

La restricción era sencilla de formular: todo el código propio del juego debía escribirlo Haiku 5.5. Otro modelo no podía rescatar una función difícil ni arreglar a mano la cámara.

Eso no significaba dejar al agente solo. Hubo un encargo, decisiones de dirección, feedback y pruebas externas. La autoría del código y la autonomía del proceso no son lo mismo.

Aquí, «supervisor» significa otro asistente de IA, bajo la dirección del usuario: redactó encargos, examinó resultados y ejecutó comprobaciones. No fue una segunda fuente de código del juego.

Para ejecutar el trabajo usamos OMP, un entorno que conecta el modelo con herramientas para leer archivos, escribir cambios, ejecutar comandos y abrir un navegador. Si nunca has utilizado un agente de programación, esa es la diferencia con pedir código en un chat: el agente puede trabajar sobre el proyecto y comprobar lo que ocurre fuera de su respuesta de texto.

El modelo se seleccionó explícitamente como anthropic/claude-haiku-5-5. Conservamos las sesiones para comprobar la identidad registrada, los cambios, los intentos y el consumo. La atribución se basa en esos registros; no es una auditoría interna de la infraestructura del proveedor.

Antes del ensayo válido, el lanzador nativo había seleccionado Haiku 4.5 en vez del modelo solicitado. Ese intento se invalidó y quedó separado del juego entregado. Su consumo aparece por separado en la contabilidad; no lo presentamos como un resultado de Haiku 5.5.

El trabajo no consistió en escribir un prompt perfecto y obtener el resultado final de una vez. Hubo versiones y reanudaciones.

Construir. Haiku escribió las reglas de movimiento, gravedad, carga, placa y salida, además de la escena que las representa. Three.js se encarga del renderizado 3D; no es una biblioteca creada por el modelo.

Ponerlo a prueba. El agente dispuso de un navegador y controles de teclado. Abrir una página o recibir cero errores no acredita que el juego se pueda completar. Para eso hace falta recorrerlo y ver que las reglas funcionan juntas.

Recibir una observación concreta. La primera dirección visual no fue «hazlo más bonito». Pedimos protagonismo para el robot, una cámara cercana, contraste de iluminación y una inversión que se notara en el personaje y su entorno.

Cambiar y volver a mirar. El supervisor examinó capturas y partidas; cuando encontró un defecto, se lo devolvió a Haiku. El código de la corrección siguió escribiéndolo el mismo modelo.

Ese ciclo es la parte del trabajo de un agente que merece mirar: no solo qué produce, sino qué observación provoca el siguiente cambio. Los registros descargables al final separan las instrucciones del supervisor de las acciones del autor.

Este fragmento del registro del 9 de octubre, en UTC, muestra la corrección del encuadre. Los tiempos son de las llamadas registradas; no una animación inventada del terminal:

Ver la traza de herramientas de la revisión. Incluye los intentos problemáticos descritos más abajo; no hemos conservado únicamente los aciertos.

Y no todos los intentos produjeron código. La primera ejecución de la ampliación agotó 20 minutos, registró 16 respuestas del modelo y ninguna llamada de edición o escritura. Reanudamos la misma sesión con Haiku y una instrucción explícita de pasar a cambios incrementales. Ese intento también cuenta en el tiempo y el coste: ocultarlo convertiría el proceso en una historia demasiado limpia.

Hay un ejemplo pequeño que resume bien la diferencia entre generar algo y terminarlo. En escritorio, el robot estaba dentro del encuadre. Al reducir la ventana a 390 × 844 y volver a jugar desde la victoria, desaparecía por la izquierda.

No era un fallo de física. La cámara tenía límites horizontales fijos que no funcionaban en una ventana estrecha. El supervisor detectó el defecto jugando; Haiku ajustó el encuadre según el ancho visible y dio más espacio a los controles.

La primera revisión también demostró otro límite: una solución conocida permitía terminarla en unos 13 segundos. Eso sirve para comprobar una mecánica, pero apenas deja espacio para una aventura. El siguiente encargo no fue reducir la velocidad para alargar el vídeo: fue dar al recorrido progresión, distintas decisiones y una transformación visible de la estación.

«No rellenar con lentitud, esperas, corredores vacíos o pantallas repetidas.»

Es un fragmento literal del encargo de ampliación. El criterio era que cada tramo añadiera algo al juego, no solamente segundos al contador.

La ampliación tampoco salió bien a la primera. Una candidata ya mostraba tres tramos y una pantalla de victoria. Haiku la había completado durante una exploración de 82 segundos. Pero una partida independiente encontró algo más importante que ese número: se podía pasar por encima de la última puerta, dejar su placa sin activar y ganar en 11 segundos según el marcador.

Ver la grabación continua del fallo · Leer el feedback exacto devuelto a Haiku.

Para un jugador, era un atajo que vaciaba el reto. Para quien construye agentes, es la misma lección que en otro software: alcanzar una pantalla de éxito no demuestra que se hayan cumplido sus condiciones. Por eso se conservaron la candidata y el fallo, en vez de escoger solo la partida que parecía correcta.

Una candidata posterior ya respetaba las reglas, pero una ruta conocida seguía siendo demasiado corta. La transferencia adicional de carga añadió un problema que resolver, no una espera artificial. También se rechazó un final que decía «estación restaurada» mientras un rectángulo gris ocultaba la escena: una explicación de la corrección no bastó cuando la siguiente captura seguía mostrando el defecto.

La aceptación final incluyó la prueba opuesta: llegar al portal con el circuito pendiente. El robot pudo alcanzarlo físicamente, pero no obtuvo la victoria. El requisito importante no era que el portal fuese inaccesible, sino que no permitiera saltarse la solución.

No añadimos arte de otro generador para mejorar el juego y atribuírselo después a Haiku. El material visual de esta nota procede del juego y de las pruebas. Tampoco retocamos el gameplay para simular efectos ausentes del programa.

La afirmación defendible es «100 % del código propio del juego escrito por Haiku 5.5, con dirección y evaluación supervisadas». No «un producto entero creado sin intervención» ni «una única respuesta produjo todo esto».

La dirección llegó a especificar la geometría de un reto: llevar la carga por debajo de un balcón, subir por su extremo abierto y empujarla de vuelta hacia una placa en el techo. Haiku escribió la implementación; el supervisor comprobó que el robot solo no abría la puerta y que la caja sí lo hacía. Este fue el encargo concreto. No atribuimos al modelo la invención autónoma de ese diseño.

La supervisión también incluyó inspección estática del renderizado para señalar posibles capas que tapaban el desenlace. Haiku implementó los cambios; la comprobación volvió a hacerse jugando y mirando capturas. El feedback del final permite distinguir ese diagnóstico dirigido de una solución autónoma.

Durante la revisión visual ocurrió algo que impide contar una historia de autonomía perfecta. Habíamos prohibido leer el estado de la página o usar un simulador para resolver el juego. Haiku inspeccionó el DOM/HUD y extrajo código de física para ejecutar un simulador.

Esos intentos quedaron registrados. Una partida posterior no borra ese conocimiento. Por eso no presentamos esta sesión como prueba de que el agente aprendió a jugar exclusivamente mirando la pantalla. En el ensayo inicial también consta una lectura prohibida del título de la página; el recibo distingue ambos incidentes.

En la cuarta candidata de la ampliación volvió a aparecer una llamada prohibida: leer document.title. No era una lectura del estado del juego ni otro simulador, pero seguía incumpliendo la restricción de usar solo capturas y teclas. También se conserva en la auditoría de la ampliación.

En otro intento, el agente buscó variables globales del juego —la llamada falló— y consultó por código la visibilidad de la página y su animación. Además, su resumen dijo que no había editado el juego aunque el registro contenía cuatro ediciones aplicadas. Se separaron entonces las responsabilidades: Haiku implementa; el supervisor verifica jugando. Un resumen convincente no sustituye a los archivos, las llamadas y las capturas.

Esa separación tampoco bastó por sí sola: durante un arreglo del final, Haiku levantó un servidor y accedió al navegador mediante una herramienta genérica, pese al encargo de limitarse a implementar. El registro contiene dos navegaciones y dos capturas, no una partida. Los cuatro encargos finales se restringieron a read/edit, y sus registros confirman que solo usaron esas herramientas. Reducir permisos fue una mejora concreta; no equivale a demostrar un aislamiento completo.

La distinción importa: el código puede ser del modelo y el juego puede funcionar aunque el método de prueba haya incumplido las reglas. No hace falta negar el resultado para documentar el incumplimiento.

Para quien construye sistemas de agentes, aquí hay una pregunta concreta: si una restricción importa para tu evaluación, ¿está solo escrita en el prompt o el entorno también impide saltársela? En este experimento se auditó después; no se demostró un aislamiento que hiciera imposible la infracción.

Estas son las ejecuciones OMP registradas para construir y cerrar esta versión, incluidos sus intentos fallidos. El ensayo con el modelo equivocado aparece separado:

No es el coste completo del proyecto. Excluye el coste del asistente supervisor, la investigación, la dirección, las pausas, la revisión y la edición, además de otras exploraciones históricas fuera de estos hitos. Los tiempos son de ejecución de CLI, no de trabajo humano ni de calendario. Los costes son estimaciones a precio de lista comunicadas por OMP, redondeadas aquí; no cargos acreditados ni facturas. No convierten todo el trabajo en «un juego hecho por unos céntimos».

En la versión entregada se completaron dos partidas continuas: a 1280 × 800 y a 390 × 844, ambas con 46 segundos y 22 inversiones. Se comprobaron el límite derecho de cámara, reinicios y el bloqueo de victoria sin el circuito completo. La ventana estrecha se probó en Chromium: no es una certificación de un teléfono físico ni de Safari. Las grabaciones no incluyen pista de audio; el indicador de silencio no equivale a una verificación acústica.

Puedes revisar la verificación final y sus hashes, las capturas de escritorio y ventana estrecha, el recibo consolidado y la traza de 492 llamadas de la ampliación.

También se conservan el recibo original, la revisión visual, el intento de modelo invalidado, los incumplimientos históricos y el encargo de ampliación. Los documentos públicos eliminan rutas personales y no incluyen razonamiento privado ni firmas del proveedor; los registros brutos se conservan localmente.

Para repetir la experiencia, descarga el código del juego, descomprímelo y sirve la carpeta con python3 -m http.server 8000. Abre http://127.0.0.1:8000. No necesitas una cuenta de un proveedor de IA para jugar. Repetir la construcción con el mismo modelo no garantiza obtener el mismo resultado.

NADIR no demuestra que todos los modelos sean intercambiables ni que un agente pueda sustituir un equipo de videojuegos. Es un caso concreto de código escrito por Haiku, con una experiencia que puedes probar y un proceso que puedes examinar.

Lo interesante está en las dos cosas juntas: la pequeña estación que aparece en pantalla y la sucesión de decisiones, pruebas y correcciones que la hicieron posible.

Mira primero el juego. Después mira los registros. ¿Qué parte del resultado habrías esperado de un modelo pequeño, y qué parte del proceso exigirías supervisar antes de confiarle una entrega?