Andrej Karpathy afirma que los LLMs de Techmeme señalan una nueva era de creación, pero persiste la brecha de auditoría

Andrej Karpathy afirma que los LLMs han superado un umbral notable, pese a conservar una debilidad básica: todavía no pueden inspeccionar de forma fiable lo que construyen. El último debate sobre techmeme llms se centra en sistemas que crean mundos interactivos y personalizados a partir de instrucciones breves. Sin embargo, esos sistemas suelen depender de humanos para detectar físicas defectuosas, objetos mal colocados, fallos visuales e interacciones ausentes.

Karpathy enmarcó el cambio mediante una comparación con una prueba anterior para modelos. Pedir a un LLM que produjera un SVG de un pelícano montando una bicicleta antes revelaba su comprensión del código, la geometría y las relaciones entre objetos. El nuevo desafío es mucho mayor. Ahora un modelo puede generar el software detrás de una escena explorable, con animación, cámaras, iluminación y comportamiento simulado.

Esa escala cambia lo que se considera éxito. Producir miles de líneas de código plausible no equivale a producir un mundo coherente. La competencia central ahora es entre generación y verificación. Los modelos pueden ampliar el artefacto más rápido de lo que pueden percibir, probar y reparar la experiencia resultante.

Los LLMs de Techmeme van más allá de la prueba del pelícano

La publicación de Karpathy marca una transición de evaluar resultados aislados a evaluar experiencias completas.

En su publicación original, Karpathy dijo que el sector estaba dejando atrás el terreno de pruebas como crear un SVG de un pelícano en bicicleta. Describió a los LLMs como sistemas que avanzan hacia mundos hipერპersonalizados generados bajo demanda.

La publicación circuló a través de un debate en Techmeme el 2 de agosto de 2026. El material adjunto mostraba una interpretación animada y tridimensional de una escena ficticia. Parecía combinar código generado, personajes, elementos ambientales, movimiento y comportamiento de cámara.

El material público no establece un benchmark controlado. No revela cada prompt, intervención, reintento o corrección manual implicados. Por tanto, la demostración debe tratarse como evidencia de un posible flujo de trabajo, no como prueba de creación autónoma de mundos.

Incluso con esa salvedad, el cambio es significativo. Un SVG es un artefacto acotado con una superficie relativamente pequeña. Un mundo basado en navegador contiene muchos sistemas que interactúan y que pueden fallar por separado.

El modelo debe elegir posiciones, escalas, colores, materiales y trayectorias de movimiento para los objetos. Debe gestionar el código de renderizado, la temporización, la colocación de la cámara, el estado de las animaciones y los controles del usuario. También debe traducir prosa ambigua en decisiones visuales concretas.

Por eso la prueba del pelícano se volvió útil en primer lugar. Una bicicleta tiene relaciones mecánicas reconocibles. Un modelo puede producir algo que parezca una bicicleta mientras conecta incorrectamente el cuadro, la cadena, los pedales y la dirección.

El software puede ocultar el mismo problema detrás de un espectáculo mayor. Una escena generada puede parecer impresionante durante una grabación breve, pero fallar desde otro ángulo de cámara. Un objeto puede flotar, desaparecer, atravesar una pared o cambiar de tamaño cuando el usuario se mueve.

Estos fallos son más difíciles de resumir que un dibujo malformado. Surgen de interacciones a lo largo del tiempo, no de un único fotograma estático. Un revisor debe explorar el mundo, recordar estados anteriores y comprender qué resultados vulneran el diseño previsto.

La colección en evolución de pelícanos de Simon Willison ilustra por qué las pruebas visuales ganaron atención. Diferentes modelos podían escribir código SVG válido mientras producían interpretaciones visiblemente distintas de la misma solicitud. El resultado expuso carencias que los benchmarks de programación convencionales a menudo pasaban por alto.

Sin embargo, el éxito puede saturar un benchmark. Una vez que los modelos reproducen patrones de prueba conocidos, el prompt deja de distinguir la competencia amplia del entrenamiento específico o las convenciones memorizadas. Un entorno más grande y menos predecible crea más oportunidades para revelar errores.

