Grok Build /goal: die Selbstprüfung ist eingebaut, der Beweis nicht

Am 22. Juni hat xAI /goal in Grok Build vorgestellt, einen neuen Modus für lange, autonome Läufe. Sie geben dem Agenten ein Ziel, und er arbeitet daran weiter, bis die Aufgabe erledigt und geprüft ist. Bemerkenswert ist nicht das einzelne Feature, sondern was es sichtbar macht: Der Ausführen-und-Prüfen-Kreis, den man vor einem Jahr noch selbst zusammengeschraubt hat, steckt jetzt als Kommando im Werkzeug. Das ist praktisch, und es verschiebt die Frage, nicht weniger als bei jeder Automatisierung davor.

Was ist /goal?

/goal ist ein Modus in Grok Build, dem Kommandozeilen-Agenten von xAI, der für lange, autonome Ausführung gedacht ist. Sie geben in einer Zeile ein Ziel vor, der Agent plant einen Weg, zerlegt die Arbeit in eine Fortschrittsliste und beginnt zu arbeiten. Während er läuft, können Sie ihm weiter Hinweise geben. Laut xAI macht er so lange weiter, bis die Aufgabe erledigt und geprüft ist, sei es durch das Lesen von Code, das Ansehen von Webseiten oder das Ausführen von Skripten. Für lange Läufe gibt es zusätzliche Kommandos zum Beobachten und Steuern. Ist das Ziel erreicht, springt die Anzeige auf „Complete“, mit jedem Punkt der Liste abgehakt.

Warum die Schleife jetzt im Werkzeug steckt

Genau diese Form habe ich im Loop Engineering beschrieben: Eine Schleife ist im Kern ein rekursives Ziel. Sie definieren den Zweck, die KI iteriert, bis er erreicht ist. Was damals ein Haufen eigener Skripte war, liefert xAI nun als /goal ab. Das senkt die Einstiegshürde deutlich. Wer früher den Takt, die Fortschrittsliste und das Abhaken selbst bauen musste, bekommt es jetzt als ein Kommando.

Der Gewinn ist echt. Der Preis ist, dass die Schleife unsichtbarer wird. Solange ich die Skripte selbst geschrieben habe, wusste ich, wann der Agent als fertig galt und woran. Steckt diese Logik im Produkt, übernehme ich eine Definition von „fertig“, die ich nicht festgelegt habe. Umso wichtiger ist, genau hinzusehen, was der Agent unter geprüft versteht.

Geprüft ist eine Behauptung, kein Beweis

Die Ankündigung sagt, der Agent laufe weiter, bis die Aufgabe geprüft ist. Sie beschreibt aber nicht, dass eine unabhängige Instanz nachsieht. Wenn derselbe Agent baut und sein Ergebnis abnickt, ist „Complete“ sein eigenes Urteil über seine eigene Arbeit. Modelle benoten sich dabei zu nett. Eine abgehakte Liste ist ein Bericht über die Absicht, kein Nachweis, dass das Ergebnis stimmt. Genau hier bleibt die Prüfung bei Ihnen, und ein grüner Haken darf nicht der Punkt sein, an dem Sie aufhören hinzusehen.

Je länger der Lauf, desto größer die Lücke zwischen dem, was entstanden ist, und dem, was Sie wirklich gelesen haben. Ein Modus, der eine Stunde unbeaufsichtigt arbeitet, arbeitet eine Stunde lang auch unbeaufsichtigt an den falschen Stellen, falls etwas schiefgeht. Die Bequemlichkeit, ein Ziel zu setzen und das Notebook zuzuklappen, ist real. Sie ersetzt nicht den Blick auf das, was zurückkommt.

Wo /goal seinen Platz verdient

Ich würde /goal für die langen, mühsamen Strecken einsetzen, bei denen das Ziel klar formulierbar und das Ergebnis gut prüfbar ist: eine Migration mit Tests, ein Refactoring mit grünem Build, eine stumpfe Umstellung über viele Dateien. Setzen Sie das Ziel so, dass „fertig“ an einer Bedingung hängt, die Sie selbst nachvollziehen können, und lesen Sie am Ende, was der Agent gebaut hat. Der Modus nimmt Ihnen das Tippen ab, nicht die Verantwortung. Diese Reihenfolge ist der eigentliche Gewinn.

Quellen

• xAI: Introducing /goal