Pedirle a la IA que haga un juego ya no es nada nuevo hoy en día.

¿Pero qué pasa si no entrega una pequeña página con un botón para pulsar y un personaje que se mueve, sino que trabaja de forma continua durante ocho horas y crea las escenas, los modelos, las texturas y los sonidos?

Felix Rieseberg de Anthropic compartió un experimento de este tipo. Quería ver qué clase de juego podía hacer Claude Fable 5.2 sin añadir comentarios humanos. Según su registro público, esta ejecución llevó unas ocho horas, costó unos 550 dólares según los precios de la API, acumuló aproximadamente 445M de Tokens de entrada y 2.7M de Tokens de salida, y utilizó ampliamente la caché.Compartido original

Estas cifras no son nuestras mediciones, ni son una cotización estándar para «hacer un juego». Sin embargo, en comparación con decir «el modelo ha vuelto a mejorar», al menos nos permiten ver una pregunta concreta: cuando los modelos pueden escribir código de forma sostenida, ¿hacia dónde se moverán los límites de la creación?

Este artículo no compara clasificaciones, sino que analiza principalmente tres casos públicos. Las imágenes proceden de los proyectos o pantallas de demostración mostrados públicamente por los autores; las descripciones relacionadas con el tiempo, el coste y el proceso de generación se ajustan a lo indicado por las fuentes, y no presentan experimentos personales como conclusiones generales.

Lo creado en ocho horas es un pequeño nivel, no una gran obra completa

El juego mostrado por Felix se llama Saltline, un proyecto de disparos en primera persona que se puede experimentar en el navegador.Entrada del proyecto

Pantalla de demostración del juego Saltline mostrada públicamente por Felix Rieseberg

Pantalla de demostración de Saltline, tomada de la portada de vídeo de la publicación original de Felix Rieseberg; solo se cita una imagen estática. Fuente: publicación original del autor.

Su prompt no era largo: quería un juego de disparos en primera persona, con gráficos lo más detallados posible, pero de alcance reducido, que podía ser solo un nivel muy pequeño.Prompt público

Aquí, lo «pequeño» es importante.

Concentrar los recursos de producción en una pequeña parte de la experiencia y hacer un juego comercial rico en contenido, al que se pueda jugar durante decenas de horas seguidas, son dos dificultades diferentes. La mención de gráficos de nivel AAA en el prompt también es solo un objetivo, no una conclusión sobre la calidad obtenida tras una evaluación.

Lo que realmente merece atención es la forma de generación de los recursos. Felix añadió más tarde que las texturas y los modelos son todos funciones, que no hay archivos de imágenes ni archivos de modelos tridimensionales, y que el código fuente está dentro del HTML y puede consultarse por cuenta propia.Información adicional

Según el autor, no se trata de llamar primero a un modelo de imágenes para generar una imagen y luego hacer que se mueva, sino de construir mediante programación los elementos de la escena.

Este camino resulta muy atractivo para los creadores: si se quiere cambiar una luz, ajustar las proporciones de un objeto o sustituir un material, se puede intentar modificar parámetros y lógica, sin tener que regenerar toda la imagen. Para el contenido que necesita interacción, el código también puede encargarse directamente de la cámara, las colisiones y la respuesta a las entradas.

Pero que se pueda modificar no significa que sea fácil de mantener. Aquí no hemos auditado el código fuente del juego ni completado pruebas de compatibilidad en múltiples dispositivos. Una demostración que parece buena todavía está a cierta distancia de un producto estable.

Además, «completado con un solo prompt» también se puede malinterpretar fácilmente. Significa que el autor no siguió dando instrucciones durante esta ejecución, no que el modelo solo hiciera una llamada, y mucho menos que entregara el resultado en unos segundos. Las ocho horas y esa factura forman parte de este caso.

Cientos de mundos tridimensionales son más interesantes que una escena bonita

El experimento de Ethan Mollick llevó esto en otra dirección.

Le dio a Fable una descripción y esperaba crear un viaje que conectara distintos mundos tridimensionales a través de portales y que pudiera avanzar automáticamente. Según su registro en «Fable 5.2 and Jagged AGI», veinte horas después, el sitio web tenía 204 mundos; la cantidad registrada posteriormente en el artículo ya superaba los 450.Artículo del autor

Aquí no se fija la cantidad de un momento concreto como «resultado final». Este es un proyecto que se actualiza continuamente y la cantidad cambiará; lo realmente interesante es la forma de creación que hay dentro.