Por tanto, el último debate sobre techmeme llms no trata principalmente de si el mundo mostrado merece elogios artísticos. Trata de si la unidad de creación con IA se ha expandido. La evidencia sugiere que sí.

Un usuario ya no necesita solicitar solo una imagen, un párrafo, un componente o un script. La solicitud puede describir una experiencia temporal adaptada a una persona. El modelo puede ensamblar esa experiencia a partir de código mientras el usuario espera.

Esto difiere del desarrollo convencional de videojuegos. Un estudio crea un producto compartido para una audiencia amplia y lo prueba antes de su lanzamiento. La generación bajo demanda, en cambio, trata el software como algo temporal, personal y barato de solicitar.

Un docente podría pedir una representación interactiva de un contexto histórico. Un niño podría solicitar un pequeño mundo basado en un cuento para dormir. Un equipo de producto podría convertir un escenario escrito en un prototipo navegable antes de comprometerse con la producción.

Estos resultados no requieren realismo cinematográfico para ser relevantes. Los mundos generados de baja fidelidad aún pueden comunicar relaciones espaciales, ideas de interacción y secuencias narrativas. Su valor puede provenir de la especificidad y la velocidad, más que del acabado.

En consecuencia, la demostración desplaza la pregunta. Ya no es simplemente: “¿Puede un LLM dibujar el objeto solicitado?”. La pregunta más difícil es: “¿Puede mantener un sistema coherente mientras ese sistema se explora?”

Los mundos bajo demanda presionan al software creativo

La presión inmediata recae sobre herramientas que asumen que toda experiencia interactiva requiere un proceso de producción largo y manual.

El software creativo tradicional separa escritura, ilustración, modelado, animación, programación y pruebas. Los especialistas trasladan el trabajo por esas etapas mediante archivos, editores y procesos de revisión. Los sistemas generativos comprimen varias etapas en una única interfaz conversacional.

Esa compresión cambia la economía de los prototipos. Un concepto que antes permanecía dentro de un documento puede convertirse en una escena funcional. Los equipos pueden evaluar la temporización, la escala y la interacción antes de invertir en recursos terminados.

El caso de uso más sólido a corto plazo no es sustituir un videojuego comercial completo. Es generar simulaciones desechables, explicaciones visuales, bocetos narrativos y experimentos de interfaz. Estos resultados solo necesitan durar lo suficiente para responder una pregunta concreta.

Un diseñador de videojuegos podría probar si una mecánica resulta comprensible. Un cineasta podría examinar el bloqueo preliminar de una escena. Un educador podría crear una lección explorable adaptada a los intereses de un estudiante.

Los trabajadores del conocimiento también podrían convertir notas en representaciones interactivas. Una base de conocimiento de IA personal puede conservar el material fuente detrás de esas solicitudes. Ese contexto se vuelve importante cuando una experiencia generada necesita trazabilidad.

La mayor oportunidad es la personalización. Los medios convencionales suelen ofrecer el mismo artefacto a cada espectador. El software generativo puede variar personajes, complejidad, ritmo, idioma o temática en cada sesión.

Un mundo personalizado puede responder a información proporcionada momentos antes. Podría incorporar el proyecto de un usuario, personajes ficticios, objetivos de aprendizaje o estilo visual preferido. Esto acerca el resultado a una aplicación generada más que a una pieza estática de contenido.

Google DeepMind ha seguido una dirección relacionada mediante modelos de mundo, que simulan cómo evolucionan los entornos después de las acciones. Su investigación Genie 3 describe mundos navegables generados a partir de texto a 720p y 24 fotogramas por segundo.

DeepMind informó que esos entornos podían mantenerse coherentes durante varios minutos. También reconoció espacios de acción limitados, dificultades para modelar múltiples agentes independientes y una precisión geográfica imperfecta. Estas limitaciones muestran por qué un vídeo impresionante por sí solo no es suficiente.

El ejemplo de Karpathy representa una ruta técnica distinta. Un LLM puede escribir código gráfico convencional que ejecuta un navegador. Un modelo de mundo especializado genera estados visuales futuros de forma más directa, basándose en fotogramas anteriores y acciones del usuario.

Ambas rutas apuntan a entornos reactivos, pero exponen distintos modos de fallo. El código generado ofrece una estructura de programa inspeccionable y ejecución determinista. Aun así, puede contener supuestos incorrectos sobre geometría, física o significado narrativo.

