Andrej Karpathy estime que Techmeme LLMs annonce une nouvelle ère de création, mais le déficit d’audit persiste

Selon Andrej Karpathy, les LLMs ont franchi un seuil remarquable, malgré une faiblesse fondamentale persistante : ils ne savent toujours pas inspecter de manière fiable ce qu’ils construisent. La dernière discussion autour de techmeme llms porte sur des systèmes capables de créer, à partir de brèves instructions, des mondes interactifs personnalisés. Pourtant, ces systèmes dépendent souvent encore des humains pour repérer une physique défaillante, des objets mal placés, des anomalies visuelles et des interactions manquantes.

Karpathy a présenté cette évolution en la comparant à un ancien test de modèles. Demander à un LLM de produire un SVG d’un pélican à vélo permettait autrefois d’évaluer sa compréhension du code, de la géométrie et des relations entre objets. Le nouveau défi est bien plus vaste. Un modèle peut désormais générer le logiciel qui sous-tend une scène explorable, avec animation, caméras, éclairage et comportements simulés.

Cette ampleur change la définition de la réussite. Produire des milliers de lignes de code plausibles ne revient pas à produire un monde cohérent. L’enjeu central oppose désormais la génération à la vérification. Les modèles peuvent étendre l’artefact plus vite qu’ils ne peuvent percevoir, tester et réparer l’expérience obtenue.

Techmeme LLMs dépasse le test du pélican

La publication de Karpathy marque le passage de l’évaluation de sorties isolées à celle d’expériences complètes.

Dans son post original, Karpathy a déclaré que le domaine quittait le terrain des tests consistant, par exemple, à créer un SVG de pélican à vélo. Il a décrit les LLMs comme se dirigeant vers des mondes hyperpersonnalisés, générés à la demande.

Le post a circulé dans une discussion Techmeme le 2 août 2026. Le contenu associé montrait une interprétation animée et tridimensionnelle d’une scène fictive. Il semblait combiner du code généré, des personnages, des éléments de décor, des mouvements et des comportements de caméra.

Les éléments publics ne permettent pas d’établir un benchmark contrôlé. Ils ne révèlent ni l’ensemble des prompts, ni les interventions, tentatives supplémentaires ou corrections manuelles impliquées. La démonstration doit donc être considérée comme la preuve d’un flux de travail possible, et non comme la démonstration d’une création de mondes autonome.

Même avec cette réserve, le changement est significatif. Un SVG est un artefact borné, dont la surface de complexité est relativement limitée. Un monde fonctionnant dans un navigateur contient de nombreux systèmes en interaction, chacun susceptible d’échouer séparément.

Le modèle doit choisir les positions, les échelles, les couleurs, les matériaux et les trajectoires de mouvement des objets. Il doit gérer le code de rendu, le timing, le placement de la caméra, l’état des animations et les commandes utilisateur. Il doit également transformer une prose ambiguë en décisions visuelles concrètes.

C’est précisément pourquoi le test du pélican est devenu utile. Un vélo possède des relations mécaniques reconnaissables. Un modèle peut produire quelque chose qui ressemble à un vélo tout en reliant incorrectement le cadre, la chaîne, les pédales et la direction.

Les logiciels peuvent masquer le même problème derrière un spectacle plus impressionnant. Une scène générée peut sembler convaincante dans un court enregistrement tout en échouant sous un autre angle de caméra. Un objet peut flotter, disparaître, traverser un mur ou changer de taille lorsque l’utilisateur se déplace.

Ces défaillances sont plus difficiles à résumer qu’un dessin mal formé. Elles émergent d’interactions dans le temps, et non d’une image statique. Un évaluateur doit explorer le monde, se souvenir d’états antérieurs et comprendre quels résultats contreviennent à la conception prévue.

La collection de pélicans évolutive de Simon Willison illustre pourquoi les tests visuels ont attiré l’attention. Différents modèles pouvaient écrire du code SVG valide tout en produisant des interprétations visiblement différentes d’une même demande. Le résultat révélait des lacunes souvent ignorées par les benchmarks de codage ordinaires.