Mosaico de mundos tridimensionales de Portals mostrado en el artículo de Ethan Mollick

Mosaico de mundos del proyecto Portals; la imagen procede del texto original de Ethan Mollick. Fuente: Fable 5.2 and Jagged AGI.

En el sitio web de Portals, se puede ver un valle cosido con tela vaquera que está siendo abierto por una cremallera, y también entrar en la perspectiva de una mosca de la fruta que toma un frigorífico como su mundo. Hay otro mundo en el que ambos lados del cañón no son rocas, sino archivadores de cajones apilados a gran altura.Proyecto del valle · Proyecto del frigorífico · Cañón de cajones

Mollick escribió que estos mundos se dibujan en tiempo real mediante código, sin usar modelos tridimensionales prefabricados ni archivos de imágenes. Su prompt pedía la colaboración de agentes de arte, programación y evaluación; posteriormente también propuso requisitos como una lista de lugares, un modo para reducir el mareo por movimiento y una galería de imágenes.

Por lo tanto, no se puede describir el sitio web final como «después de unas palabras, las personas ya no participaron en absoluto». El inicio inicial fue muy breve, pero en la posterior elección de direcciones y los ajustes de funciones, todavía hubo personas involucradas.

Para quienes quieren hacer animación interactiva o contenido educativo, creo que este proyecto tiene más valor de referencia que una sola imagen de resultado. Nos sugiere que se puede dejar que el modelo divida una idea en reglas de escena, relaciones espaciales, movimiento y parámetros ajustables, en lugar de limitarse a escribir una descripción en una ventana de chat. Por ejemplo, al explicar el movimiento planetario, se pueden convertir la órbita, el período y la velocidad en variables controlables; al explicar geometría, se puede permitir a los espectadores arrastrar vértices y observar los cambios. Estas son direcciones de aplicación que proponemos basándonos en casos, no declaraciones verificadas de que Fable ya haya completado estos proyectos educativos específicos.

La parte más emocionante, quizá también la parte que más fácilmente se descontrola

La historia de Portals no se detuvo en “cada vez hay más mundos”.

Mollick descubrió que la calidad de algunas escenas era desigual y que distintos equipos repetidamente pensaban en ideas similares. Exigió al modelo pausar la expansión y primero pulir el contenido existente.

Lo que ocurrió después fue muy interesante: los agentes comenzaron a establecer procesos de revisión. Las nuevas versiones debían compararse mediante múltiples evaluadores sobre capturas de pantalla fijas, por lo que los equipos tendían a optimizar para esas capturas; el agente encargado de coordinarlo, al descubrirlo, añadió más reglas.

Según los registros de Mollick, el documento de reglas posteriormente creció hasta 204 secciones y aproximadamente 87.500 palabras. Un proyecto creativo fue ralentizándose gradualmente por su propio proceso de aprobación. Registro del proceso

Esto no es solo una anécdota graciosa.

A menudo consideramos “que revise sus propios resultados” como una ventaja, pero revisar también necesita objetivos. Si cada vez que se descubre un problema se añade una regla, pero no se eliminan los requisitos obsoletos, el sistema podría ser cada vez más riguroso, pero cada vez menos eficiente.

Del mismo modo, tener revisiones no significa tener criterio estético. Que las capturas sean aprobadas, el código funcione y todos los elementos de verificación se superen tampoco significa necesariamente que un mundo valga la pena habitarlo unos minutos más.

Una observación importante de Mollick sobre estos experimentos es que los modelos pueden completar muchos trabajos complejos, pero no necesariamente descubrirán por iniciativa propia que una obra es demasiado larga, demasiado repetitiva o no lo bastante interesante. Al final, todavía se necesita a una persona para sacar el proyecto de la dirección equivocada.

Para la creación, esta limitación merece más atención que un pequeño error ocasional. Porque a menudo se oculta en resultados donde “cada paso se hizo con mucho cuidado”.

El cortometraje de Blender ilustra otra cosa: el modelo puede ser un coordinador entre herramientas

El experimento compartido por Riley Brown, por su parte, introdujo el código en un flujo de trabajo de producción tridimensional más tradicional.

Según su publicación original, Fable escribió código y construyó en Blender una habitación, una mesa, una computadora portátil, iluminación y personajes; la interfaz mostrada en la pantalla de la computadora también era una página web que escribió. Después, el modelo organizó 13 planos, así como las acciones del teclado, los movimientos de los personajes y los cambios de iluminación desde el atardecer hasta la noche y luego hasta el amanecer. Publicación original del autor

