Claude Code /goal:
Tiefe statt Breite bei autonomen KI-Agenten

Der andere Modus: Tiefe statt Breite

Die meisten Gespraeche ueber KI-Coding-Agenten drehen sich gerade um Skalierung nach aussen: mehr Agenten, mehr Worktrees, mehr Tickets gleichzeitig. Wir haben diesem Muster einen eigenen Artikel gewidmet – Parallel entwickeln mit KI-Agenten: Git Worktrees als Produktivitaetsmultiplier – weil es fuer Teams mit vielen unabhaengigen Aufgaben enorm viel Durchsatz freisetzt.

Es gibt aber ein zweites, leiseres Muster, das fuer Unternehmen, die autonome Agenten in eigene Prozesse einbauen wollen, mindestens genauso relevant ist: Was passiert, wenn Sie einen einzigen Agenten auf ein einziges, schwieriges Ziel ansetzen und ihn stundenlang ohne Zwischenfreigabe laufen lassen? Nicht mehr Agenten – ein Agent, der tiefer geht.

Genau dieses Muster hat Anthropic mit dem /goal-Befehl in Claude Code in ein konkretes Werkzeug gegossen. Er wurde laut Anthropics offiziellem Changelog mit Claude Code v2.1.139 in der Woche vom 11. bis 15. Mai 2026 eingefuehrt – als Teil desselben Release-Zyklus wie die "Agent View"-Uebersicht fuer laufende Sessions.

Was der /goal-Befehl technisch tut

Die Grundidee ist einfach zu beschreiben, aber praezise umgesetzt: Sie setzen eine Abbruchbedingung, und Claude Code arbeitet danach eigenstaendig darauf hin – ueber viele Zuege hinweg, ohne dass Sie jeden einzelnen Schritt freigeben muessen.

# Ziel setzen – startet sofort den ersten Zug
/goal all tests in test/auth pass and the lint step is clean

# Status pruefen: Dauer, Zuege, Tokens, letzte Begruendung des Evaluators
/goal

# Ziel vorzeitig abbrechen (Aliase: stop, off, reset, none, cancel)
/goal clear

# Headless: laeuft die Schleife bis zum Abschluss in einem Aufruf durch
claude -p "/goal CHANGELOG.md hat einen Eintrag fuer jeden PR dieser Woche"

Nach Anthropics eigener Dokumentation ist /goal technisch ein Wrapper um einen session-gebundenen, prompt-basierten Stop-Hook. Nach jedem Zug schickt Claude Code die Bedingung zusammen mit dem bisherigen Gespraechsverlauf an ein kleines, schnelles Modell – standardmaessig Haiku. Dieses Evaluator-Modell antwortet mit Ja oder Nein plus einer kurzen Begruendung. Bei "Nein" arbeitet Claude im naechsten Zug weiter, die Begruendung dient dabei als Hinweis, woran es noch hakt. Bei "Ja" loescht sich das Ziel automatisch und der Erfolg wird im Transkript vermerkt.

Entscheidend: Der Evaluator fuehrt selbst keine Tools aus. Er liest nur, was Claude bereits im Gespraech sichtbar gemacht hat – ein Testlauf, ein Build-Exit-Code, eine Diff-Ausgabe. Eine Bedingung wie "alle Tests in test/auth sind gruen" funktioniert deshalb gut: Claude fuehrt die Tests selbst aus, das Ergebnis landet im Transkript, und der Evaluator kann es lesen. Die Bedingung darf bis zu 4.000 Zeichen lang sein, und Anthropics Dokumentation empfiehlt ausdruecklich, eine Obergrenze einzubauen, etwa "oder stoppe nach 20 Zuegen" – ohne diese Klausel kann eine Session theoretisch sehr lange weiterlaufen.

Pro Session ist immer nur ein Ziel aktiv. Wichtig ist auch die Abgrenzung zum sogenannten Auto Mode: Auto Mode genehmigt Tool-Aufrufe automatisch innerhalb eines Zugs, entscheidet aber nicht, ob ein neuer Zug beginnt. /goal ergaenzt das um eine zweite, unabhaengige Bewertungsebene zwischen den Zuegen – ein frisches Modell entscheidet, ob wirklich fertig ist, statt sich auf das Modell zu verlassen, das den Code geschrieben hat.

Tiefe vs. Breite: /goal im Vergleich zu parallelen Agenten

Hier lohnt sich der explizite Vergleich mit unserem Artikel zu Git Worktrees und parallelen KI-Agenten. Beide Muster loesen ein Autonomie-Problem – aber ein unterschiedliches.