Un modelo de mundo puede producir imágenes más naturales sin construir explícitamente cada objeto. Su estado interno puede ser más difícil de inspeccionar para los desarrolladores. La coherencia también puede degradarse cuando la interacción se extiende más allá de la memoria efectiva del modelo.

Estos enfoques pueden converger con el tiempo. Un agente podría escribir la lógica de una escena, llamar a modelos de medios generativos, observar el resultado renderizado y revisar ambos. El sistema terminado combinaría estructura simbólica con generación visual.

Esta perspectiva presiona a los motores de videojuegos, herramientas de diseño y suites creativas establecidos para que sean más fáciles de operar por agentes. Sus interfaces fueron diseñadas para humanos que pueden ver el lienzo y comprender una retroalimentación visual sutil.

Un LLM que opera mediante texto no recibe automáticamente esa misma experiencia. Puede conocer cada objeto en el código fuente sin saber cómo luce la escena final. Los creadores de herramientas deben exponer capturas de pantalla, grafos de escena, controles de prueba y diagnósticos estructurados.

Los agentes de programación ya muestran cuán rápido puede producirse esta transición. Anthropic estudió aproximadamente 400.000 sesiones de Claude Code realizadas entre octubre de 2025 y abril de 2026. Su estudio sobre agentes de programación concluyó que las mediciones de verificación todavía dependían en parte de la confirmación explícita dentro de las conversaciones.

Ese detalle importa más allá del desarrollo de software. Si el éxito depende de que el modelo declare que una tarea está completa, el resultado puede parecer más fiable de lo que realmente es. Los mundos interactivos hacen visible ese problema de medición.

Una aplicación generada puede compilarse e iniciarse y, aun así, no cumplir su propósito. Los controles pueden ser incómodos. La escena puede representar incorrectamente la fuente. La interacción más importante podría no funcionar nunca.

Por tanto, las herramientas creativas están bajo presión para proporcionar retroalimentación que los agentes puedan usar realmente. Una integración exitosa debe ayudar al modelo a inspeccionar el comportamiento, no solo a producir más código.

Sin embargo, esas capacidades no garantizan una autoauditoría fiable. El mismo modelo que produjo un diseño equivocado puede repetir su suposición al revisar la captura de pantalla. Puede pasar por alto errores sutiles o justificarlos como decisiones de diseño intencionales.

La investigación sobre la autorretroalimentación multimodal muestra tanto la oportunidad como la limitación. La investigación Volcano concluyó que la retroalimentación visual podía reducir las alucinaciones al ayudar a un modelo a revisar una respuesta inicial. Eso exigía un proceso de retroalimentación diseñado, en lugar de limitarse a la generación.

Esta distinción es el núcleo del argumento de Karpathy. El modelo puede producir los ingredientes de un mundo sin poseer una experiencia continua y nativa de ese mundo. Su acceso suele depender de herramientas que capturan fotogramas seleccionados o describen estados concretos.

Un desarrollador humano percibe a la vez el movimiento, el ritmo, el equilibrio y la jerarquía visual. Puede mover la cámara, probar un control inesperado y notar que algo no funciona bien. Estas observaciones ocurren antes de convertirse en instrucciones verbales.

Un LLM suele recibir una representación más limitada. Puede inspeccionar una captura de pantalla, un registro de consola o un grafo de escena textual. Cada formato omite parte de la información disponible para quien revisa como humano.

Una captura de pantalla congela el tiempo. Un registro recoge eventos programados, pero no la apariencia. Un grafo de escena describe objetos, pero no si la composición comunica el significado previsto.

El vídeo puede preservar el movimiento, pero revisarlo introduce otro desafío. El modelo debe identificar momentos importantes entre muchos fotogramas y relacionarlos con el estado del programa. Las grabaciones largas también consumen un contexto y una capacidad de cómputo considerables.

Esto genera una asimetría. Producir otras mil líneas de código puede ser barato y rápido. Probar cuidadosamente el resultado en muchos estados puede requerir renderizado, percepción, razonamiento y revisión repetidos.

