Mistral Large 4 a résolu le cube, puis l'a perdu

Matthew Berman, un testeur de performance IA renommé, a récemment mis au défi Mistral Mistral Large 4 de construire une simulation interactive de Rubik's Cube basée sur un navigateur. Cette tâche va au-delà de la simple génération d'images statiques, exigeant que le modèle produise un code fonctionnel capable de rendre un objet 3D et de répondre aux entrées de l'utilisateur.

Une simulation réussie nécessite plus qu'une simple fidélité visuelle. Elle doit :

• Rendre les 27 petits cubes individuels qui composent le cube
• Accepter les entrées de l'utilisateur pour sélectionner et faire pivoter des faces spécifiques
• Conserver avec précision la couleur et la position de chaque facette lors de transformations complexes

Initialement, Mistral Mistral Large 4 a livré un cube visuellement convaincant permettant une rotation complète de la caméra. Cette première itération semblait prometteuse, mais un défaut critique est apparu : le bouton « mélanger », destiné à randomiser l'état du cube, est resté inactif, laissant le cube perpétuellement résolu. Berman a qualifié cela d'« échec » lors de son cube test, soulignant le fossé entre le rendu visuel et l'interactivité fonctionnelle.

La deuxième tentative de Berman pour obtenir un Rubik's Cube fonctionnel de la part de Mistral Mistral Large 4 a abouti à un paradoxe frustrant. Après une nouvelle itération, le code généré a réussi à implémenter les side rotations, permettant aux utilisateurs de faire tourner les faces comme prévu. Pourtant, cette correction a introduit un nouveau bug : toutes les couleurs disparaissaient des surfaces du cube à chaque rotation.

Ce résultat met en lumière une distinction cruciale dans les simulations 3D. Bien que la caméra puisse toujours orbiter autour du cube, offrant une perspective dynamique, ce mouvement visuel est totalement distinct des mécanismes internes du puzzle. La mise à jour correcte de la position et de l'état de couleur d'une face nécessite une synchronisation méticuleuse entre la géométrie rendue et le modèle de données sous-jacent.

Le défi réside dans la gestion des 3D transforms, des identités des petits cubes et des matériaux rendus. Chacun des 26 « petits cubes » visibles doit conserver son identité unique et ses informations de couleur, même lorsqu'il se déplace sur différentes faces et orientations. Lorsque le code de Mistral Mistral Large 4 a provoqué la disparition des couleurs, cela a suggéré une désynchronisation : les petits cubes tournaient physiquement, mais leurs propriétés de matériau associées ou leurs mappages de texture UV — la manière dont les couleurs sont appliquées aux surfaces — n'étaient pas correctement mis à jour ou étaient écrasés.

Il ne s'agit pas seulement de rendu ; il s'agit de state management persistant. La simulation doit suivre la position et l'orientation de chaque petit cube par rapport au centre du cube, en s'assurant que les informations de couleur restent liées de manière cohérente aux bonnes facettes tout au long de chaque mélange et rotation. Le modèle a eu du mal à maintenir cet état complexe et entremêlé à travers les changements de code itératifs.

La vidéo de Berman, « Mistral Mistral Large 4 failed my Rubik's's's Cube Test », révèle une nuance critique souvent négligée dans les évaluations de LLM : il n'attribue pas l'échec final à Mistral Mistral Large 4 lui-même, mais à l'interaction entre le modèle et son « harnais » (harness). Cette distinction est vitale pour comprendre le développement complexe piloté par l'IA.

Le harnais fait référence au flux de travail de l'agent environnant — le système automatisé qui fournit le contexte au modèle, applique ses modifications et exécute ou vérifie le code généré. Son comportement peut profondément affecter ce que le modèle parvient à corriger, en particulier lors du débogage itératif. Par exemple, un harnais peut appliquer incorrectement des diffs, mal interpréter les instructions du modèle ou échouer à fournir des retours de test complets.

