Cuando le pedís a un modelo de lenguaje que dibuje un pelícano en una bicicleta, estás midiendo apenas un instante: una imagen estática, sin tiempo ni continuidad. Andrej Karpathy, cofundador de OpenAI y ex director de inteligencia artificial en Tesla, decidió subir la apuesta con Opus 5: le dio el primer párrafo de El Señor de los Anillos, un presupuesto de 1 millón de tokens (unos $10) y le pidió un render animado en three.js.
El experimento, publicado por Karpathy en X el 2 de agosto de 2026, terminó con Opus 5 trabajando cerca de dos horas y escribiendo 5.500 líneas de código para colocar y animar una escena tridimensional completa, sin que nadie supervisara cada línea.
TL;DR
- Andrej Karpathy le dio a Opus 5 el primer párrafo de El Señor de los Anillos y le pidió un render en three.js.- El presupuesto fue de 1 millón de tokens, con un costo estimado de $10 según Karpathy.- Opus 5 trabajó cerca de dos horas y escribió 5.500 líneas de código para la escena.- El render coloca y anima objetos poligonales en coordenadas x, y, z de forma procedural.- El proyecto quedó público y forkeable en karpathy.ai/lotr-movie/, corre en el navegador.- Karpathy usa el experimento para superar el test clásico del pelícano en bicicleta.- Opus 5 tuvo que tomar capturas de pantalla manuales para auto-revisar su propio trabajo.- Karpathy imagina mundos hiperpersonalizados on demand, tipo GTA efímero de cualquier historia.
Qué pasó
Karpathy planteó el experimento como una forma de ir más allá del típico test de una sola imagen para evaluar modelos de lenguaje. En lugar de pedir un SVG estático, le entregó a Opus 5 tres insumos: el primer párrafo de El Señor de los Anillos, un presupuesto de cómputo de 1 millón de tokens y una instrucción simple, generar un render en three.js de esa escena.
El modelo no devolvió una imagen ni un boceto. Devolvió código: 5.500 líneas que ubican y orquestan assets poligonales en coordenadas (x, y, z), además de la lógica de animación necesaria para moverlos en el tiempo. Karpathy describió el resultado como "kind of janky but fun": funcional, con errores visuales, pero coherente con la escena narrada en el texto original.
El proceso tomó cerca de dos horas de trabajo autónomo del modelo, sin intervención humana línea por línea. Karpathy subió el código fuente a karpathy.ai/lotr-movie/, donde cualquiera puede reproducirlo, verlo correr en el navegador y forkearlo.
Opus 5 escribió 5.500 líneas de código en cerca de dos horas.
Contexto e historia
Durante buena parte de 2025, la comunidad de IA usó el test informal del pelícano en una bicicleta, popularizado por el desarrollador Simon Willison, para comparar modelos: pedirle a un LLM que genere el código SVG de un pelícano montando una bicicleta y evaluar qué tan reconocible resulta el dibujo. Es un test barato, reproducible y fácil de comparar entre modelos.
Karpathy sostiene que ese tipo de pruebas ya no alcanza para diferenciar a los modelos de última generación. Su frase textual en X fue: "We're starting to leave the territory where you'd test an LLM by e.g. 'create an svg of pelican on a bicycle'". La idea detrás del experimento con Opus 5 es generalizar el test: en vez de una imagen fija, pedir una escena completa con movimiento, orquestación de objetos y coherencia narrativa sostenida en el tiempo.
Este tipo de generalización no es exclusiva de Karpathy. Es parte de una tendencia más amplia donde los benchmarks de código y razonamiento migran de tareas cerradas, como una función o un archivo, hacia tareas abiertas y de mayor duración: escribir una aplicación completa, mantener un repositorio o, como en este caso, construir un mundo tridimensional interactivo a partir de una instrucción narrativa.
Detalles técnicos y rendimiento
El aspecto más llamativo del experimento no es visual, es de ingeniería: Opus 5 tuvo que resolver un problema de orquestación espacial sin que nadie le diera coordenadas explícitas. A partir de una descripción textual, el modelo definió qué objetos existían en la escena (el Condado, personajes, vegetación), en qué posición (x, y, z) colocarlos, y qué animaciones aplicarles para representar la narración del párrafo original.
Para entender qué tuvo que resolver el modelo, sirve ver primero cómo se arma una escena mínima en three.js:
import * as THREE from "three";
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
const renderer = new THREE.WebGLRenderer();
renderer.setSize(window.innerWidth, window.innerHeight);
document.body.appendChild(renderer.domElement);
const geometria = new THREE.BoxGeometry();
const material = new THREE.MeshStandardMaterial({ color: 0x2e8b57 });
const hobbiton = new THREE.Mesh(geometria, material);
scene.add(hobbiton);
function animar() {
requestAnimationFrame(animar);
hobbiton.rotation.y += 0.01;
renderer.render(scene, camera);
}
animar();
Este bloque crea una escena, una cámara y un cubo verde que gira sobre su eje: el equivalente a un "hola mundo" en three.js. Lo que hizo Opus 5 es una extensión masiva de esta misma idea, pero con decenas de objetos, geometrías más complejas y trayectorias coordinadas entre sí.
Un fragmento representativo de ese tipo de lógica procedural, colocando personajes a lo largo de una ruta, se ve así:
function colocarPersonajes(escena, ruta) {
ruta.forEach((punto, indice) => {
const geometriaHobbit = new THREE.CapsuleGeometry(0.3, 1, 4, 8);
const materialHobbit = new THREE.MeshStandardMaterial({ color: 0x8b5a2b });
const hobbit = new THREE.Mesh(geometriaHobbit, materialHobbit);
hobbit.position.set(punto.x, punto.y, punto.z);
hobbit.userData.nombre = `personaje-${indice}`;
escena.add(hobbit);
});
}
const rutaCondado = [
{ x: 0, y: 0, z: 0 },
{ x: 2, y: 0, z: -1 },
{ x: 4, y: 0.2, z: -3 },
];
colocarPersonajes(scene, rutaCondado);
La función recorre un arreglo de coordenadas y crea un personaje en cada punto, asignándole una posición y un nombre único. Multiplicá esto por decenas de objetos (árboles, casas, el río) y se entiende por qué el resultado terminó en 5.500 líneas: no es una escena estática, es un sistema que coloca y sincroniza piezas.
Karpathy no publicó cifras de framerate ni de uso de memoria, así que cualquier comparación de rendimiento en tu propia máquina hay que medirla vos mismo. En three.js, la forma estándar de hacerlo es leer renderer.info.render.calls para contar draw calls por frame, y renderer.info.render.triangles para ver la carga geométrica real de la escena.
Para dimensionar qué tan distinto es este tipo de prueba frente al benchmark clásico de una imagen, conviene compararlos lado a lado:
Enfoque de benchmarkQué mideEjemploLimitaciónTest de una imagen estáticaComposición visual en un solo intentoDibujar un pelícano en una bicicleta en SVGNo evalúa planificación temporal ni coherencia narrativaTest de mundo generativoOrquestación de escenas, física simple y animación sostenidaRender en three.js de El Señor de los Anillos con Opus 5El propio modelo no puede ver el resultado en video, solo capturas sueltas
La clave técnica es que colocar un objeto en una imagen SVG es un problema de diseño en 2D con reglas simples. Colocar y animar decenas de objetos en un espacio 3D, manteniendo coherencia entre frames, es un problema de estado que se acumula: cada decisión, como dónde va un árbol o cuándo se mueve un personaje, afecta a las siguientes. Ahí es donde 5.500 líneas de código dejan de ser un capricho y se vuelven necesarias.
flowchart TD
A["Prompt: primer parrafo de El Senor de los Anillos"] --> B["Opus 5 genera codigo three.js"]
B --> C["Coloca assets en coordenadas x, y, z"]
C --> D["Toma captura de pantalla"]
D --> E{"Se ve correcto?"}
E -- "No, hay jank" --> C
E -- "Si" --> F["Render final: 5500 lineas de codigo"]
Cada objeto se posiciona con coordenadas x, y, z definidas por el modelo.
Cómo probarlo
No hace falta pedir acceso a nada para ver el resultado: Karpathy dejó el proyecto público y forkeable en karpathy.ai/lotr-movie/, donde corre directo en el navegador sin instalar nada.
Si preferís bajar el código y correrlo localmente, por ejemplo para modificarlo o entender cómo Opus 5 organizó las 5.500 líneas, lo más simple es servir la carpeta con un servidor estático. Funciona igual en Windows, macOS y Linux:
# macOS / Linux (con Node.js instalado)
npx serve .
# Windows (PowerShell, con Node.js instalado)
npx serve .
# Alternativa sin Node.js, en cualquier sistema operativo con Python 3
python3 -m http.server 8000
Con el servidor corriendo, abrí http://localhost:3000 (o el puerto que indique la terminal) en el navegador. Si vas a experimentar con la escena vos mismo, un punto de partida razonable es instalar three.js como dependencia de un proyecto nuevo:
npm install three
y usar el ejemplo de escena mínima descrito más arriba como base para tus propias pruebas.
💡 Tip: para confirmar qué versión de three.js está corriendo en cualquier demo, abrí la consola del navegador con F12 y ejecutá
THREE.REVISION. Te devuelve el número de build, útil para reproducir errores específicos de una versión.
Impacto y análisis
Karpathy conecta el experimento con una idea más grande: mundos hiperpersonalizados generados on demand. En sus palabras, algo así como un "ephemeral GTA of X on demand": tomás cualquier historia, se la das a un modelo con presupuesto de cómputo suficiente, y el modelo construye un mundo alrededor de ella, aunque sea por unas horas y después se descarte.
La aplicación que menciona explícitamente es narrativa: participar en la historia de El Señor de los Anillos como espectador, como NPC, o como uno de los personajes. Ya no se trata de generar un video prerenderizado, sino un entorno que se puede recorrer, con objetos que reaccionan y se animan.
El propio Karpathy señala la limitación central del experimento: Opus 5 no puede "ver" video ni jugar dentro de los mundos que genera. Para revisar su propio trabajo, tuvo que tomar capturas de pantalla en distintos puntos de la ejecución, una por una, de forma lenta y manual. Ese proceso de auto-verificación falló varias veces, lo que explica buena parte del "jank" que Karpathy reconoce en el resultado final.
💭 Clave: el cuello de botella no es generar código 3D, sino auditar visualmente ese código sin percepción nativa de video o gameplay. Es una brecha multimodal que ningún modelo actual resuelve del todo.
Este punto importa para developers que evalúan agentes de IA para tareas visuales o de interfaz: si el modelo no puede mirar lo que construyó con la misma fidelidad que un humano, cualquier pipeline automatizado de generación de UI, juegos o simulaciones va a necesitar un paso de verificación humana, o herramientas que traduzcan el estado visual a algo que el modelo sí pueda leer, como un árbol de objetos en JSON en lugar de una captura de pantalla.
Qué sigue
Karpathy no da una fecha, pero el experimento funciona como preview de hacia dónde apunta la próxima generación de benchmarks: menos "una imagen, un intento" y más "un mundo, una sesión completa". Si los modelos ganan percepción de video nativa, capaz de ver el resultado de su propio código en movimiento y no solo capturas sueltas, el ciclo de generar, revisar y corregir que hoy toma dos horas y produce jank visible podría acortarse.
Por ahora, el costo de este tipo de experimento (unos $10 por 1 millón de tokens) lo vuelve accesible para cualquier developer con acceso a la API de Opus 5. Es, como dice Karpathy, un ejemplo de tareas que antes nadie haría por lo específicas y demandantes que son, pero que hoy son prácticamente gratis de intentar.
📖 Resumen en Telegram: Ver resumen
Probalo vos: abrí karpathy.ai/lotr-movie/ ahora mismo y mirá correr en tu navegador las 5.500 líneas que escribió Opus 5.
Preguntas frecuentes
¿Qué es Opus 5?
Es el modelo de lenguaje que Andrej Karpathy usó en este experimento para generar el render en three.js de El Señor de los Anillos a partir de una instrucción de texto.
¿Cuánto costó el experimento?
Karpathy estimó el costo en unos $10, correspondientes a un presupuesto de 1 millón de tokens.
¿Cuánto tiempo tardó Opus 5 en generar el resultado?
Cerca de dos horas de trabajo autónomo, según describió Karpathy en su publicación en X.
¿Dónde puedo ver el resultado?
El proyecto está publicado y es forkeable en karpathy.ai/lotr-movie/, corre directo en el navegador.
¿Qué es el test del pelícano en una bicicleta?
Es una prueba informal, popularizada por el desarrollador Simon Willison, que consiste en pedirle a un LLM que genere el SVG de un pelícano montando una bicicleta para comparar qué tan bien razona sobre composición visual.
¿Por qué Opus 5 tuvo errores visuales en el render?
Porque no puede percibir video ni jugar dentro del mundo que genera de forma nativa. Tuvo que auto-revisar su trabajo tomando capturas de pantalla manuales, un proceso lento que introdujo fallos.
Referencias
- Publicación original de Andrej Karpathy en X: hilo donde describe el experimento con Opus 5 y El Señor de los Anillos.- karpathy.ai/lotr-movie/: código fuente y demo jugable del render generado por Opus 5.- three.js: documentación oficial de la librería usada para renderizar la escena en el navegador.- simonwillison.net: blog de Simon Willison, quien popularizó el test del pelícano en bicicleta como benchmark informal de LLMs.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)