Die zweite Grundregel für die Arbeit mit KI-Agenten: Eine große Anfrage in kleinere Einheiten zu zerlegen, mit Verifikation nach jedem Schritt, liefert bessere Ergebnisse als ein einziger riesiger Prompt.
Wer ein großes neues Feature angeht, teilt es besser in kleinere Tasks auf, und zwar aus mehreren Gründen.
Eines der wichtigsten Dinge ist, wie sich die Kosten der Softwareentwicklung über die Zeit verhalten. Das Buch Code Complete enthält ein bekanntes Diagramm, das zeigt, um wie viel teurer eine Fehlerbehebung wird, je nachdem, in welcher Entwicklungsphase man den Fehler findet: In der Analyse sind die Kosten nahezu null, sobald die Software aber beim Kunden produktiv läuft, liegen sie um eine Größenordnung oder mehr höher. Bei der Geschwindigkeit, mit der KI heute Code erzeugt, muss man noch sorgfältiger darauf achten, die Architektur vorab zu entwerfen – denn Refactoring ist genau das, womit KI nicht besonders gut zurechtkommt. Am besten hält man sich an die in Clean-Code-Büchern beschriebenen Standards und nutzt etablierte Muster für Struktur und Geschäftslogik – Bücher gehören zu den hochwertigsten Quellen, aus denen ein KI-Modell beim Training korrekte Praktiken gelernt hat, daher versteht es sie am besten. Für die KI ist es außerdem wichtig, den Code auch in einem Monolithen in klare Schichten zu gliedern – der Agent findet sich dann deutlich leichter im Code zurecht.
Kehren wir zur Frage zurück, wie man Tasks richtig aufteilt. Angenommen, die Aufgabe lautet: ein neues Formular zur Kundenzufriedenheit bauen. Welche Phasen brauchen wir?
- UI – das Formular, seine Felder und das Submit-Ereignis.
- Geschäftslogik – Validierung des Formulars, Zuordnung der Anfrage zum Kundenkonto, Priorität der Anfrage.
- Datenstruktur – wie die Daten zum BE und zurück zum FE gelangen.
- BE – wieder Validierung und Geschäftslogik, diesmal auf der Backend-Seite.
- Datenschicht – Mapping von der Datenstruktur auf die Datenbank.
- Persistieren der Daten, plus die passende Struktur, die vom BE zurück zum FE fließt.
Für die KI spielt es kaum eine Rolle, wo man beginnt – wichtig ist, jeden Schritt korrekt zu beschreiben. Für den Benutzer ist es am praktischsten, entweder bei der Datenbank oder beim Frontend anzufangen.
Damit sind alle Tasks abgedeckt. Die Frage lautet nun: Was ist der Unterschied zwischen einem großen Task und mehreren kleineren?
Bei einem einzelnen Task liegt der Vorteil in einem gemeinsamen Kontext (Cache) über alle Schritte – der Agent muss nie etwas erneut nachschlagen. Über mehrere Turns kehrt sich dieser Vorteil jedoch um: Je länger man in einem Kontext bleibt, desto mehr Tokens werden in jedem folgenden Turn erneut gesendet und verarbeitet, sodass die Kosten pro Turn mit der Größe des Kontexts weiter wachsen – bei einem langen Task mit vielen Turns kann das eine spürbare Summe ergeben.
Teilen wir die Tasks stattdessen auf, erledigt die KI immer nur ihren einen konkreten Teil, der am Ende unabhängig getestet werden kann – Fehler werden entdeckt, bevor die Arbeit am nächsten Teil überhaupt beginnt. Wir verbrauchen insgesamt weniger Tokens, und weil sich jeder Schritt unabhängig verifizieren lässt, fallen Halluzinationen oder Abweichungen von der Anforderung deutlich früher auf als nach Abschluss eines einzigen riesigen Tasks. Kleinere Tasks verlangen vom Modell außerdem nicht, seine Aufmerksamkeit gleichzeitig auf jedes Detail zu halten.
Warum ist das für KI-Modelle so wichtig? Sie können die Priorität über eine große Zahl von Anweisungen hinweg nur begrenzt aufrechterhalten. Schreibt man „füge ein neues Feature hinzu, refaktoriere die alte Logik und behebe drei zusammenhängende Bugs“ in einen einzigen Prompt, erstellt sich das Modell seine eigene Prioritätenreihenfolge – und die muss nicht mit der eigenen übereinstimmen. Das Ergebnis: Ein Teil der Aufgabe wird brillant erledigt, ein Teil vernachlässigt, und niemand merkt es, bis es in der Produktion kaputtgeht.
Genau deshalb zerlegt AITM große Anfragen in verkettete Tasks, statt sie als einen durchgehenden Durchlauf laufen zu lassen.
Wie das in der Praxis aussieht: ein normaler KI-Chat vs. AITM
Ein normaler KI-Agent (Chat/IDE-Copilot): Man gibt ihm einen langen Prompt, und der Agent arbeitet in einem durchgehenden Kontext. Verhaut er nach 80 % ein Detail, erfährt man das erst beim Review des gesamten Diffs – inzwischen wurde die Arbeit an späteren Punkten auf dem fehlerhaften Fundament fortgesetzt.
AITM: Dieselbe Anfrage wird in Chat/Brainstorming in einzelne verkettete Task-Aufrufe mit Abhängigkeiten zerlegt – Task B darf erst starten, nachdem Task A die gesamte Pipeline durchlaufen hat und gemergt wurde. Schlägt Task A bei Review oder Test fehl, startet Task B nicht auf einem kaputten Fundament – er wartet. Währenddessen bewertet der Watchdog das Scheitern von Task A selbst: Kann er den Fehler analysieren und eine Korrektur vorschlagen, startet der Task automatisch neu, mit einem Prompt, der genau diesen Fehler und die vorgeschlagene Korrektur beschreibt; ist der Fehler unklar oder ohne menschliche Entscheidung nicht lösbar, stoppt der Task und wartet darauf, dass der Benutzer entscheidet, wie es weitergehen soll. Zusätzlich läuft nach dem Merge des letzten Tasks der Kette ein Chain-audit-Schritt – eine deterministische (nicht KI-basierte) Abschlussprüfung, die die von der gesamten Kette betroffenen Contracts erneut validiert.
Den Unterschied sieht der Benutzer so: Bei einem normalen Agenten erhält man am Ende einen großen, undurchsichtigen Diff. Mit AITM erhält man mehrere kleinere, benannte, unabhängig geprüfte Tasks mit eigenem Verlauf – und man weiß genau, wo etwas schiefging, wenn es nicht nach Plan lief.