Nesformer mete un emulador de NES en Qwen3.5-4B

Nesformer: un emulador de NES dentro de los pesos de Qwen3.5-4B

Drew Breunig consiguió algo que suena a broma de laboratorio: metió un emulador funcional del CPU 6502 del Nintendo Entertainment System (NES) dentro de los pesos de Qwen3.5-4B. El proyecto, publicado como dbreunig/nesformer, permite cargar ROMs clásicas como Super Mario Bros y jugarlas —muy lentamente— dentro del propio modelo de lenguaje.

Para un founder, lo interesante no es el juego. Es la técnica: demuestra que un LLM puede comportarse como un programa determinista cuando se lo construye contra pruebas de conformidad bien definidas. Eso abre una puerta concreta para validar y controlar modelos en producción.

¿Cómo se construyó el emulador dentro del modelo?

Breunig no escribió el emulador a mano. Según contó en la discusión pública del proyecto, usó Opus 5.5 con apenas dos instrucciones. La primera pedía leer el artículo y el código de qwenputer, el proyecto de Divyansh Agrawal que sirvió de inspiración, y evaluar si se podía emular el chip y la RAM del NES con la misma técnica.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La segunda instrucción fue la que activó la construcción: la idea era tener los pesos y una CLI (interfaz de línea de comandos) para apuntarla a una ROM, aceptando de antemano que no fuera rápido. El propio autor describe el resultado como una corrida "épica" del modelo.

El detalle clave está en el material de referencia. Opus encontró y usó un conjunto de pruebas de conformidad para el CPU del NES publicado hace 15 años por Christopher Pow. Ese tipo de suite —instrucciones de referencia con su resultado esperado— es lo que convierte una tarea difusa en un problema verificable.

El contexto: de qwenputer a nesformer

Breunig se apoyó explícitamente en qwenputer, el proyecto de Divyansh Agrawal que mostró que se podía emular una computadora dentro de los pesos de un modelo. Nesformer lleva esa idea a un caso más ambicioso: no una máquina genérica, sino el CPU exacto de una consola con décadas de documentación y pruebas públicas.

Ese salto importa porque el NES tiene algo que muchos dominios de negocio no tienen: un estándar cerrado, documentado y con tests. La técnica escala mejor donde la especificación es rígida y el resultado esperado es único.

¿Por qué funcionó? La prueba de conformidad como ventaja

Un emulador no es un problema creativo: es un problema de especificación. Cada instrucción del 6502 tiene un resultado exacto y comprobable. Cuando existe una suite que enumera esas instrucciones y su salida correcta, el modelo deja de "adivinar" y pasa a tener un objetivo medible.

Esa es la lección transferible. Breunig lo resumió así: es un gran ejemplo de lo que estos modelos pueden hacer cuando tienen buenos materiales de referencia, especificaciones claras, pruebas de conformidad y una dirección precisa.

Para cualquier equipo que use IA para generar código o lógica de negocio, el patrón se repite: la calidad del output depende menos del prompt ingenioso y más de la calidad del oráculo contra el que se valida.

¿Qué tan rápido es? La letra chica del experimento

Según los datos que acompañan al proyecto, nesformer corre entre 150 y 290 veces más lento que la consola real. Es decir: técnicamente funciona, pero no es una alternativa práctica a un emulador tradicional.

La razón es estructural. Un emulador escrito en código ejecuta instrucciones directamente sobre el hardware; nesformer tiene que pasar cada paso por la inferencia de un modelo de 4.000 millones de parámetros. La diferencia de cómputo no es un detalle de optimización: es la distancia entre ejecutar un programa y predecir su siguiente paso.

El debate de fondo: ¿los LLM reemplazan al código?

El proyecto reavivó una discusión recurrente en la industria: si los modelos generativos pueden sustituir al software tradicional. La respuesta que deja nesformer es matizada.

Un emulador convencional es, en términos de cómputo, órdenes de magnitud más eficiente que la versión incrustada en pesos. Por eso el experimento funciona mejor como demostración de posibilidades que como arquitectura de producto. La comunidad lo comparó con otros ejercicios de recursión técnica, como correr Minecraft dentro de Minecraft: impresionantes, pero sin relación con la eficiencia.

Lo que sí cambia es la dirección. Si un modelo puede absorber la lógica de un chip completo, también puede absorber reglas de negocio, validaciones o parsers específicos de un dominio, siempre que exista una especificación clara.

¿Qué significa esto para tu startup?

Tres lecturas prácticas para un equipo que construye con IA:

Invierte en pruebas de conformidad, no en prompts. Si tu producto depende de que un modelo genere lógica correcta, define primero un conjunto de casos con resultado esperado. Es el mismo principio que hizo posible nesformer y es lo que separa una demo de un sistema confiable.
Separa lo que debe ser código de lo que puede ser modelo. Un emulador en pesos es un logro, pero nadie lo pondría en producción. Antes de mover una función crítica a un LLM, pregúntate si el costo de cómputo y la latencia son aceptables para tu caso de uso.
Usa estos experimentos como banco de pruebas. Proyectos abiertos como nesformer o qwenputer son entornos baratos para entender los límites reales de la técnica, sin arriesgar tu roadmap.

Conclusión

Nesformer no va a reemplazar a tu emulador de NES ni a tu backend. Pero sí deja una señal clara: cuando existe una especificación verificable, un modelo puede aprender a comportarse como un programa. La ventaja competitiva no está en el modelo, sino en la calidad de las pruebas que le das.