Construyó una computadora con 277,248 compuertas NAND — y la IA se lo arruinó

Placa de circuito con microchip: un procesador de 16 bits construido con 277,248 compuertas NAND
NAND-16 simula 277,248 compuertas NAND a 23 millones por segundo dentro de tu navegador.

Hay un proyecto en internet que te deja jugar Tetris a 16.4 kHz en un procesador de 16 bits que no tiene un solo transistor de silicio real. No hay CPU de fabrica, no hay GPU, no hay hilos. Hay 277,248 compuertas NAND y nada mas. Y el debate que se desato en Hacker News debajo del proyecto es mucho mas interesante que el Tetris mismo.

Se llama NAND-16 y vive en somethingbig.ai/computer. La descripcion oficial lo resume sin rodeos: “Una computadora de 16 bits construida con 277,248 compuertas NAND. CPU, memoria, sistema operativo y Tetris, todo corriendo sobre las compuertas en tu navegador”.

Eso significa que puedes hacer zoom hasta el nivel de puerta logica individual y ver las senales viajar por el netlist en tiempo real. No es un video renderizado. No es un emulador de otro emulador. La simulacion esta evaluando 23 millones de compuertas por segundo en tu maquina mientras juegas.

Que es realmente una compuerta NAND

Antes de la controversy, la base. Una compuerta NAND es el componente mas simple posible: dos entradas, una salida. Devuelve 0 salvo que ambas entradas sean 1. Eso es todo. Ni suma, ni multiplicacion, ni memoria. Solo eso.

Y aqui esta el punto que hace olvidar el proyecto: puedes construir absolutamente cualquier cosa con NANDs. Invirtiendolas obtenes NOR, y de NOR salen AND, OR y XOR. Con XOR construyes el half-adder, con half-adders el full-adder, y con full-adders un sumador de 16 bits. De ahi sale la ALU. De la ALU sale la CPU. Asi, con una sola primitiva logica, 277,248 veces repetida, aparece una maquina de Turing completa.

El numero no es decorativo. Es aproximadamente el orden de magnitud de la logica en un microcontrolador diminuto, y por eso el navegador aguanta la simulacion en tiempo real.

Las especificaciones que hacen la historia

El depurador embebido en la pagina muestra lo que esta pasando por dentro, y los numeros son reveladores:

El ensamblador en pantalla muestra la instruccion literalmente como ensamblador real: st r0, [r0+IO_FRAME], st r0, [r0-9], kbd.s:98. Esto no es un Tetris dibujado con rectangulos. Es un Tetris que escribe pixeles en un puerto de framebuffer a traves de instrucciones de 16 bits.

Y se llama NANDTRIS, no Tetris, porque Nintendo habria reclamado — con razon, por cierto.

La guerra cultural de los 38 comentarios

Aqui esta la parte que te va a hacer compartir el articulo. El post llego a 74 puntos y genero 38 comentarios. Y el post principal dice, textual: “Valio la pena durante dos anos. Hoy en dia, meh.”

La respuesta que mas se repite es brutal en su simplicidad: “Vibecodie un emulador MOS6502 en Rust hace unos meses. Mi habilidad en Rust es floja y no aprendi absolutamente nada sobre el 6502 ni sobre diseno de CPU”.

El otro bando tambien tiene razon

Y aqui es donde la discusion se pone interesante de verdad, porque la respuesta opuesta es igual de fuerte:

“Los LLM son herramientas como compiladores o motosierras. No decimos que un armario hecho con madera mecanizada sea menos autentico que uno hecho con herramientas de pedernal. No le negamos la autoria a quien escribe programas compilados en un lenguaje de alto nivel sin entender cada rama del arbol de sintaxis abstracta”.

Ese comentario tambien atacaba el problema de la prueba de autoria con la mejor respuesta practica que he leido en meses: “Por supuesto que hay forma de probarlo — preguntale”. El autor describe un proceso de entrevista en el MIT Lincoln Lab que consistia en dar una charla de una hora sobre algo que construiste y luego responder preguntas durante otra hora. Sin entenderlo, no se puede pasar. Es la unica entrevista a prueba de IA.

Mi postura, sin rodeos

Estoy del lado de la segunda. Ver un proyecto asi desarmarse en la discusion por ser “slop” es exactamente la misma logica de quienes dicen que un codigo compilado no es programacion. La pregunta correcta no es si usaste una herramienta, sino si entiendes lo que hiciste.

Pero tampoco voy a ser ingenuo: si el interes se limita a tener una demo bonita y cero comprension de por que un half-adder necesita XOR, el aprendizaje es cero. Eso no lo arregla ningun netlist. La diferencia entre un hobbista y un ingeniero no es el banco de trabajo, es la comprension.

Lo que si es innegable: un proyecto asi es un ejercicio de ensenanza brutalmente bueno. Te obliga a entender registros, buses, timing, ALU y framebuffers. No hay atajo. El que lo hizo, aprendio lo que hizo. Eso es todo.

Por que esto le importa a un dev latino

Porque el mercado de trabajo esta cambiando y la pregunta “como hice esto” se esta volviendo mas dificil de responder con repos publicos. Ese comentario de “tengo proyectos publicos de la era pre-LLM, incluido un emulador 6502” no es nostalgia: es capital de reputacion que tardaste anos en construir y que ahora se construye instantaneamente.

Mi consejo practico: construye algo asi. No importa si usaste un LLM para acelerar. Importa que puedas dar la charla de una hora sin leer una sola linea de tu codigo en voz alta.

Y hazlo publico. Transmitir el proceso en streaming vale mas que cualquier certificado.

Un ultimo detalle que te va a hacer sonreir

El proyecto incluye un boton de Tetris que juega solo, con velocidad ajustable, y un modo “bullet time” para ver las cosas paso a paso. Y un modo TURBO con disclaimer. Alguien gasto horas construyendo un acelerador para un Tetris que corre en compuertas logicas puras a 16 kHz. Eso no es slop. Eso es pasion con excedentes.

El comentario que resume mejor toda la controversy es el de un escetico: “Nadie esta impresionado de que alguien use un martillo para clavar tornillos, y deeply impresionado por herramientas que pelean contigo en cada paso”.

Y tiene razon. Pero la otra mitad de la ecuacion es que esa misma herramienta, en manos de alguien que si entiende que esta haciendo, construye cosas como esto.

Prueba NAND-16 tu mismo: es el mejor argumento a favor de entender la maquina por debajo de los frameworks, y el mejor argumento en contra de dejarlo todo en manos de la maquina.

Comparte esto si crees que el “slop” no es el codigo, sino la falta de comprension. Y si estas del otro bando, dejame por que en los comentarios — quiero ver argumentos de verdad.