Por tanto, el sistema puede ampliar la complejidad más rápido que la confianza. Cada interacción generada añade otra ruta que podría contener un defecto oculto. Más producción aumenta la necesidad de una mejor evaluación.

Este problema se parece a la transición del autocompletado a los agentes de programación. El autocompletado propone un cambio pequeño que un desarrollador ve de inmediato. Un agente puede modificar muchos archivos y ejecutar comandos antes de que una persona inspeccione el resultado.

La generación interactiva amplifica ese patrón. Un modelo puede construir una escena completa antes de que alguien verifique la cámara, la física, los controles, la precisión narrativa o la accesibilidad. La aparente exhaustividad del resultado puede desalentar una revisión cuidadosa.

El término «percepción nativa» requiere cautela en este caso. Los modelos multimodales modernos pueden procesar imágenes, vídeo, audio y texto. La brecha se refiere a la fiabilidad con la que la percepción se integra en un ciclo de producción autónomo.

Un modelo no necesita conciencia humana para auditar software. Necesita acceso fiable a las pruebas relevantes, criterios de evaluación adecuados y la capacidad de revisar sin introducir nuevos fallos.

Estos requisitos siguen siendo difíciles porque muchos juicios creativos son subjetivos. Puede no haber un único ángulo de cámara o velocidad de animación correctos. Sin embargo, otros problemas son lo bastante objetivos como para someterlos a pruebas.

Los objetos no deberían atravesarse de forma inesperada. Los controles deberían activar la acción documentada. Deberían aparecer los personajes requeridos. Una secuencia solicitada debería ocurrir en el orden correcto.

Un sistema de auditoría útil debe separar esas comprobaciones mecánicas de las preferencias estéticas. Puede probar automáticamente las colisiones y la finalización de eventos, mientras pide a una persona que juzgue el tono y la composición.

Es probable que el sistema futuro combine varios evaluadores. El análisis estático puede inspeccionar el código. Las pruebas automatizadas pueden ejercitar las interacciones. Los modelos de visión pueden revisar fotogramas, mientras que los humanos resuelven decisiones creativas ambiguas.

Hasta que esa pila se vuelva fiable, los mundos generados seguirán estando más cerca de prototipos ambiciosos que de productos terminados. Su valor es real, pero su corrección no puede inferirse de su escala.

La demostración aún no es un referente general de construcción de mundos

Una escena generada impresionante no demuestra que un modelo comprenda el espacio físico, la intención narrativa o sus propios errores.

El ejemplo público crea varias lagunas de verificación. Los observadores no disponen de un registro completo del proceso de prompting. Tampoco pueden determinar cuánta selección se produjo antes de que apareciera el resultado mostrado.

Una demostración sólida podría provenir de una sola solicitud, de muchos reintentos o de una amplia orientación humana. Cada flujo de trabajo revelaría una capacidad diferente. Sin ese contexto, sería prematuro extraer conclusiones firmes sobre la autonomía.

El material de origen también parece estar conectado con un universo ficticio conocido. Las historias populares cuentan con abundante texto, imágenes, comentarios y material de fans en internet. Esa exposición durante el entrenamiento puede ayudar a un modelo a inferir los personajes y escenarios esperados.

Una prueba más sólida utilizaría material de origen desconocido. Los evaluadores podrían proporcionar una escena nueva que no aparezca en el corpus de entrenamiento. Entonces, el modelo tendría que fundamentar su mundo en la descripción suministrada.

La prueba también debería conservar el historial completo de interacción. Los investigadores necesitan los prompts, las llamadas a herramientas, los archivos generados, las correcciones y los intentos fallidos. Un vídeo breve no puede revelar cómo se alcanzó el resultado.

La última discusión de Andrej Karpathy sobre LLMs incluye tanto entusiasmo como críticas por este motivo. Sus defensores ven un lienzo más amplio para la creación personalizada. Sus críticos ven una demostración visualmente atractiva que carece de una evaluación controlada.

Ambas reacciones señalan algo importante. El resultado puede ser útil sin demostrar inteligencia general. Un prototipo puede ahorrar tiempo incluso cuando requiere revisión humana.

Llamar al sistema un «constructor de mundos» también corre el riesgo de difuminar distinciones técnicas. Una escena de navegador generada mediante JavaScript no equivale a un simulador aprendido. Sigue las reglas codificadas en su programa.

