So gibst du deinem KI-Coding-Agenten eine Feedback-Schleife, die seine eigenen Bugs erkennt
Von VCA Newsroom
Wenn ein KI-Coding-Agent Code schreibt, der richtig aussieht, aber im Stillen etwas kaputtmacht, liegt das Problem meist nicht am Modell — sondern daran, dass der Agent den Fehler nie gesehen hat. Er hat die Änderung geschrieben, den Sieg verkündet und ist weitergezogen, weil ihm nichts mitgeteilt hat, dass die Testsuite jetzt rot war. Die Lösung ist, die Schleife zu schließen: Lass die eigenen Werkzeuge des Agenten ihm automatisch Rückmeldung geben.
Diese Anleitung zeigt, wie du diese Feedback-Schleife so baust, dass dein Agent seine Fehler erkennt, bevor du es tust.
Die Kernidee: Fehler sollten zurück in den Kontext fließen
Ein zuverlässiger Agenten-Workflow hat vier Takte — erkunden, planen, bauen, verifizieren. Die meisten Menschen hören bei "bauen" auf. Der Verifizierungsschritt ist das, was einen Agenten, der funktionierenden Code produziert, von einem unterscheidet, der nur plausibel aussehenden Code produziert.
Verifizierung bedeutet, nach jeder Änderung echte Prüfungen auszuführen — deinen Test-Runner, Linter und Type-Checker — und die Ausgabe an den Agenten zurückzuspielen. Wenn eine Prüfung fehlschlägt, landet die Fehlermeldung im Kontext des Agenten, und das Modell behandelt sie wie jede andere Anweisung: Es liest den Fehler und behebt ihn. Kein Mensch in der Schleife für die langweiligen Rundläufe.
Du kannst das auf zwei Arten tun: darum bitten in deinen Projektanweisungen oder es so automatisieren, dass es nicht übersprungen werden kann.
Option 1: Einfach darum bitten, in deiner Projektkonfiguration
Die aufwandärmste Variante ist eine Zeile in deiner CLAUDE.md oder AGENTS.md (der Klartext-Anweisungsdatei, die die meisten Agenten beim Start lesen):
## Verification
After any code change, run `npm run typecheck && npm test`.
If either fails, fix the cause and re-run before reporting done.
Das funktioniert erstaunlich gut — aber es ist nur ein Hinweis. Ein beschäftigter Agent kann es vergessen oder entscheiden, eine Änderung sei "zu klein" zum Verifizieren. Für alles, was dir wichtig ist, mach die Verifizierung deterministisch.
Option 2: Automatisiere es mit einem Hook
Claude-Code-Hooks erlauben dir, einen Shell-Befehl als Reaktion auf Lebenszyklus-Ereignisse auszuführen — unabhängig davon, ob sich das Modell daran erinnert. Der hier relevante ist PostToolUse, der nachdem der Agent eine Datei bearbeitet hat, auslöst. Wie es ein praktischer Hooks-Leitfaden formuliert, ist PostToolUse für Reaktionen gemacht — Formatieren, Logging, Tests ausführen — und seine Ausgabe wird zurück in den Kontext des Agenten eingespeist, um seinen nächsten Schritt zu beeinflussen.
Hier ist ein minimaler Hook, der deinen Type-Checker nach jeder Dateibearbeitung ausführt und Fehler an den Agenten zurückgibt. In .claude/settings.json:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npm run typecheck"
}
]
}
]
}
}
Jetzt ist der Zyklus automatisch: Der Agent schreibt Code → der Hook führt tsc aus → wenn es einen Typfehler gibt, fließt die Meldung als Kontext zurück → der Agent behebt ihn → der Hook läuft erneut. Die Hooks-Referenz dokumentiert, wie der von null verschiedene Exit-Code und die Ausgabe dem Modell sichtbar gemacht werden. Diese Schleife läuft bei jedem Schreibvorgang, ganz ohne Nachfragen.
Halte die Schleife schnell und eng gefasst
Eine Feedback-Schleife hilft nur, wenn sie schnell ist. Ein paar Faustregeln:
- Führe die günstigen Prüfungen bei jeder Bearbeitung aus, die teuren seltener. Ein Type-Check oder Linter auf der geänderten Datei ist schnell. Eine vollständige Integrationssuite nicht — sperre die hinter einen
Stop-Hook (wenn der Agent eine Runde beendet) oder einen manuellen Befehl, nicht hinter jeden Tastenanschlag. - Begrenze auf das, was sich geändert hat. Deine gesamte Testsuite nach einer einzeiligen CSS-Anpassung auszuführen, verschwendet Zeit und überflutet den Kontext. Wo dein Tooling es erlaubt, ziele auf die betroffenen Dateien.
- Mach Fehler lesbar. Der Agent behebt nur, was er lesen kann. Linter und Type-Checker mit klaren, verorteten Fehlermeldungen (
file:line: message) geben dem Modell genau das, was es braucht; ein generisches "build failed" tut das nicht.
Ein konkretes Vorher-Nachher
Ohne Schleife: Du bittest den Agenten, eine Funktion umzubenennen. Er aktualisiert drei Aufrufstellen, übersieht eine vierte in einer Datei, die er nicht geöffnet hat, und meldet "fertig". Eine Stunde später entdeckst du zur Laufzeit den kaputten Import.
Mit der Schleife: Dieselbe Umbenennung löst beim Speichern typecheck aus. tsc meldet Cannot find name 'oldFn' an der übersehenen Aufrufstelle. Dieser Fehler landet im Kontext, der Agent öffnet die vierte Datei, korrigiert die Referenz, und die nächste Prüfung läuft durch — alles, bevor er dir sagt, dass er fertig ist.
Die Erkenntnis
KI-Agenten sind gut darin, Code zu produzieren, und schlecht darin, zu bemerken, wenn er falsch ist. Du schließt diese Lücke, indem du ihnen dasselbe Signal gibst, auf das du dich verlässt: ein roter Test, ein Typfehler, eine fehlschlagende Lint-Regel — automatisch geliefert, direkt nach der Änderung. Beginne mit einer Zeile in deinen Projektanweisungen und befördere dann deine wichtigste Prüfung zu einem Hook, damit sie läuft, ob sich das Modell daran erinnert oder nicht. Die Agenten, die sich "schlau" anfühlen, sind meist einfach die, die in eine enge Feedback-Schleife verdrahtet sind.
SOURCES
Auto-generated by Vibe Coding Academy on June 19, 2026, grounded in the real sources linked above. We review for accuracy, but please verify time-sensitive details against the primary sources.
Build Blueprint · Creator
Hast du eine Idee? Hol dir die Spezifikation, aus der dein KI-Agent bauen kann.
Beschreibe ein beliebiges Produkt und erhalte einen vollständigen Build-Blueprint — Stack, Datenmodell, Bildschirme, APIs und einen einsatzbereiten Prompt für Claude Code oder Cursor. Als PDF exportieren.
Blueprint öffnen ▸