Dans ce scénario, bien que Mistral Mistral Large 4 ait produit un code rendant les rotations latérales fonctionnelles, la gestion ultérieure par le harness a pu corrompre l'état visuel du cube, provoquant la disparition des couleurs. La vidéo démontre le résultat mais n'isole pas la cause profonde, ce qui rend difficile d'attribuer définitivement la responsabilité au raisonnement du modèle, au code généré, à l'application des modifications ou au framework de test.

Cela met en lumière un défi croissant dans le développement assisté par IA : séparer les capacités du modèle de la performance des outils qui les orchestrent. À mesure que les modèles deviennent plus sophistiqués, la qualité du harness — sa capacité à maintenir l'état, à gérer les modifications multi-fichiers et à fournir des retours précis — devient un goulot d'étranglement. Les développeurs souhaitant plus de détails sur les avancées continues de Mistral peuvent consulter Mistral AI - Latest News and Model Announcements. Cette distinction est cruciale pour comprendre pourquoi des tâches complexes comme le test du Rubik's cube peuvent échouer, même avec des modèles puissants.

Le test du cube de Berman met en évidence une distinction critique : les benchmarks de codage statiques ou les premiers rendus attrayants passent souvent à côté des faiblesses fondamentales. Les tâches interactives et à état exposent la manière dont une IA gère les données persistantes, les écouteurs d'événements et les mises à jour de l'interface utilisateur en temps réel sur plusieurs tours. Un modèle peut générer un code initial magnifique, mais échouer à maintenir la cohérence lorsque l'utilisateur interagit avec lui, ou lorsque le système lui-même itère sur le code.

Pour les développeurs, cela offre une leçon pratique. Jugez les outils de codage IA sur leur comportement de bout en bout, et non simplement sur une capture d'écran du résultat initial. Évaluez la performance lors d'interactions répétées et intégrez des contrôles de régression dans votre flux de travail. Ces étapes révèlent si une IA peut construire des systèmes robustes et maintenables ou simplement générer des points de départ impressionnants, mais fragiles.

La performance de Mistral Mistral Large 4 sur le Rubik's cube test sert d'échec révélateur du flux de travail tenté. Le modèle a pu générer un objet 3D interactif visuellement attrayant, puis des rotations fonctionnelles. Mais l'interaction complexe des coordonnées spatiales, de la synchronisation de l'état et du rendu de l'interface utilisateur s'est avérée trop difficile pour le processus itératif employé par Berman.

Bien que cette démonstration unique ne puisse prouver de manière générale que Mistral Mistral Large 4 est incapable de coder, elle souligne les défis de la génération de code à état et multi-tours. Le problème, comme le suggère Berman, réside probablement dans l'interaction entre le modèle et son harness, et non uniquement dans les capacités intrinsèques du modèle. Cette danse complexe entre l'IA et son environnement opérationnel reste un obstacle important pour les agents de codage IA avancés.

Qu'est-ce que Mistral Large 4 a mal fait dans le test du Rubik’s Cube ?

Sa première version a rendu un cube mais n'a pas répondu au bouton de mélange. Une itération ultérieure a permis la rotation des faces, mais les couleurs du cube ont disparu.

Mistral Large 4 a-t-il échoué à comprendre comment fonctionne un Rubik’s Cube ?

Le test ne l'établit pas. Il montre que l'implémentation générée a eu du mal à faire fonctionner ensemble les interactions et l'état visuel.

Que signifie « harness » dans ce test ?

Le harness est l'ensemble des outils et du flux de travail autour du modèle qui gère les modifications, le contexte, l'exécution du code et l'itération.

Pourquoi un Rubik’s Cube est-il un test de codage IA difficile ?

Une simulation fonctionnelle doit coordonner le rendu 3D, les rotations des faces, les contrôles et l'état persistant des couleurs — pas seulement dessiner un cube.