Andrej Karpathy le dio a Claude Opus 5 el primer párrafo de El Señor de los Anillos, un presupuesto de un millón de tokens (unos 10 dólares) y una instrucción: renderízalo en Three.js. El modelo trabajó unas dos horas seguidas y escribió 5.500 líneas de código que dibujan la escena de forma procedimental. El resultado está publicado y es navegable.
Su valoración, en su propio hilo: algo cutre pero divertido, y le sigue pareciendo increíble que el modelo tenga que colocar y orquestar cada elemento por su cuenta.
Puntos clave
- Entrada: el primer párrafo del libro. Presupuesto: un millón de tokens, unos 10 dólares.
- Salida: 5.500 líneas de Three.js escritas en unas 2 horas de trabajo autónomo.
- El audio lo puso ElevenLabs.
- Karpathy señala que el modelo solo podía comprobar su propio resultado mediante capturas de pantalla, y de ahí salían los errores.
- Lo propone como sustituto del viejo test del pelícano en bicicleta en SVG.
Por qué el test viejo se quedó corto
Durante dos años, la prueba informal para calibrar un modelo era pedirle un SVG de un pelícano en bicicleta. Servía porque medía algo difícil de fingir: entender una escena espacial y traducirla a código, sin poder ver el resultado.
Ese test ya no discrimina. Los modelos actuales lo resuelven bien, y una prueba que todos pasan no informa de nada.
Lo que propone Karpathy sube el listón en tres ejes a la vez. Duración: dos horas de trabajo continuado en lugar de una respuesta. Volumen: 5.500 líneas coherentes entre sí. Y autonomía: nadie le va corrigiendo por el camino.
El cuello de botella que señala
La observación más útil del experimento no es el resultado, es la limitación. El modelo solo podía ver lo que había hecho a través de capturas de pantalla.
Piensa en lo que eso significa. Un programador que monta una escena 3D la mueve, la mira desde varios ángulos, ve cómo se comporta la animación en el tiempo. El modelo tenía fotos fijas. Es como pedirle a alguien que dirija una película viendo solo fotogramas sueltos.
Ahí está el techo actual de los agentes de codificación en tareas visuales. Y explica por qué a Karpathy le parece cutre el resultado: no es que el modelo no sepa colocar un árbol, es que no puede comprobar bien si lo colocó donde quería.
Es el mismo patrón que aparece en las pruebas serias de agentes. En julio contamos que seis días y miles de dólares de cómputo no dieron ningún avance en investigación real. Cuando el agente no tiene una señal fiable de si va bien o mal, la autonomía larga se degrada.
Y en el lado contrario, cuando sí hay señal clara, los resultados son otros: GPT-5.6 Sol reescribió los kernels de GPU de OpenAI y recortó un 20% el coste de servir el modelo. Ahí el criterio de éxito es un número, no una impresión visual.
Por qué importa
Lo que me interesa de este experimento no es Tolkien. Son los 10 dólares.
Dos horas de trabajo autónomo, 5.500 líneas de código, diez dólares. Ese es el precio actual de poner a un modelo a construir algo entero sin supervisión. Y sube todos los meses en capacidad y baja en coste.
La lectura para un operador es directa. Si tienes en la cabeza una herramienta interna que nunca hiciste porque no tenías desarrollador (un panel que cruce dos exports, un visor de stock, una calculadora para el equipo comercial), el coste de intentarlo ha dejado de ser una barrera. La barrera ahora es saber describir bien qué quieres.
Con una salvedad honesta, que es la misma que enseña el experimento: lo que sale en dos horas no es robusto. Es un prototipo que funciona y que te enseña si la idea vale. La robustez viene después, con semanas de uso real y errores corregidos. Nada hecho en dos horas está listo para producción, ni con Opus 5 ni con nadie.
Relacionado