Esas reglas pueden aproximar un comportamiento físico sin representar comprensión física. Un objeto que cae podría moverse según una ecuación simple. Eso no significa que el modelo pueda predecir todas las consecuencias del sistema simulado.

A la inversa, escribir código gráfico coherente sí exige una competencia significativa. El modelo debe trasladar el lenguaje a coordenadas, objetos y transformaciones. Descartar el resultado como mero autocompletado ignora el trabajo de integración que implica.

La interpretación correcta se sitúa entre esos extremos. La generación de mundos con LLMs muestra una síntesis de software más amplia. Aún no demuestra una autoverificación visual completa.

Los equipos que consideren este flujo de trabajo deberían evaluar todo el ciclo. Deberían medir con qué frecuencia funciona el primer resultado, cuántas revisiones son necesarias y qué defectos eluden las comprobaciones automatizadas.

También deberían probar la variación. Un modelo que tiene éxito con una escena icónica podría fallar cuando cambian los personajes, las posiciones de cámara o las restricciones. Los sistemas fiables deben resistir solicitudes que queden fuera de los ejemplos populares compartidos en internet.

La seguridad genera otra preocupación. El software interactivo generado puede incluir dependencias, permisos de navegador, llamadas de red o código inseguro. El éxito visual no dice nada sobre si esos componentes son apropiados.

El rendimiento también importa. Una escena puede ejecutarse con fluidez en el ordenador del creador y fallar en hardware móvil. La geometría, las texturas y los bucles de animación generados pueden consumir memoria o tiempo de procesamiento sin advertencias evidentes.

La accesibilidad es fácil de pasar por alto. La navegación por teclado, las etiquetas legibles, los controles de movimiento y las descripciones alternativas rara vez aparecen automáticamente en demostraciones llamativas. Estas cualidades requieren especificaciones y pruebas explícitas.

Las cuestiones de derechos de autor e identidad también siguen sin resolverse. Un usuario puede solicitar mundos basados en personajes protegidos, personas reconocibles o juegos existentes. La capacidad técnica de generarlos no resuelve las cuestiones de derechos o distribución.

Estas debilidades no invalidan la observación de Karpathy. Definen el trabajo necesario para convertir esa observación en una categoría de producto fiable.

Un referente creíble debería usar prompts ocultos, referencias desconocidas y puntuación reproducible. Debería evaluar la consistencia espacial, la finalización de interacciones, la precisión visual, el rendimiento, la seguridad y la recuperación ante errores detectados.

Lo más importante es que debería probar la autocorrección. El modelo debería recibir acceso al mundo en ejecución, identificar un defecto introducido deliberadamente, localizar su causa y repararlo sin una orientación humana detallada.

Eso mediría más que la producción. Revelaría si la generación y la percepción se están convirtiendo en un ciclo fiable.

Qué debería ocurrir después del momento de los LLMs en Techmeme

Tres señales mostrarán si los mundos bajo demanda se están convirtiendo en herramientas fiables o si siguen siendo demostraciones impresionantes.

La primera señal es la llegada de evaluaciones reproducibles de construcción de mundos. Estas pruebas deberían publicar los prompts, los entornos, las reglas de puntuación y los rastros completos de los agentes. Los casos de prueba ocultos reducirían la posibilidad de que los modelos se optimicen para ejemplos virales conocidos.

Una evaluación útil mediría tanto la creación como el rendimiento de auditoría. El modelo podría construir una escena a partir de una descripción desconocida y luego inspeccionarla desde múltiples posiciones de cámara. Los evaluadores podrían introducir defectos y medir si el sistema los detecta.

Si esos referentes muestran mejoras consistentes en tareas no relacionadas, la tesis de Karpathy se fortalecerá. El campo podría demostrar que los modelos están aprendiendo habilidades espaciales e interactivas transferibles. El éxito en publicaciones aisladas de redes sociales importaría menos.

El fracaso debilitaría la afirmación. Si el rendimiento se desploma fuera de historias reconocibles o bibliotecas gráficas preferidas, la aparente transición podría reflejar una fluidez especializada en programación. Aún no representaría la creación general de mundos bajo demanda.