Toutefois, la réussite peut saturer un benchmark. Une fois que les modèles reproduisent des schémas de test familiers, le prompt cesse de distinguer une compétence générale d’un entraînement ciblé ou de conventions mémorisées. Un environnement plus vaste et moins prévisible laisse davantage de place à l’apparition d’erreurs révélatrices.

Le dernier débat autour de techmeme llms ne porte donc pas principalement sur la question de savoir si le monde affiché mérite des éloges artistiques. Il concerne la possibilité que l’unité de création par IA se soit élargie. Les éléments disponibles suggèrent que c’est le cas.

Un utilisateur n’a plus besoin de demander uniquement une image, un paragraphe, un composant ou un script. La demande peut décrire une expérience temporaire adaptée à une personne. Le modèle peut assembler cette expérience à partir de code pendant que l’utilisateur attend.

Cela diffère du développement de jeux vidéo conventionnel. Un studio crée un produit commun destiné à un large public et le teste avant sa sortie. La génération à la demande traite au contraire le logiciel comme quelque chose de temporaire, de personnel et peu coûteux à demander.

Un enseignant pourrait demander une représentation interactive d’un contexte historique. Un enfant pourrait demander un petit monde inspiré d’une histoire du soir. Une équipe produit pourrait transformer un scénario écrit en prototype navigable avant de s’engager dans la production.

Ces résultats n’ont pas besoin d’un réalisme cinématographique pour être importants. Des mondes générés de faible fidélité peuvent malgré tout communiquer des relations spatiales, des idées d’interaction et des séquences narratives. Leur valeur peut venir de leur spécificité et de leur rapidité plutôt que de leur finition.

La démonstration déplace donc la question. Il ne s’agit plus simplement de demander : « Un LLM peut-il dessiner l’objet demandé ? » La question plus difficile devient : « Peut-il maintenir un système cohérent pendant que ce système est exploré ? »

Les mondes à la demande mettent les logiciels créatifs sous pression

La pression immédiate s’exerce sur les outils qui supposent que toute expérience interactive exige un long processus de production manuel.

Les logiciels créatifs traditionnels séparent l’écriture, l’illustration, la modélisation, l’animation, la programmation et les tests. Les spécialistes font passer le travail par ces étapes à l’aide de fichiers, d’éditeurs et de processus de revue. Les systèmes génératifs compressent plusieurs étapes dans une seule interface conversationnelle.

Cette compression modifie l’économie des prototypes. Un concept qui restait autrefois dans un document peut devenir une scène fonctionnelle. Les équipes peuvent évaluer le rythme, l’échelle et l’interaction avant d’investir dans des ressources finalisées.

Le cas d’usage le plus solide à court terme n’est pas le remplacement d’un jeu commercial complet. Il s’agit de générer des simulations jetables, des explications visuelles, des ébauches narratives et des expérimentations d’interface. Ces résultats n’ont besoin de survivre que suffisamment longtemps pour répondre à une question ciblée.

Un concepteur de jeux pourrait tester si une mécanique semble compréhensible. Un cinéaste pourrait examiner un découpage sommaire pour une scène. Un enseignant pourrait créer une leçon explorable adaptée aux centres d’intérêt d’un élève.

Les travailleurs du savoir pourraient également transformer des notes en représentations interactives. Une base de connaissances IA personnelle peut conserver les documents sources derrière de telles demandes. Ce contexte devient important lorsqu’une expérience générée doit être traçable.

L’opportunité la plus large est la personnalisation. Les médias conventionnels proposent généralement le même artefact à chaque spectateur. Les logiciels génératifs peuvent faire varier les personnages, la complexité, le rythme, la langue ou le sujet à chaque session.

Un monde personnalisé peut répondre à des informations fournies quelques instants auparavant. Il peut intégrer le projet d’un utilisateur, des personnages fictifs, des objectifs d’apprentissage ou un style visuel privilégié. Le résultat se rapproche alors davantage d’une application générée que d’un contenu multimédia statique.

Google DeepMind poursuit une direction connexe avec les modèles du monde, qui simulent l’évolution des environnements après des actions. Ses recherches sur Genie 3 décrivent des mondes navigables générés à partir de texte en 720p et à 24 images par seconde.

DeepMind a indiqué que ces environnements pouvaient rester cohérents pendant plusieurs minutes. L’entreprise a également reconnu des espaces d’action limités, des difficultés à modéliser plusieurs agents indépendants et une précision géographique imparfaite. Ces limites montrent pourquoi une vidéo impressionnante ne suffit pas à elle seule.

L’exemple de Karpathy représente une voie technique différente. Un LLM peut écrire du code graphique conventionnel exécuté par un navigateur. Un modèle du monde spécialisé génère plus directement les futurs états visuels, à partir des images précédentes et des actions de l’utilisateur.

Les deux approches visent des environnements réactifs, mais elles exposent des modes de défaillance différents. Le code généré offre une structure de programme inspectable et une exécution déterministe. Il peut néanmoins contenir des hypothèses erronées sur la géométrie, la physique ou le sens narratif.

Un modèle du monde peut produire des images plus naturelles sans construire explicitement chaque objet. Son état interne peut être plus difficile à inspecter pour les développeurs. La cohérence peut aussi se dégrader lorsque l’interaction dépasse la mémoire effective du modèle.

Ces approches pourraient finir par converger. Un agent pourrait écrire la logique d’une scène, appeler des modèles de médias génératifs, observer le rendu et réviser les deux. Le système final combinerait structure symbolique et génération visuelle.

Cette perspective met sous pression les moteurs de jeu établis, les outils de conception et les suites créatives afin qu’ils deviennent plus faciles à utiliser pour les agents. Leurs interfaces ont été conçues pour des humains capables de voir le canevas et de comprendre des retours visuels subtils.

Un LLM opérant par le texte ne reçoit pas automatiquement cette même expérience. Il peut connaître chaque objet présent dans le code source tout en ignorant l’apparence de la scène finale. Les éditeurs d’outils doivent exposer des captures d’écran, des graphes de scène, des commandes de test et des diagnostics structurés.

Les agents de codage montrent déjà la rapidité avec laquelle cette transition peut se produire. Anthropic a étudié environ 400 000 sessions Claude Code menées entre octobre 2025 et avril 2026. Son étude sur les agents de codage a constaté que les mesures de vérification dépendaient encore en partie d’une confirmation explicite dans les conversations.

Ce détail importe au-delà du développement logiciel. Si la réussite dépend du fait que le modèle déclare une tâche terminée, le résultat peut sembler plus fiable qu’il ne l’est réellement. Les mondes interactifs rendent ce problème de mesure visible.

Une application générée peut compiler et se lancer tout en échouant à remplir son objectif. Les commandes peuvent être peu pratiques. La scène peut déformer la source. L’interaction la plus importante peut ne jamais fonctionner.

Les outils créatifs sont donc sous pression pour fournir des retours que les agents peuvent réellement exploiter. Une intégration réussie doit aider le modèle à inspecter le comportement, et pas seulement à produire davantage de code.

La génération a dépassé la perception native

Le compromis central est simple : les modèles peuvent créer un espace d’états plus vaste qu’ils ne peuvent explorer et auditer de manière fiable.

Un espace d’états est l’ensemble des conditions dans lesquelles un système peut se trouver après différentes actions. Même un petit monde interactif peut contenir de nombreuses positions, vues de caméra, états d’objets et combinaisons d’événements. Tester tous les parcours devient rapidement impraticable.

Les LLMs générateurs de code fonctionnent bien lorsque le retour arrive sous forme de texte. Un compilateur peut identifier une erreur de syntaxe et indiquer une ligne. Un test peut renvoyer un résultat clair de réussite ou d’échec.

La qualité visuelle fournit rarement un retour aussi net. Le programme peut s’exécuter correctement tout en présentant une scène impossible ou déroutante. Aucune exception n’apparaît lorsque les pieds d’un personnage glissent sur le sol.

Le modèle a besoin de perception pour détecter ce type de problème. Il doit capturer le rendu, reconnaître les objets, les comparer à l’instruction et décider si leurs relations ont du sens. Il doit ensuite relier un défaut visible au bon code.

Les systèmes multimodaux actuels peuvent accomplir certaines parties de cette boucle. Ils peuvent interpréter des captures d’écran et raisonner sur de nombreux éléments visuels. Ils peuvent également réviser du code après avoir reçu la description d’un défaut par un utilisateur.

Cependant, ces capacités ne garantissent pas une auto-évaluation fiable. Le même modèle qui a produit une mise en page erronée peut répéter son hypothèse en examinant la capture d’écran. Il peut négliger des erreurs subtiles ou les rationaliser comme des choix de conception intentionnels.

Les recherches sur l’auto-feedback multimodal montrent à la fois l’opportunité et la limite. La recherche Volcano a révélé que le retour visuel pouvait réduire les hallucinations en aidant un modèle à réviser une réponse initiale. Cela nécessitait un processus de feedback conçu à cet effet, plutôt que la seule génération.

Cette distinction est au cœur de l’argument de Karpathy. Le modèle peut produire les éléments d’un monde sans posséder une expérience continue et native de ce monde. Son accès dépend souvent d’outils qui capturent des images sélectionnées ou décrivent des états sélectionnés.

Un développeur humain perçoit simultanément le mouvement, le rythme, l’équilibre et la hiérarchie visuelle. Il peut déplacer la caméra, essayer une commande inattendue et remarquer que quelque chose ne va pas. Ces observations surviennent avant de devenir des instructions verbales.

Un LLM reçoit généralement une représentation plus limitée. Il peut examiner une seule capture d’écran, un journal de console ou un graphe de scène textuel. Chaque format omet une partie des informations accessibles au relecteur humain.

Une capture d’écran fige le temps. Un journal enregistre les événements programmés, mais pas leur apparence. Un graphe de scène décrit des objets sans indiquer si la composition transmet le sens voulu.

La vidéo peut préserver le mouvement, mais son examen introduit un autre défi. Le modèle doit identifier les moments importants parmi de nombreuses images et les relier à l’état du programme. Les enregistrements longs consomment également beaucoup de contexte et de calcul.

Cela crée une asymétrie. Générer mille lignes de code supplémentaires peut être rapide et peu coûteux. Tester soigneusement le résultat dans de nombreux états peut exiger des cycles répétés de rendu, de perception, de raisonnement et de révision.

Le système peut donc accroître la complexité plus vite que la confiance. Chaque interaction générée ajoute un chemin susceptible de contenir un défaut caché. Davantage de production augmente le besoin d’une meilleure évaluation.

Ce problème rappelle le passage de l’autocomplétion aux agents de programmation. L’autocomplétion propose une petite modification qu’un développeur voit immédiatement. Un agent peut modifier de nombreux fichiers et exécuter des commandes avant que l’humain n’examine le résultat.

La génération interactive amplifie ce schéma. Un modèle peut construire une scène complète avant que quiconque ne vérifie la caméra, la physique, les contrôles, la fidélité narrative ou l’accessibilité. L’apparente complétude de la production peut décourager une relecture attentive.

L’expression « perception native » doit être employée avec prudence ici. Les modèles multimodaux modernes peuvent traiter des images, des vidéos, de l’audio et du texte. L’écart concerne la fiabilité avec laquelle la perception est intégrée à une boucle de production autonome.

Un modèle n’a pas besoin d’une conscience humaine pour auditer un logiciel. Il a besoin d’un accès fiable aux éléments de preuve pertinents, de critères d’évaluation adaptés et de la capacité à réviser sans introduire de nouvelles défaillances.

Ces exigences restent difficiles, car de nombreux jugements créatifs sont subjectifs. Il n’existe peut-être pas un seul angle de caméra ou une seule vitesse d’animation corrects. D’autres problèmes sont toutefois suffisamment objectifs pour être testés.

