Demoscener: IA que autocompleta demos de 140 caracteres

Qué es Demoscener y por qué nació de un demo de MS-DOS

Un desarrollador entrenó un modelo de lenguaje capaz de autocompletar demos de JavaScript de 140 caracteres, y lo hizo con un dataset de 25.000 dweets más 1.300 de validación. El proyecto, llamado Demoscener, arranca de una obsesión poco convencional: entender cómo se construyen los efectos visuales del demoscening y el sizecoding, la disciplina de generar gráficos impactantes con la menor cantidad de código posible.

El punto de partida fue "Memories", un demo de MS-DOS de HellMood. Al leer el writeup del autor, el creador de Demoscener se preguntó cuántas direcciones alternativas podrían haber tomado las mismas ideas subyacentes. La respuesta estaba en Dwitter.net, una plataforma que funciona como un Twitter de demos en JavaScript de 140 caracteres, donde cualquier pieza se puede "remixear" para construir encima.

La observación clave fue esta: algunos remixes comparten porciones sustanciales de código y difieren por pocos caracteres, mientras que otros logran efectos visuales parecidos con implementaciones totalmente distintas. Esa es exactamente la propiedad que comparten los lenguajes naturales y los de programación: una gramática finita habilita un número enorme de expresiones posibles. El autor calcula que, quitando los últimos 30 caracteres a un programa de 140 y asumiendo un alfabeto de apenas 64 símbolos, existen cerca de 1,5 x 10^54 terminaciones posibles. Casi todas serán inválidas o aburridas, pero el espacio es astronómico.

Cómo se entrenó: del continued pretraining al curriculum

El primer obstáculo fue el dataset. El autor probó generar dweets sintéticos con Claude Sonnet 5.5 y los encontró estéticamente desagradables. Terminó usando la API de Dwitter para armar el corpus real de 25.000 programas.

Como base eligió Qwen2.5-Code-7B, un modelo de código de propósito general. El problema: fallaba al completar la mayoría de los dweets, algo esperable dado que estos programas usan trucos de code golfing y notación matemática abreviada que un modelo generalista casi nunca ve. La solución fue continued pretraining (CPT) sobre el corpus, para desplazar la distribución de probabilidad del modelo hacia ese dialecto particular.

Para medir si funcionaba, el autor usó la surprisal: la probabilidad negativa logarítmica que el modelo asigna a un token dado todo lo anterior. Tras el CPT, buena parte del código se volvió notablemente menos sorprendente. En 30 dweets reservados, la perplejidad cayó de 28,63 a 8,57.

El segundo salto vino del curriculum learning. Dwitter tiene un puntaje de "awesomeness" por cada dweet, y el autor lo usó para rankear los 5.000 mejores y construir un curriculum que, a lo largo de 400 pasos de entrenamiento, fue favoreciendo progresivamente los programas mejor valorados. Al inicio cada dweet tenía la misma probabilidad de ser muestreado; al final, el top 1000 concentraba cerca del 67% de la probabilidad de muestreo. El resultado fue un salto cualitativo: las continuaciones generadas se volvieron mucho más interesantes desde lo visual.

Lo llamativo es que la mejora se extendió a dweets que nunca fueron muestreados durante el curriculum. La perplejidad bajó de 7,42 a 5,65, y las ganancias se repartieron de forma bastante pareja entre todos los rangos de awesomeness.

RLHF con un solo humano como función de recompensa

Con un modelo que ya producía continuaciones atractivas, el autor quiso inyectar su propio gusto estético. Se inspiró en un artículo de Surya sobre entrenar IA para pintar con código usando p5js, donde se habían probado distintas funciones de recompensa hasta quedarse con comparaciones por pares contra un conjunto de pinturas calificadas a mano.

La implementación fue RLHF con GRPO, con el propio autor actuando como función de recompensa. Para cada dweet sin terminar, muestreaba un grupo de ocho completaciones, las renderizaba lado a lado y elegía la que le parecía más bella. Si ninguna le gustaba, saltaba el grupo. Con esas preferencias actualizaba la política del modelo, generaba nuevas continuaciones y repetía el proceso durante unas 9 a 10 rondas de 500 grupos cada una. En total, inspeccionó a mano alrededor de 40.000 animaciones.

El autor admite, con humor, que cerca de la animación número 10.000 empezó a valorar la existencia de los VLMs y de HPSv3 como posibles jueces automáticos, pero ya era tarde para cambiar el enfoque.

Para verificar cuánto de su gusto había transferido, reclutó a un amigo que evaluó 400 sets de demos de cuatro checkpoints elegidos al azar, sin saber cuál modelo había producido cada uno. El checkpoint 4 resultó el mejor valorado y fue el que usó para correr inferencia en su Mac. Demoscener-7B y el dataset quedaron publicados en HuggingFace.

Qué significa esto para tu startup

Más allá del encanto del proyecto, hay tres lecciones que aplican directo a cualquier equipo que quiera adaptar un modelo a un dominio raro.

• El dominio manda sobre el tamaño. Un modelo de 7B de propósito general fallaba en dweets, y no por falta de capacidad, sino por falta de exposición a ese dialecto. Antes de saltar a un modelo más grande, pregúntate si el problema es de capacidad o de distribución. El CPT resolvió lo que el tamaño no resolvía.
• Los datos sintéticos no siempre alcanzan. Generar ejemplos con un modelo grande puede parecer el atajo obvio, pero aquí produjo resultados estéticamente pobres. La API de una plataforma real entregó 25.000 ejemplos auténticos. Si existe una comunidad con datos propios, esa suele ser mejor materia prima que la generación artificial.
• Una señal de calidad barata vale oro. El puntaje de "awesomeness" de Dwitter no fue diseñado para entrenar modelos, pero funcionó como criterio de ranking para el curriculum. Revisa qué métricas de engagement o calidad ya genera tu producto: pueden convertirse en una función de recompensa sin costo adicional.

Sobre el RLHF con un humano en el loop, la advertencia es clara: 40.000 inspecciones manuales es un costo real que solo se justifica cuando el criterio es genuinamente subjetivo y no hay un juez automático confiable. El propio autor señala que los VLMs habrían sido una alternativa más eficiente. Si tu dominio tiene un criterio de calidad medible, automatízalo desde el principio; reserva la anotación humana para lo que de verdad requiere ojo entrenado.

El cierre del proyecto es la parte más inspiradora: el autor construyó una interfaz donde puede generar varias continuaciones desde el mismo prefijo, compararlas visualmente, ramificar desde la que le llama la atención y seguir explorando. No es un producto, es una herramienta de exploración creativa. Y ahí está el insight para founders: a veces el mejor uso de un modelo ajustado no es reemplazar al humano, sino ampliar el espacio de opciones que el humano puede evaluar.

No se encontraron datos adicionales verificables en las búsquedas realizadas; las cifras de este artículo provienen del writeup original del autor.

Fuentes

• I post trained a model on Demoscenes (fuente original)