La segunda señal es una percepción más estrecha dentro de los agentes de programación. Los desarrolladores deberían prestar atención a agentes que inicien automáticamente aplicaciones generadas, recorran interfaces, graben fotogramas, inspeccionen el movimiento y relacionen errores visibles con el código fuente.

El soporte para capturas de pantalla por sí solo no bastará. El agente necesita memoria temporal y exploración sistemática. Debe saber qué estados ha probado y cuáles siguen sin cubrir.

El sistema también debería conservar pruebas. Quien revise necesita registros que muestren qué observó el agente, qué criterios aplicó y por qué consideró completo el resultado. Este registro puede acelerar la revisión sin pedir a los usuarios que confíen en un resumen.

Si los principales agentes introducen pruebas fiables de regresión visual, la brecha de auditoría se reducirá. Las pruebas de regresión visual comparan el resultado renderizado entre versiones para identificar cambios no intencionados. Los agentes pueden ampliar ese método explicando la causa probable.

Si el progreso sigue limitado a generar código más elaborado, la brecha se ampliará. Los usuarios recibirán artefactos mayores con más estados ocultos y ningún aumento proporcional de confianza.

La tercera señal es la convergencia entre escenas codificadas y modelos de mundo aprendidos. El trabajo de Google DeepMind demuestra la generación directa de entornos en tiempo real. La programación basada en LLMs proporciona estructura editable y acceso a herramientas de software consolidadas.

Un sistema combinado podría usar código para las reglas, las interfaces y el estado persistente. Un modelo de mundo podría aportar detalle visual, variación y comportamiento simulado. Un agente de auditoría podría comparar ambos resultados con la solicitud original.

Esa convergencia respaldaría aplicaciones más allá del entretenimiento. Las simulaciones de formación podrían adaptarse a un alumno. Los equipos de producto podrían generar escenarios de uso realistas. Los robots podrían practicar en entornos variados antes de entrar en espacios físicos.

También aumentaría el coste de los errores. Una simulación defectuosa puede enseñar a un agente el comportamiento equivocado. Una lección personalizada puede presentar relaciones falsas con detalles visuales persuasivos.

Por esa razón, la procedencia debe acompañar a la personalización. Los usuarios deberían poder rastrear qué material de origen dio forma a un mundo generado. También deberían saber qué componentes fueron inferidos en lugar de recuperados.

Las herramientas de combinación de conocimientos pueden ayudar a mantener las explicaciones generadas vinculadas al contexto de origen. No sustituyen la validación, pero pueden reducir la distancia entre una experiencia y el material que la respalda.

Los ganadores a corto plazo no necesariamente generarán la demostración más espectacular. Cerrarán el ciclo entre la solicitud, la creación, la observación, las pruebas y la corrección.

Ese ciclo también necesita reglas de detención sensatas. Un agente que modifica repetidamente una escena que ya funciona puede introducir regresiones mientras persigue pequeñas mejoras visuales. Debe distinguir entre un defecto bloqueante y una preferencia estética.

La revisión humana seguirá siendo importante, especialmente para el significado y el criterio estético. El objetivo no es eliminar al revisor. Es garantizar que el modelo detecte fallos evidentes antes de solicitar aprobación.

Por tanto, la tesis más amplia de Andrej Karpathy sobre los LLMs es menos celebratoria de lo que parece a primera vista. La generación se ha expandido de los artefactos a los sistemas, pero la evaluación no se ha expandido al mismo ritmo.

Ese desequilibrio dará forma al diseño de productos durante los próximos meses. Más empresas promocionarán aplicaciones instantáneas, juegos, simulaciones e historias interactivas. Su característica decisiva debería ser la evidencia de que esas experiencias fueron realmente inspeccionadas.

El momento de techmeme llms ofrece a los desarrolladores una prueba útil para cada nueva demostración: ¿qué creó el modelo y qué evidencia muestra que comprendió el resultado?

Prueba la misma pregunta en tu propio proyecto generado con IA. Pide al agente que enumere los estados que inspeccionó, los defectos que encontró y la evidencia que respalda la finalización. Luego prueba una ruta que nunca mencionó. Si el proyecto falla ahí, la característica que falta no es otro modelo de generación. Es un ciclo de auditoría creíble.