Fable 5.2 a écrit un path tracer et une scène de 370 000 polygones avec un seul prompt

En général, quand on parle d'agents, on pense à un modèle qui utilise des outils existants : il ouvre Blender, appelle une API, lance le script de quelqu'un d'autre. L'expérience décrite par la chaîne « Metaversichtche » casse ce schéma. Le modèle a reçu une tâche, s'est fabriqué ses propres outils et les a utilisés lui-même.

Ce qui s'est passé exactement

Le prompt tenait en une phrase en anglais. En substance : en utilisant toutes les techniques de programmation que tu connais, crée une image faite de l'entrelacement de la lumière et de l'ombre, montre le jeu paisible de la lumière et de l'ombre par une journée claire, vise la perfection. Pas un mot sur le rendu, le C++ ou la 3D. Le modèle Fable 5.2 (c'est ainsi que l'auteur du post l'appelle) a décidé de lui-même que le meilleur moyen d'obtenir une telle image était d'écrire un moteur de rendu.

Selon la description, le résultat est le suivant :

• un path tracer écrit de zéro en C++ ;
• un soleil en forme de vrai disque, et non de point ;
• environ 370 000 polygones entièrement générés par du code : parquet à point de Hongrie, plis des rideaux, chaque feuille d'érable derrière la fenêtre ;
• des matériaux procéduraux, dont un petit motif sur le mur ;
• un script Python qui retire le bruit, fait l'étalonnage des couleurs et ajoute du grain.

Ce que veut dire « soleil en forme de disque » se comprend le mieux sur un exemple. Dans les moteurs de rendu simplifiés, la source de lumière est un point, et son ombre est dure. Pour qu'elle paraisse douce, on la floute généralement avec un filtre. Si, en revanche, la source a une surface, comme le vrai soleil, le bord de l'ombre se brouille tout seul : net à la base de l'objet, puis de plus en plus doux en s'éloignant. C'est ce qu'on appelle la pénombre. Le modèle a choisi la voie physiquement fidèle, alors que le prompt ne le demandait pas.

Pourquoi c'est important pour les développeurs et les product managers

Premièrement : le passage du tool use au tool making. L'agent habituel choisit dans un ensemble de fonctions toutes faites. Ici, le modèle a écrit des outils pour une seule tâche, ils ont servi une fois, et c'est tout. Pour le développeur, cela change la question. Avant, il fallait décider comment intégrer une dizaine de SDK. Désormais, il suffit parfois de donner au modèle un bac à sable avec un compilateur et de décrire le résultat voulu.

Deuxièmement : ce n'est pas une image de diffusion, mais un programme qui la calcule. D'où un avantage logique, même si le post ne l'a pas vérifié : le résultat peut être reproduit et modifié. Envie d'un autre angle de soleil ou d'un autre érable ? On change un paramètre et on refait le rendu. Un générateur d'images n'offre généralement pas ce contrôle. Pour les produits autour de la 3D et de la visualisation, c'est un signal : la frontière entre « générateur » et « code » commence à s'effacer.

Troisièmement : un effet de bord sur l'infrastructure. L'auteur plaisante en disant que si l'on sauvegardait tous les outils jetables sur GitHub, la plateforme éclaterait, et affirme que le stockage y a été multiplié par 20 en un an. Le chiffre vient du post, nous ne l'avons pas vérifié. Mais l'idée est juste : quand le code devient un consommable, la question « que vaut-il la peine de conserver » devient réelle.

Limites

• C'est un seul post et un seul exemple. On ne sait pas combien d'itérations internes le modèle a faites, combien de tokens et d'argent ont été dépensés ni combien de temps le travail a pris. Les mots « juste un prompt » ne répondent pas à ces questions.
• Le path tracer est un classique de l'infographie, sur lequel il existe beaucoup de documentation. Pour des tâches de niche, avec moins d'exemples, ce tour de force peut ne pas fonctionner.
• Le critère de « perfection » est subjectif. Une belle scène ne prouve pas que la physique est correctement calculée partout.
• Un modèle qui écrit et exécute du code exige de l'isolation : bac à sable, limites de temps et de mémoire, interdiction des accès réseau superflus.

Que faire de tout cela

Essayez sur votre propre tâche. Donnez au modèle un environnement avec un compilateur ou un interpréteur et formulez un objectif, pas une recette. Voyez s'il se met à écrire des outils plutôt qu'à choisir des outils existants. Prévoyez l'isolation et les limites dès le départ. Et ouvrez le dépôt afternoon-light : on y voit à quoi ressemble le code que le modèle a écrit pour une seule image.