Du hast einen neuen Mitarbeiter im Team. Du könntest ihm jeden Schritt vorschreiben: „Öffne die Datei, suche die Fehlermeldung, ändere Zeile 42.“ Oder du sagst: „Kümmere dich um den Fehler, so gut du kannst.“ Die zweite Variante führt schneller zum Ziel. Der Mitarbeiter nutzt eigene Erfahrung und Urteilsvermögen. Dieser Gedanke überträgt ein aktueller Trend auf große Sprachmodelle – der erste Erfahrungsbericht kommt aus dem Umfeld von Claude Code.
Der Entwickler Simon berichtete von einem Fireside Chat mit Cat Wu und Thariq Shihipar vom Claude Code Team bei AIE. Dabei erhielt er diesen Tipp: Modelle wie Fable sollten ihr eigenes Urteilsvermögen nutzen, statt detaillierte Anweisungen zu bekommen. Das klingt kontraintuitiv. Das Beispiel der automatisierten Tests macht es klar.
Statt Fable zu sagen: „Schreibe nur für große Features Tests, ignoriere kleine Copy-Änderungen“, reicht der Hinweis: „Nutze dein Urteilsvermögen, wann Tests sinnvoll sind.“ Das Modell entscheidet selbst, welche Aufgaben testwürdig sind. Es vermeidet überflüssige Testläufe und das Auslassen wichtiger Tests. Das Ergebnis: weniger Verschwendung von Rechenressourcen und Token bei gleichbleibender Qualität.
Der zweite Schritt: Modelle delegieren
Jesse Vincent empfahl Simon, auch die Wahl des richtigen Modells abzugeben. Die Idee: Fable soll für mechanische Aufgaben günstigere Modelle wie Sonnet oder Haiku einsetzen und nur anspruchsvolle Schritte selbst übernehmen. Das spart Token – wichtig, weil die Preise für Fable steigen werden.
Simon setzte den Rat um. Er gab Claude Code die Anweisung: „Für alle Programmieraufgaben nutze dein Urteilsvermögen, um ein günstigeres Modell auszuwählen, und führe die Aufgabe in einem Sub-Agenten aus.“ Claude Code speicherte die Regel in einer Memory-Datei: ~/.claude/projects/name-of-project/memory/delegate-coding-to-subagents.md. Der Inhalt beschreibt: „Umsetzungsarbeit braucht selten das Spitzenmodell; Urteilsvermögen, Überprüfung und Synthese bleiben im Hauptprozess.“
So funktioniert es: Wenn eine Aufgabe hauptsächlich aus Schreiben oder Bearbeiten von Code besteht, startet der Haupt-Agent einen Sub-Agenten mit einem Modell-Override – Sonnet für substanzielle Implementierungen, Haiku für triviale Änderungen. Der Sub-Agent erhält einen geschlossenen Prompt. Der Haupt-Agent überprüft das Ergebnis, bevor es ins Projekt übernommen wird. Aufgaben mit hohem Urteilsbedarf – Design, Audits, Datensynthese – bleiben im Hauptmodell.
Warum funktioniert dieser Ansatz?
Das Prinzip ähnelt bewährten Managementtechniken: Wer Vertrauen schenkt, erzielt oft bessere Ergebnisse als mit Mikromanagement. Große Sprachmodelle haben keine Absicht, aber sie können Muster erkennen und Entscheidungen treffen – wenn man ihnen Raum gibt. Simons Konfiguration zeigt, dass Modelle selbst beurteilen können, wann ein kleineres Modell ausreicht. Sie tun das auf Basis der Aufgabenbeschreibung und des Projektkontexts.
Die Kosten-Nutzen-Rechnung ist klar. Fable ist leistungsfähig, aber teuer. Indem man es nur für anspruchsvolle Teile einsetzt und Routineaufgaben delegiert, sinken die Kosten. Simons Erfahrung: „Ich komme mit meiner Arbeit voran, und mein Fable-Kontingent schrumpft langsamer.“ Das ist ein handfestes Argument.
Der Nutzen geht über Kosteneinsparung hinaus. Das Hauptmodell bleibt für Aufgaben frei, die sein volles Potenzial brauchen. Die Antwortqualität in kritischen Entscheidungen verbessert sich. Die Latenz sinkt, weil kleinere Modelle einfache Aufgaben schneller bearbeiten. Der Entwicklungsprozess wird flüssiger und weniger anfällig für Token-Limit-Probleme.
Voraussetzungen und Grenzen
Der Ansatz funktioniert nicht völlig autonom. Der Entwickler muss klare Prinzipien vorgeben – etwa welche Aufgaben als urteilsintensiv gelten. In Simons Konfiguration bleiben Design, Auditing und Datensynthese im Hauptmodell. Das ist sinnvoll. Nicht jedes Modell kann komplexe Architekturentscheidungen treffen. Die Überprüfung der Ergebnisse durch den Haupt-Agent ist notwendig: Sub-Agenten machen Fehler, die ein Mensch oder Haupt-Agent abfangen muss.
Transparenz ist wichtig. Die Memory-Datei dokumentiert die Regel explizit. Der Entwickler kann nachvollziehen, warum Aufgaben delegiert wurden. Ohne solche Dokumentation wird das System undurchschaubar. Wer mit mehreren Projekten arbeitet, sollte projektspezifische Regeln definieren, da der ideale Delegationsgrad variiert.
Dieser Tipp stammt aus dem Kontext von Claude Code und Fable. Nicht alle KI-Assistenten bieten eine so feingranulare Sub-Agenten-Architektur. Die Idee, dem Modell Urteilsvermögen zuzugestehen, ist jedoch allgemein gültig. Selbst bei anderen technischen Umsetzungen bleibt das Prinzip: Gib der KI mehr Freiheit, statt sie zu gängeln.
Was bedeutet das für die Zukunft der KI-Entwicklung?
Simons Erfahrung zeigt, dass wir die Zusammenarbeit mit KI-Modellen neu denken müssen. Bisher war der Reflex vieler Entwickler, möglichst viele Details vorzugeben. Das führt zu übermäßigem Prompt-Engineering und suboptimaler Ressourcennutzung. Die Alternative – dem Modell Eigenverantwortung übertragen – erfordert Vertrauen und eine durchdachte Konfiguration. Wer diesen Schritt geht, kann von erheblich gesteigerter Effizienz profitieren.
Der Trend zeichnet sich ab: Immer mehr KI-Werkzeuge bieten Sub-Agenten, Modell-Routing oder automatische Kostenoptimierung. Anbieter wie Anthropic oder OpenAI arbeiten daran, dass Modelle selbst entscheiden, wann sie auf externe Tools oder kleinere Modelle zurückgreifen. Simons Konfiguration ist ein praktisches Beispiel, wie man diese Möglichkeiten heute schon nutzen kann.
Der Fall zeigt: Exzellenz in der KI-Nutzung bedeutet nicht, jedes Detail zu kontrollieren, sondern die richtigen Rahmenbedingungen zu schaffen. Wie ein guter Teamleiter delegierst du Aufgaben an passende Spezialisten und behältst die strategischen Entscheidungen selbst. Das spart Geld und Zeit und fördert eine Arbeitsweise, bei der das Modell sein volles Potenzial entfalten kann.
Quelle: simonwillison.net