Escena de animación de Blender mostrada públicamente por Riley Brown

Escena de animación de Blender, tomada de la portada del video de la publicación original de Riley Brown; solo se cita una imagen estática. Fuente: Publicación original del autor.

Riley también escribió que el renderizado utilizó 10 GPU en RunPod, completó un renderizado en 4K en unos 52 minutos, y que la música y los efectos de sonido utilizaron ElevenLabs.

Por lo tanto, esto no significa que “Fable sea por sí mismo un modelo de generación de video”. Más precisamente, mediante código y herramientas externas, impulsó la construcción de escenas, la animación, el renderizado y la producción de sonido.

La publicación original también proporcionó una cifra de coste de 5,75 dólares, pero no adjuntó una factura completa desglosada. Este artículo no la interpreta como un coste general de producción final que incluya llamadas al modelo, música, efectos de sonido y toda la infraestructura, ni promete basándose en ello que los lectores puedan reproducirlo con el mismo presupuesto.

Para quienes realmente quieren crear contenido, esta distinción es muy práctica.

Si la tarea es obtener rápidamente un fragmento visual, usar directamente un modelo de generación de video puede ser más conveniente. Si necesitas ajustar repetidamente los planos, modificar un objeto concreto, mantener relaciones espaciales o hacer que la animación siga cambios en los datos, vale la pena probar un flujo de trabajo tridimensional impulsado por scripts.

Ambas formas no tienen por qué sustituirse mutuamente. La clave es saber qué contenido necesita ser controlable y editable, y qué partes pueden dejarse al modelo generativo para explorar.

Si realmente quieres probarlo tú mismo, primero cambia “haz algo increíble” por una tarea pequeña que pueda verificarse

Después de ver estos casos, es fácil querer decirle directamente al modelo: hazme un juego completo, o rueda una película de animación.

Yo recomiendo más bien reducir primero el alcance.

Para el juego, crea solo una habitación, una ruta o una mecánica clara; para la animación, crea primero un plano; para el contenido educativo, explica primero con claridad un punto de conocimiento. Primero verifica si el modelo puede completar en el entorno que proporcionas una vez el ciclo de “generar, ejecutar, observar, modificar”, y después decide si ampliar el proyecto.

Tampoco hace falta que el prompt esté escrito de manera muy misteriosa. A continuación hay una descripción de tarea que puede adaptarse, que pertenece a nuestras recomendaciones prácticas y no es el prompt original de los autores mencionados:

Crea una escena interactiva que pueda ejecutarse en el navegador, que muestre solo una idea central y no se extienda hasta convertirse en un juego completo. Antes de comenzar, explica primero el enfoque técnico, las dependencias necesarias y los pasos de ejecución previstos. Expresa en la medida de lo posible mediante código la geometría, los colores y el movimiento de la escena, y concentra como parámetros los elementos de ajuste habituales. Entrega primero una versión mínima ejecutable y luego corrige según los resultados reales de la ejecución. Distingue entre el contenido que ya has probado y el contenido que aún no ha sido verificado; no uses “debería funcionar” en lugar de registros de pruebas. Sin mi confirmación, no compres recursos en la nube, no despliegues en la red pública y no accedas a archivos fuera del directorio del proyecto. Cuando alcances el límite de presupuesto o tiempo acordado, pausa, conserva el resultado actual e indica los problemas restantes.

Aquí, lo más importante no es la redacción, sino los límites de la entrega.

Que pueda ejecutarse requiere un método de inicio y dependencias claros. Que pueda modificarse requiere saber dónde están los parámetros y la lógica central. Que pueda verificarse requiere registros de pruebas, problemas conocidos y las partes que no se han completado.

Las tareas largas también deberían conservar versiones por etapas. Si la última modificación daña la escena, al menos se podrá volver a la versión utilizable anterior, en lugar de que solo quede un registro de chat que diga “se está reparando”. Los sistemas multiagente también pueden empezar primero con una pequeña cantidad de roles claros, en lugar de poner a decenas de agentes a trabajar al mismo tiempo desde el principio. Es mejor dejar claro qué entrega cada uno: quien se encarga de la producción, quien se encarga de comprobar la ejecución real y quien se encarga de evaluar la experiencia visual. Después de que la revisión detecte problemas, también debe haber alguien que decida cuáles vale la pena corregir y cuáles deberían terminar ahí.

El umbral de creación está cambiando, la capacidad de juicio no ha perdido valor