Parallele Agenten via Git Worktrees verteilen mehrere unabhaengige Aufgaben auf mehrere gleichzeitig laufende Agenten: Feature A in Worktree 1, Refactoring B in Worktree 2, Migration C in Worktree 3. Das ist Breite – mehr Durchsatz durch Parallelisierung. Anthropic hat mit "dynamic workflows" (eingefuehrt zusammen mit Opus 4.8, Woche vom 25. bis 29. Mai 2026) dieses Muster sogar noch weiter automatisiert: Ein Skript, das Claude selbst schreibt, orchestriert dabei Dutzende bis Hunderte Subagenten.

/goal tut das Gegenteil: ein Agent, ein Ziel, viele Zuege hintereinander auf demselben Branch. Statt zehn kleine Aufgaben parallel zu erledigen, arbeitet sich ein Agent durch eine einzige, groessere Aufgabe – zum Beispiel eine komplette Modul-Migration, bis jede Aufrufstelle kompiliert und alle Tests bestehen. Das ist Tiefe.

Ein Praxisbeispiel: Von Prototyp zu MVP

Clawgency-Gruender Joshua Heller hat in einem eigenen LinkedIn-Beitrag ein konkretes Beispiel aus der eigenen Praxis beschrieben – und wir wollen es hier bewusst als Einzelfall einordnen, nicht als allgemeingueltige Kennzahl.

Ausgangspunkt war die Migration einer Anwendung vom Prototyp zum MVP: neue Datenbank, neues Backend, neuer Storage-Layer, neue Authentifizierung – ein Eingriff, der praktisch jeden Teil der Anwendung beruehrt. Statt jeden Testfall manuell durchzuklicken, setzte er ein /goal, das Claude Code dazu brachte, End-to-End-Tests und Sicherheitschecks eigenstaendig zu durchlaufen: Anwendung starten, Kernablaeufe durchspielen, Fehler interpretieren, Code korrigieren, erneut testen – so lange, bis der Agent selbst zu dem Schluss kam, dass die Bedingung haelt.

Nach seiner eigenen Schilderung fing der Agent dabei die meisten Bugs automatisch ab und sparte ihm nach eigener Schaetzung rund einen Arbeitstag manuelles Testen. Ein Teil der Randfaelle musste er im Anschluss trotzdem von Hand pruefen. Genau dieser zweite Teil ist wichtig – dazu gleich mehr im Abschnitt ueber menschliches Review. Das Beispiel zeigt, was /goal in einer konkreten Situation leisten kann – es ist keine belastbare Kennzahl fuer "wie viel Prozent der Bugs KI-Agenten automatisch finden". Solche pauschalen Prozentzahlen kursieren zwar in Social-Media-Diskussionen ueber Agenten, sind aber nicht seriös belegt und sollten mit Vorsicht behandelt werden.

Best Practices fuer den sicheren Einsatz

Aus der offiziellen Dokumentation und aus der Praxis lassen sich klare Leitplanken ableiten, bevor Sie /goal auf etwas Wichtiges ansetzen:

• Klar begrenzter Umfang: Ein Modul, ein Feature, ein Verzeichnis – keine "mach die ganze Codebase besser"-Formulierungen.
• Ein pruefbarer Erfolgszustand: "Alle Tests bestehen" funktioniert, weil der Evaluator es im Transkript nachlesen kann. Vage Ziele wie "Code ist sauberer" funktionieren nicht.
• Explizite Grenzen: Was darf sich nicht aendern? Welche Dateien sind tabu? Das gehoert in die Bedingung, nicht in Ihren Kopf.
• Kontext, den der Agent nicht erraten kann: Geschaeftsregeln, Compliance-Anforderungen, bestehende Architekturentscheidungen.
• Immer auf einem versionskontrollierten Branch: Nie auf main. Ein langer autonomer Lauf gehoert isoliert.
• Ein Diff-Review vor dem Merge: Ausnahmslos – dazu mehr im naechsten Abschnitt.

Der Branchenkontext: Was Zahlen wirklich zeigen

Warum ist das gerade jetzt relevant? Weil Softwaretests ein teures, personalintensives Feld sind – und weil sich die Branche 2026 sichtbar in Richtung Automatisierung bewegt, ohne dass das Problem bereits geloest waere.

Zur Einordnung der reinen Kosten: Das US Bureau of Labor Statistics beziffert das mittlere Jahresgehalt von Software-QA-Analysten und -Testern in seinem Occupational Outlook Handbook (Stand Mai 2024) auf 102.610 US-Dollar (rund 49 US-Dollar pro Stunde); fuer die breitere Kategorie aus Software-Entwicklern sowie QA-Analysten und Testern zusammen liegt der Wert bei 131.450 US-Dollar pro Jahr (63,20 US-Dollar pro Stunde).

Branchenreports zeichnen ein Bild wachsender Automatisierung: Der "QA Trends Report 2026" von ThinkSys berichtet, dass mittlerweile ueber 60 % der QA-Pipelines in Unternehmen automatisiert laufen. Das ist ein Trendbefund einzelner Anbieterstudien, keine universelle Kennzahl – aber die Richtung ist eindeutig. Gleichzeitig zeigt der "2026 Quality Transformation Report" von Tricentis eine interessante Gegenposition: Trotz KI-Beschleunigung geben 60 % der befragten Organisationen an, weiterhin ungetesteten Code in Produktion zu bringen. Autonome Test-Agenten sind also kein geloestes Problem, sondern ein aktives Spannungsfeld zwischen Entwicklungsgeschwindigkeit und Testkapazitaet.

Auf der Kostenseite schaetzt der Anbieter Bug0 in seinem Blogbeitrag "The 2026 Quality Tax", dass manuelles QA bei einem schnell wachsenden Startup versteckte Kosten von rund 55.000 bis 78.000 US-Dollar pro Entwickler und Jahr erzeugt – ausdruecklich als Schaetzung eines Testing-Anbieters zu verstehen, nicht als branchenweit belastbare Zahl.

Was Menschen weiterhin reviewen muessen

So leistungsfaehig der Loop ist – er hat eine strukturelle Grenze, die direkt aus der Funktionsweise des Evaluators folgt: Er fuehrt selbst keine Befehle aus und kann nur beurteilen, was Claude im Gespraech sichtbar gemacht hat. Was Claude nicht testet oder nicht erwaehnt, kann der Evaluator nicht bewerten. Ein "Ja" heisst also "die Bedingung haelt gemaess dem, was im Transkript steht" – nicht "der Code ist fehlerfrei".

Konkret bleiben mindestens diese Punkte in menschlicher Verantwortung:

• Business-Logik-Randfaelle: Faelle, die kein Test abdeckt, weil niemand daran gedacht hat, sie zu schreiben.
• Sicherheitsrelevanter Code: Auch wenn ein "Sicherheitscheck" im Ziel steht, ersetzt das kein dediziertes Security-Review bei Auth, Payments oder personenbezogenen Daten.
• Datenmigrationen: Ein gruener Testlauf beweist nicht, dass historische Produktionsdaten korrekt migriert wurden.
• DSGVO- und Compliance-Fragen: Automatisierte Tests pruefen Funktion, nicht Rechtskonformitaet.
• UX- und Produktentscheidungen: "Funktioniert" und "ist die richtige Loesung fuer Nutzer" sind zwei verschiedene Fragen.

Die ehrliche Einordnung: Autonome Agenten wie ein /goal-Lauf verschieben, wo menschliche Aufmerksamkeit ansetzt – von "jeden Zwischenschritt beobachten" zu "das Endergebnis pruefen". Sie ersetzen die Pruefung nicht.

Die Parallele zu OpenClaw im Unternehmen

Diese Vertrauensfrage ist nicht auf Software-Entwicklung beschraenkt. Wer OpenClaw-Agenten in eigene Geschaeftsprozesse einbindet – Kundenservice-Automatisierung, Angebotsvorbereitung, Dokumentenverarbeitung –, steht vor derselben Grundfrage wie ein Entwickler vor einem langen /goal-Lauf: Wie pruefen Sie autonome Arbeit, ohne jeden Schritt zu beobachten?

Claude Code und OpenClaw sind dabei bewusst als getrennt zu verstehen: Claude Code ist Anthropics CLI fuer Coding-Agenten, OpenClaw das quelloffene Agenten-Framework, das Clawgency fuer Geschaeftsprozess-Automatisierung im deutschsprachigen Mittelstand implementiert – teils auf Basis von Werkzeugen wie Claude Code, aber ein eigenstaendiges Produkt mit eigener Governance-Schicht. Das Grundmuster aus diesem Artikel – klar begrenzter Scope, pruefbare Erfolgsbedingung, Review am Ende statt bei jedem Schritt – uebertraegt sich direkt auf unsere OpenClaw-Implementierungen fuer Unternehmen und auf die konkreten Use Cases und ROI-Muster fuer den Mittelstand, die wir dort beschreiben.

FAQ: Claude Code /goal und autonome Test-Agenten