BrickWright apprend aux agents de code à assembler des LEGO : 100% de montages valides contre 9–69%

Le framework BrickWright pousse des agents de code prêts à l'emploi à construire en LEGO des modèles qu'on peut réellement assembler à la main. Sur un échantillon de 512 prompts, les agents pilotés par BrickWright ont produit 100% d'assemblages physiquement corrects. Les mêmes modèles sans le framework s'en sortaient nettement moins bien : GPT-6 Luna n'y parvenait que dans 9% des cas, et le meilleur des agents de base, GPT-6 Astra, plafonnait à 69%.

Pourquoi les agents construisent dans le vide

Les agents de code actuels maîtrisent bien la modélisation 3D, mais le monde physique ne leur fait aucun cadeau. Un objet virtuel peut être dessiné de façon à ce qu'une partie des pièces flotte sans support, qu'une autre traverse ses voisines et qu'une troisième forme un îlot isolé. À l'écran, cela passe parfois inaperçu ; dans une boîte de briques, c'est un rebut.

Les auteurs définissent la faisabilité physique de manière stricte. Un assemblage est valide s'il ne contient que des pièces réelles, sans éléments qui se chevauchent ni « flottants », et si l'ensemble de la construction forme une structure connexe, lorsque c'est possible en principe. Leur thèse : pour obtenir de tels assemblages, l'agent n'a pas besoin d'être réentraîné. Il suffit de lui fournir des outils qui construisent le modèle et en vérifient la physique.

BrickLayer : une API pratique et un validateur dans la boucle

BrickWright pilote l'agent par le code. Celui-ci écrit des programmes avec BrickLayer, un toolkit Python composé de deux parties principales.

La première est une API ergonomique pour assembler des briques. Elle divise par deux le coût d'inférence par rapport au format LDraw brut, dans lequel l'agent manipule à la main une description de bas niveau des pièces. Moins de tokens dépensés sur les tâches routinières, c'est un coût moindre à chaque tentative.

La seconde est un validateur. Il contrôle l'assemblage et renvoie à l'agent un retour d'information : ce qui flotte, ce qui se chevauche, ce qui n'est pas relié au reste. L'agent lit les erreurs sous forme de texte et corrige son code jusqu'à ce que la construction soit correcte.

Les chiffres clés de l'étude :

• 100% de validité physique sur l'échantillon de 512 prompts pour les agents équipés de BrickWright
• 9% pour GPT-6 Luna en configuration de base
• 69% pour GPT-6 Astra en configuration de base
• 2× d'économie sur le coût d'inférence grâce à l'API BrickLayer, par rapport au LDraw brut
• entrée : prompt textuel ou image, fonctionnement sur des agents pré-entraînés, sans entraînement dédié

La validité n'a pas sacrifié la qualité

La fiabilité s'achète facilement au prix de résultats ennuyeux : on peut ne construire que des plaques plates, qui passeront n'importe quelle vérification. C'est pourquoi la seconde moitié du résultat compte. Pour les agents légers, la conformité au prompt a progressé ; pour les agents puissants, elle est restée au même niveau. Autrement dit, les contraintes physiques n'ont pas poussé les modèles à simplifier leur idée.

Les auteurs ont aussi comparé leur méthode à des modèles spécialisés dans la tâche text-to-brick, entraînés précisément à générer des assemblages de briques. Les agents BrickWright les ont surpassés. Un modèle généraliste doté de bons outils s'est révélé plus performant qu'une solution étroite.

À quoi cette approche peut servir

L'application directe est évidente : générer des notices et des sets LEGO à partir d'une description ou d'une photo, là où il est exclu de livrer une construction qui s'effondrerait sur la table. Le code du projet est ouvert : on peut le récupérer et le brancher à son propre agent.

Plus largement, c'est le schéma lui-même qui fonctionne : une API propre au domaine, plus un validateur qui renvoie les erreurs dans la boucle. Il convient à toutes les tâches dont le résultat doit obéir à des règles strictes : pièces de CAO, implantation d'équipements, assemblage à partir de composants standard. La leçon pour les développeurs d'agents est simple. Avant d'améliorer le modèle, mieux vaut vérifier qu'il dispose d'une vraie règle pour s'autocontrôler. Ici, elle a fait passer le pire résultat de 9% à 100% et a, au passage, divisé par deux les dépenses en tokens.