Les objets ne devraient pas se traverser de manière inattendue. Les contrôles devraient déclencher l’action documentée. Les personnages requis devraient apparaître. Une séquence demandée devrait se dérouler dans le bon ordre.

Un système d’audit utile doit séparer ces vérifications mécaniques des préférences esthétiques. Il peut tester automatiquement les collisions et la réalisation des événements, tout en demandant à un humain d’évaluer le ton et la composition.

Le système futur combinera probablement plusieurs évaluateurs. L’analyse statique peut examiner le code. Les tests automatisés peuvent exercer les interactions. Les modèles de vision peuvent examiner les images, tandis que les humains tranchent les choix créatifs ambigus.

Tant que cet ensemble ne sera pas fiable, les mondes générés resteront plus proches de prototypes ambitieux que de produits finis. Leur valeur est réelle, mais leur exactitude ne peut être déduite de leur ampleur.

La démonstration n’est pas encore un benchmark général de création de mondes

Une scène générée impressionnante ne prouve pas qu’un modèle comprend l’espace physique, l’intention narrative ou ses propres erreurs.

L’exemple public crée plusieurs lacunes de vérification. Les observateurs ne disposent pas d’un historique complet du processus de prompting. Ils ne peuvent pas non plus déterminer dans quelle mesure une sélection a eu lieu avant l’apparition du résultat présenté.

Une démonstration convaincante peut provenir d’une seule demande, de nombreuses tentatives ou d’un accompagnement humain important. Chaque flux de travail révélerait une capacité différente. Sans ce contexte, tirer des conclusions fermes sur l’autonomie serait prématuré.

Le matériau source semble également lié à un univers fictionnel familier. Les histoires célèbres disposent d’une abondante documentation textuelle, visuelle, critique et créée par les fans en ligne. Cette exposition dans l’entraînement peut aider un modèle à déduire les personnages et décors attendus.

Un test plus solide utiliserait un matériau source inconnu. Les évaluateurs pourraient fournir une nouvelle scène qui n’apparaît pas dans le corpus d’entraînement. Le modèle devrait alors ancrer son monde dans la description fournie.

Le test devrait aussi préserver l’historique complet des interactions. Les chercheurs ont besoin des prompts, appels d’outils, fichiers générés, corrections et tentatives échouées. Une courte vidéo ne peut pas révéler comment le résultat a été obtenu.

La récente discussion d’Andrej Karpathy sur les LLMs suscite à la fois enthousiasme et critiques pour cette raison. Les partisans y voient une toile plus vaste pour une création personnalisée. Les critiques y voient une démonstration visuellement séduisante dépourvue d’évaluation contrôlée.

Ces deux réactions soulignent quelque chose d’important. La production peut être utile sans prouver une intelligence générale. Un prototype peut faire gagner du temps même s’il exige une relecture humaine.

Qualifier le système de « constructeur de mondes » risque également de brouiller des distinctions techniques. Une scène de navigateur générée via JavaScript n’est pas équivalente à un simulateur appris. Elle suit les règles encodées dans son programme.

Ces règles peuvent approximativement reproduire un comportement physique sans représenter une compréhension physique. Un objet en chute peut se déplacer selon une équation simple. Cela ne signifie pas que le modèle peut prédire toutes les conséquences du système simulé.

À l’inverse, écrire du code graphique cohérent exige une compétence réelle. Le modèle doit transposer le langage en coordonnées, objets et transformations. Réduire le résultat à de la simple autocomplétion ignore le travail d’intégration impliqué.

L’interprétation juste se situe entre ces deux extrêmes. La génération de mondes par les LLMs montre une synthèse logicielle plus large. Elle ne démontre pas encore une auto-vérification visuelle complète.

Les équipes qui envisagent ce flux de travail devraient évaluer l’ensemble de la boucle. Elles devraient mesurer la fréquence à laquelle le premier résultat fonctionne, le nombre de révisions nécessaires et les défauts qui échappent aux vérifications automatisées.

Elles devraient également tester la variation. Un modèle qui réussit sur une scène emblématique peut échouer lorsque les personnages, positions de caméra ou contraintes changent. Les systèmes fiables doivent résister à des demandes qui sortent des exemples populaires partagés en ligne.

La sécurité soulève une autre préoccupation. Les logiciels interactifs générés peuvent inclure des dépendances, des autorisations de navigateur, des appels réseau ou du code dangereux. La réussite visuelle ne dit rien sur le caractère approprié de ces composants.

Les performances comptent également. Une scène peut fonctionner sans accroc sur l’ordinateur de son créateur tout en échouant sur du matériel mobile. La géométrie, les textures et les boucles d’animation générées peuvent consommer de la mémoire ou du temps de calcul sans avertissement évident.

L’accessibilité est facile à négliger. La navigation au clavier, les libellés lisibles, les contrôles de mouvement et les descriptions alternatives apparaissent rarement automatiquement dans les démonstrations spectaculaires. Ces qualités exigent des spécifications et des tests explicites.

Les questions de droit d’auteur et d’identité restent également non résolues. Un utilisateur peut demander des mondes fondés sur des personnages protégés, des personnes reconnaissables ou des jeux existants. La capacité technique à les générer ne résout pas les questions de droits ou de distribution.

Ces faiblesses n’invalident pas l’observation de Karpathy. Elles définissent le travail nécessaire pour transformer cette observation en une catégorie de produits fiable.

Un benchmark crédible devrait utiliser des prompts cachés, des références inconnues et une notation reproductible. Il devrait évaluer la cohérence spatiale, l’exécution des interactions, l’exactitude visuelle, les performances, la sécurité et la récupération après détection d’erreurs.

Plus important encore, il devrait tester l’autocorrection. Le modèle devrait recevoir un accès au monde en cours d’exécution, identifier un défaut introduit délibérément, en localiser la cause et le corriger sans guidage humain détaillé.

Cela mesurerait davantage que la seule production. Cela révélerait si la génération et la perception deviennent une boucle fiable unique.

Ce qui devrait se passer après le moment Techmeme des LLMs

Trois signaux montreront si les mondes à la demande deviennent des outils fiables ou restent des démonstrations impressionnantes.

Le premier signal est l’arrivée d’évaluations reproductibles de création de mondes. Ces tests devraient publier les prompts, les environnements, les règles de notation et les traces complètes des agents. Des cas de test cachés réduiraient la probabilité que les modèles s’optimisent pour des exemples viraux déjà connus.

Une évaluation utile noterait à la fois les performances de création et d’audit. Le modèle pourrait construire une scène à partir d’une description inconnue, puis l’examiner depuis plusieurs positions de caméra. Les évaluateurs pourraient introduire des défauts et mesurer si le système les détecte.

Si de tels benchmarks montrent des progrès constants sur des tâches sans lien entre elles, la thèse de Karpathy se renforcera. Le domaine pourrait démontrer que les modèles apprennent des compétences spatiales et interactives transférables. Les réussites sur des publications sociales isolées importeraient moins.

Un échec affaiblirait cette affirmation. Si les performances s’effondrent en dehors d’histoires reconnaissables ou de bibliothèques graphiques privilégiées, la transition apparente pourrait refléter une aisance spécialisée en programmation. Elle ne représenterait pas encore une création générale de mondes à la demande.

Le deuxième signal est une perception plus étroitement intégrée aux agents de programmation. Les développeurs devraient surveiller l’apparition d’agents qui lancent automatiquement des applications générées, parcourent les interfaces, enregistrent des images, inspectent les mouvements et relient les erreurs visibles au code source.

La prise en charge des captures d’écran seule ne suffira pas. L’agent a besoin d’une mémoire temporelle et d’une exploration systématique. Il doit savoir quels états il a testés et lesquels restent non couverts.