En su presentación oficial, Anthropic posiciona Fable 5.2 para trabajos técnicos difíciles y abiertos, y al mismo tiempo recomienda que, para la mayoría de las tareas cotidianas de programación y conocimiento, se empiece con Opus 5.5 y luego se elija el modelo según la complejidad.Presentación oficial

Al volver a situar este posicionamiento en los tres casos, será más fácil entender su significado.

Saltline muestra la posibilidad de una producción procedimental de larga duración; Portals muestra la capacidad de construir mundos creativos en lote, y también expone la repetición y la expansión del proceso; el cortometraje de Blender muestra cómo el código puede conectar distintas herramientas de producción.

Todo esto merece una mirada seria, pero no hay necesidad de apresurarse a resumirlo como “ya no se necesitan creadores”.

El modelo puede ayudarnos a montar escenas, escribir lógica, organizar tomas e incluso organizar las comprobaciones por sí mismo. Pero qué quiere expresar exactamente una obra, por qué una imagen debe permanecer, cuándo se debería eliminar la mitad del contenido y cuándo ya es lo suficientemente buena, siguen siendo decisiones que deben tomar las personas.

Quizá lo que más vale la pena esperar no es que cualquiera pueda crear una gran obra con una sola frase, sino que algunas pequeñas ideas que antes solo podían quedarse en la mente ahora tengan la oportunidad de convertirse en obras que se pueden abrir, experimentar y seguir modificando.


Fuentes y explicación de las imágenes

Las tres imágenes complementarias del texto citan respectivamente imágenes de exhibición pública o portadas de demostraciones estáticas de los proyectos mencionados, y los derechos de autor pertenecen a los correspondientes titulares de derechos; no representan la obtención de autorización para su reproducción. Antes de la publicación pública, se deben confirmar los permisos de uso de las imágenes, la disponibilidad de los enlaces externos y los requisitos de atribución. La portada del artículo mantiene el póster en inglés de Fable 5.2 preparado para esta creación. Este texto es un borrador de análisis de casos, no una evaluación independiente del rendimiento, ni constituye una garantía del uso comercial del proyecto o de la disponibilidad del modelo.


¿Quieres probar algunas ideas más? Deja un poco más de cuota para crear

Al crear escenas interactivas, modificar la lógica de un juego y depurar animaciones repetidamente, lo que realmente consume Tokens a menudo no es solo la primera generación, sino las posteriores rondas de modificaciones y verificaciones. Si tú también te preparas para convertir estas ideas en tus propios pequeños proyectos, puedes echar un vistazo a Ace Data Cloud Coding Plan.

Coding Plan puede conectarse a herramientas de programación habituales como Claude Code y Codex, lo que te permite seguir escribiendo código, ejecutando pruebas y ajustando obras en un entorno familiar. La promoción actual por tiempo limitado añade Credits sin cambiar el precio de los planes, de modo que los planes del mismo nivel disponen de más cuota para llamadas de Token.

Plan Cuota base Regalo adicional por tiempo limitado Total de la promoción
Coding Plus 400 Credits 100 Credits 500 Credits
Coding Standard 1,200 Credits 400 Credits 1,600 Credits
Coding Pro 3,000 Credits 1,000 Credits 4,000 Credits
Coding Max 8,000 Credits 2,000 Credits 10,000 Credits

La información anterior se basa en la descripción actual de los planes oficiales. La promoción está prevista hasta el 30 de noviembre de 2026 a las 23:59:59 (hora de Pekín); los precios concretos, la elegibilidad para participar y la cuota acreditada estarán sujetos a la página de compra. El alcance de acceso a los modelos Coding es el mismo en los cuatro planes; la principal diferencia son los Credits incluidos.

Los Credits aquí son cuota de llamadas, no una cantidad fija de Tokens; la cantidad real de Tokens que se puede utilizar depende del modelo, de la proporción entre entrada y salida y de la caché. Los planes se gestionan en ciclos de 30 días; renovar antes de que expire permite transferir la cuota restante y extenderla 30 días; la cuota no utilizada al vencimiento caducará. No hay renovación automática, ni se deducirá automáticamente el saldo general. La disponibilidad de Fable 5.2 y la compatibilidad con los clientes estarán sujetas al catálogo actual de modelos y a los permisos de las credenciales.

No hace falta desafiar un gran proyecto de ocho horas desde el principio. Primero elige una pequeña escena que realmente quieras crear, haz que funcione y luego púlila poco a poco con una cuota más amplia.

Enlaces relacionados: