Mistral Large 4 hat den Würfel geknackt – und ihn dann verloren

Matthew Berman, ein bekannter KI-Leistungstester, forderte kürzlich Mistral Mistral Large 4 heraus, eine browserbasierte, interaktive Rubik's's Cube-Simulation zu erstellen. Diese Aufgabe geht über die statische Bilderzeugung hinaus und erfordert, dass das Modell funktionalen Code produziert, der in der Lage ist, ein 3D-Objekt zu rendern und auf Benutzereingaben zu reagieren.

Eine erfolgreiche Simulation erfordert mehr als visuelle Wiedergabetreue. Sie muss:

• Die 27 einzelnen Cubies rendern, aus denen der Würfel besteht
• Benutzereingaben akzeptieren, um bestimmte Seiten auszuwählen und zu drehen
• Die Farbe und Position jedes kleinen Flächenelements bei komplexen Transformationen präzise beibehalten

Anfangs lieferte Mistral Mistral Large 4 einen visuell überzeugenden Würfel, der eine vollständige Kamerarotation ermöglichte. Diese erste Iteration schien vielversprechend, aber ein kritischer Fehler trat auf: Die „Mischen“-Schaltfläche, die den Zustand des Würfels randomisieren sollte, blieb ohne Funktion, sodass der Würfel dauerhaft gelöst blieb. Berman beschrieb dies als ein „Versagen“ in seinem cube test und hob die Lücke zwischen visueller Ausgabe und funktionaler Interaktivität hervor.

Bermans zweiter Versuch, Mistral Mistral Large 4 zu einem funktionsfähigen Rubik's's Cube zu bewegen, ergab ein frustrierendes Paradoxon. Nach einer weiteren Iteration implementierte der generierte Code erfolgreich side rotations, wodurch Benutzer die Seiten wie beabsichtigt drehen konnten. Doch diese Korrektur führte einen neuen Fehler ein: Bei jeder Drehung verschwanden alle Farben von den Oberflächen des Würfels.

Dieses Ergebnis unterstreicht eine entscheidende Unterscheidung bei 3D-Simulationen. Während die Kamera immer noch um den Würfel kreisen konnte und eine dynamische Perspektive bot, ist diese visuelle Bewegung völlig unabhängig von der internen Mechanik des Puzzles. Die korrekte Aktualisierung der Positions- und Farbzustände einer Seite erfordert eine sorgfältige Synchronisation zwischen der gerenderten Geometrie und dem zugrunde liegenden Datenmodell.

Die Herausforderung liegt in der Verwaltung von 3D transforms, Cubie-Identitäten und gerenderten Materialien. Jeder der 26 sichtbaren „Cubies“ muss seine einzigartige Identität und Farbinformation beibehalten, selbst wenn er sich über verschiedene Seiten und Ausrichtungen bewegt. Als der Code von Mistral Mistral Large 4 dazu führte, dass Farben verschwanden, deutete dies auf eine Desynchronisation hin: Die Cubies rotierten zwar physisch, aber ihre zugehörigen Materialeigenschaften oder UV-Textur-Mappings – also wie Farben auf Oberflächen angewendet werden – wurden nicht korrekt aktualisiert oder wurden überschrieben.

Hier geht es nicht nur um das Rendern; es geht um persistentes state management. Die Simulation muss die Position und Ausrichtung jedes Cubies relativ zum Mittelpunkt des Würfels verfolgen und sicherstellen, dass die Farbinformationen bei jedem Mischen und Drehen konsistent an die richtigen Flächen gebunden bleiben. Das Modell hatte Schwierigkeiten, diesen komplexen, miteinander verflochtenen Zustand über iterative Codeänderungen hinweg aufrechtzuerhalten.

Bermans Video „Mistral Mistral Large 4 failed my Rubik's's's Cube Test“ offenbart eine kritische Nuance, die bei LLM-Bewertungen oft übersehen wird: Er schreibt das endgültige Versagen nicht Mistral Mistral Large 4 selbst zu, sondern der Interaktion zwischen dem Modell und seinem „Harness“ (Framework). Diese Unterscheidung ist entscheidend für das Verständnis komplexer KI-gestützter Entwicklung.

Das Harness bezieht sich auf den umgebenden Agenten-Workflow – das automatisierte System, das dem Modell Kontext liefert, seine Bearbeitungen anwendet und den generierten Code ausführt oder überprüft. Sein Verhalten kann maßgeblich beeinflussen, was das Modell zu korrigieren vermag, insbesondere beim iterativen Debugging. Beispielsweise könnte ein Harness Diffs falsch anwenden, Modellanweisungen missverstehen oder kein umfassendes Test-Feedback liefern.

In diesem Szenario hat Mistral Mistral Large 4 zwar Code erzeugt, der Seitenrotationen funktionsfähig machte, aber die anschließende Handhabung durch das Harness könnte den visuellen Zustand des Würfels beschädigt haben, was dazu führte, dass Farben verschwanden. Das Video zeigt das Ergebnis, isoliert jedoch nicht die Grundursache, was es schwierig macht, die Schuld eindeutig dem logischen Schlussfolgern des Modells, dem generierten Code, der Bearbeitungsanwendung oder dem Test-Framework zuzuweisen.

Dies unterstreicht eine wachsende Herausforderung bei der KI-gestützten Entwicklung: die Trennung der Modellfähigkeiten von der Leistung der Tools, die sie orchestrieren. Da Modelle immer ausgefeilter werden, wird die Qualität des Harness – seine Fähigkeit, den Zustand beizubehalten, Multi-File-Edits zu verwalten und präzises Feedback zu geben – zu einem Engpass. Entwickler, die weitere Details zu den laufenden Fortschritten von Mistral suchen, können Mistral AI - Latest News and Model Announcements konsultieren. Diese Unterscheidung ist entscheidend, um zu verstehen, warum komplexe Aufgaben wie ein Rubik's Cube-Test selbst bei leistungsstarken Modellen scheitern können.

Bermans Würfeltest hebt eine kritische Unterscheidung hervor: Statische Coding-Benchmarks oder attraktive erste Renderings übersehen oft grundlegende Schwächen. Zustandsbehaftete, interaktive Aufgaben legen offen, wie eine KI mit persistenten Daten, Event-Listenern und UI-Echtzeit-Updates über mehrere Durchläufe hinweg umgeht. Ein Modell mag zwar schönen anfänglichen Code generieren, scheitert jedoch möglicherweise daran, die Konsistenz aufrechtzuerhalten, wenn der Benutzer damit interagiert oder wenn das System selbst den Code iteriert.

Für Entwickler bietet dies eine praktische Lektion. Bewerten Sie KI-Coding-Tools nach ihrem End-to-End-Verhalten, nicht nur anhand eines Screenshots der ersten Ausgabe. Bewerten Sie die Leistung über wiederholte Interaktionen hinweg und integrieren Sie Regressionsprüfungen in Ihren Workflow. Diese Schritte zeigen, ob eine KI robuste, wartbare Systeme aufbauen kann oder lediglich beeindruckende, aber anfällige Ausgangspunkte generiert.

Die Leistung von Mistral Mistral Large 4 beim Rubik's Cube-Test dient als aufschlussreiches Scheitern des versuchten Workflows. Das Modell konnte ein visuell ansprechendes, interaktives 3D-Objekt und später funktionale Rotationen generieren. Doch das komplexe Zusammenspiel von räumlichen Koordinaten, Zustands-Synchronisation und UI-Rendering erwies sich als zu schwierig für den iterativen Prozess, den Berman anwandte.

Obwohl diese einzelne Demo nicht allgemein beweisen kann, dass Mistral Mistral Large 4 nicht programmieren kann, unterstreicht sie die Herausforderungen bei der Multi-Turn, zustandsbehafteten Codegenerierung. Das Problem liegt, wie Berman andeutet, wahrscheinlich in der Interaktion zwischen dem Modell und seinem Harness, nicht allein in den intrinsischen Fähigkeiten des Modells. Dieser komplexe Tanz zwischen KI und ihrer operativen Umgebung bleibt eine erhebliche Hürde für fortschrittliche KI-Coding-Agenten.

Was hat Mistral Large 4 beim Rubik's Cube-Test falsch gemacht?

Die erste Version rendert zwar einen Würfel, reagierte aber nicht auf den Scramble-Button. Eine spätere Iteration ermöglichte die Gesichtsrotation, aber die Farben des Würfels verschwanden.

Hat Mistral Large 4 nicht verstanden, wie ein Rubik's Cube funktioniert?

Der Test belegt das nicht. Er zeigt, dass die generierte Implementierung Schwierigkeiten hatte, Interaktionen und visuellen Zustand zusammenarbeiten zu lassen.

Was bedeutet „Harness“ in diesem Test?

Das Harness ist das Tooling und der Workflow um das Modell herum, das Bearbeitungen, Kontext, Codeausführung und Iteration verwaltet.

Warum ist ein Rubik's Cube ein schwieriger KI-Coding-Test?

Eine funktionierende Simulation muss 3D-Rendering, Gesichtsrotationen, Steuerelemente und einen persistenten Farbzustand koordinieren – nicht nur einen Würfel zeichnen.