Le système devrait également préserver les éléments de preuve. Un relecteur a besoin de journaux indiquant ce que l’agent a observé, quels critères il a appliqués et pourquoi il a jugé le résultat complet. Cet historique peut accélérer la relecture sans demander aux utilisateurs de faire confiance à un résumé.

Si les principaux agents introduisent des tests fiables de régression visuelle, le fossé d’audit se réduira. Les tests de régression visuelle comparent le rendu entre versions afin d’identifier les changements non intentionnels. Les agents peuvent étendre cette méthode en expliquant la cause probable.

Si les progrès se limitent à générer du code plus élaboré, le fossé se creusera. Les utilisateurs recevront des artefacts plus volumineux, avec davantage d’états cachés et sans augmentation proportionnelle de la confiance.

Le troisième signal est la convergence entre les scènes codées et les modèles de monde appris. Les travaux de Google DeepMind démontrent la génération directe et en temps réel d’environnements. La programmation fondée sur les LLMs apporte une structure modifiable et l’accès à des outils logiciels établis.

Un système combiné pourrait utiliser le code pour les règles, les interfaces et l’état persistant. Un modèle de monde pourrait fournir le détail visuel, la variation et le comportement simulé. Un agent d’audit pourrait comparer ces deux productions à la demande initiale.

Cette convergence soutiendrait des applications au-delà du divertissement. Les simulations de formation pourraient s’adapter à un apprenant. Les équipes produit pourraient générer des scénarios d’utilisation réalistes. Les robots pourraient s’entraîner dans des environnements variés avant d’entrer dans des espaces physiques.

Elle augmenterait aussi le coût des erreurs. Une simulation défaillante peut enseigner à un agent le mauvais comportement. Une leçon personnalisée peut présenter de fausses relations avec un niveau de détail visuel convaincant.

Pour cette raison, la provenance doit accompagner la personnalisation. Les utilisateurs doivent pouvoir retracer quels contenus sources ont façonné un univers généré. Ils doivent également savoir quels composants ont été inférés plutôt que récupérés.

Les outils de fusion des connaissances peuvent aider à maintenir les explications générées ancrées dans leur contexte source. Ils ne remplacent pas la validation, mais ils peuvent réduire l’écart entre une expérience et les contenus qui l’étayent.

Les gagnants à court terme ne seront pas nécessairement ceux qui produiront la démo la plus spectaculaire. Ce seront ceux qui boucleront la chaîne entre demande, création, observation, test et correction.

Cette boucle a également besoin de règles d’arrêt raisonnables. Un agent qui modifie à répétition une scène fonctionnelle peut introduire des régressions en cherchant à obtenir de modestes améliorations visuelles. Il doit faire la distinction entre un défaut bloquant et une préférence esthétique.

La revue humaine restera importante, en particulier pour le sens et le goût. L’objectif n’est pas d’éliminer le relecteur. Il consiste à garantir que le modèle détecte les échecs évidents avant de demander une approbation.

La thèse plus large d’Andrej Karpathy sur les LLM est donc moins triomphaliste qu’elle n’y paraît au premier abord. La génération s’est étendue des artefacts aux systèmes, mais l’évaluation n’a pas progressé au même rythme.

Ce déséquilibre façonnera la conception des produits au cours des prochains mois. Davantage d’entreprises commercialiseront des applications instantanées, des jeux, des simulations et des histoires interactives. Leur fonctionnalité décisive devrait être la preuve que ces expériences ont réellement été inspectées.

Le moment techmeme des LLM offre aux développeurs un test utile pour chaque nouvelle démonstration : qu’a créé le modèle, et quelles preuves montrent qu’il en a compris le résultat ?

Posez la même question à votre propre projet généré par IA. Demandez à l’agent de lister les états qu’il a inspectés, les défauts qu’il a trouvés et les éléments justifiant l’achèvement. Testez ensuite un parcours qu’il n’a jamais mentionné. Si le projet échoue à cet endroit, la fonctionnalité manquante n’est pas un autre modèle de génération. C’est une boucle d’audit crédible.