AI Coding Workflow: Wie man wiederholte KI-Code-Änderungen reduziert

Plan → Scoped Edit → Verify / Cursor Rules / kleine Diffs / Abnahme-Checkliste / Endlosschleifen-Diagnose

Wenn Sie mit Cursor, Claude Code oder Copilot Workspace Features bauen, kennen Sie vielleicht diesen Abend: Die KI ändert Datei A, Tests schlagen fehl; Sie reparieren B, A ist wieder kaputt; Sie sagen „versuch nochmal“, und plötzlich ist auch der gestern noch laufende Code weg. Das liegt nicht daran, dass das Modell „nicht schlau genug“ ist — es fehlt ein wiederholbarer AI Coding Workflow, der Planung, Änderungsumfang und Abnahme in getrennte Phasen teilt. Ohne diese Struktur dreht der Agent endlos auf derselben falschen Annahme.

Dieser Artikel beschreibt einen 2026 in Teams erprobten Ablauf: erst Planen, dann gezielt ändern, und erst nach Verify weitergehen. Zusammen mit Cursor Rules und kleinen Git-Commits haben wir „denselben Bug 8 Mal fixen“ auf höchstens 2 Runden reduziert. Wenn Sie parallel einen MCP Server auf einem Cloud Mac aufsetzen oder Open-Source-AI-Agent-Projekte auf GitHub evaluieren, gilt derselbe Workflow.

Warum gerät die KI in eine Endlosschleife?

Agent-Modus bedeutet im Kern: in einer unsicheren Umgebung trial-and-error. Wenn Sie nur sagen „beheb den Login-Bug“, weiß das Modell nicht, ob OAuth-Callback, Session-Ablauf oder Frontend-Routing gemeint ist — es rät die plausibelste Antwort, testet, scheitert und probiert eine andere Richtung. Jede Runde wirft Teile der vorherigen Annahme um, der Diff wächst, der Kontext füllt sich mit widersprüchlichen Änderungen — und Sie landen im Zustand „je mehr wir patchen, desto schlimmer“.

Drei Grundursachen

• Unklares Ziel — ohne Definition von „Erfolg sieht so aus“ muss die KI aus Testfehlern rückwärts schließen; Fehlermeldungen zeigen oft Symptome, nicht die Wurzel
• Entgleister Umfang — eine Aufgabe über 10+ Dateien, beim Auth-Fix wird nebenbei utils refactored, neue Regressionen entstehen
• Kein Abnahme-Gate — ohne harte Regel „nur weiter bei Grün“ ist die Standardreaktion auf Fehlschlag „noch eine Version generieren“ statt „zurückrollen und Umfang neu festlegen“

Faustregel: Wenn Sie drei Runden hintereinander „nein, nochmal“ sagen, liegt das Problem nicht am Modell, sondern daran, dass die Aufgabe nicht neu geplant wurde.

Drei-Phasen-Workflow: Plan → Scoped Edit → Verify

Jede KI-Session in drei nicht überspringbare Phasen zu teilen, wirkt oft stärker als ein Modell-Upgrade:

1. Plan (Planung) — im Plan-Modus oder rein im Dialog: betroffene Dateien, Tabus und Abnahmebefehle (z. B. npm test -- auth) auflisten. Ergebnis: eine einfügbare „Aufgabenspezifikation“; nicht sofort den Agent losschicken, sondern die Spec bestätigen
2. Scoped Edit (begrenzte Änderung) — explizit schreiben: „nur src/auth/login.ts ändern, andere Dateien tabu“. Pro Runde: 1–3 Dateien, <200 Zeilen Nettoänderung
3. Verify (Abnahme) — Tests, Lint, manueller Smoke-Test. Grün → committen und nächste Aufgabe; rot → mit vollständigem Fehlerlog zurück zu Plan, nicht „versuch nochmal“

Prompt-Struktur: Ziel, Grenzen und Abnahme auf einmal klären

Kopierbare Vorlage (Klammern durch Ihr Projekt ersetzen):

## Ziel
(Ein Satz: Nutzer klickt Login, innerhalb von 3 Sekunden im Dashboard)

## Umfang
- Nur ändern: src/auth/login.ts, src/auth/session.ts
- Tabu: Routing, Styles, andere Module

## Abnahme
- npm test -- --grep "login"
- Manuell: Falsches Passwort zeigt „Benutzername oder Passwort falsch“, ohne zu verraten ob der Account existiert

## Kontext
- Aktueller Fehler: (vollständigen Stack Trace einfügen)
- Konventionen: Session in Redis, siehe docs/auth.md

Diese Struktur entspricht dem, was Anthropics Claude-Code-Best-Practices als „klare Grenzen“ betonen — das Modell muss nicht raten, und die Regressionsfläche bleibt kontrollierbar.

Rules / Skills: Projektregeln ins Repository schreiben

Bei jedem Chat „wir nutzen pnpm, keine Class Components, Tests in __tests__“ zu wiederholen, kostet Token und führt zu inkonsistentem Verhalten. Schreiben Sie Konventionen in .cursor/rules oder projektweites AGENTS.md:

Rules (Regeln)

Dauerhafte Constraints: Namensstil, verbotene Muster, Pflichtbefehle vor dem Commit. Cursor injiziert sie bei jedem Agent-Aufruf.

Skills (Fähigkeiten)

Wiederverwendbare Ablauf-Skripte, z. B. Checkliste „neuen API-Endpunkt hinzufügen“. Weniger Neuentdeckung der Projektstruktur bei jeder Aufgabe.

User Rules vs. Project Rules

Persönliche Präferenzen (z. B. „Antworten auf Deutsch“) in User Rules; Teamkonsens (z. B. „Backend nur auf Anfrage ändern“) in Project Rules — wichtig für Zusammenarbeit.

Siehe Cursor Skills Dokumentation: Wenn häufige Abläufe festgeschrieben sind, sinkt die Zahl wiederholter Fehler derselben Art deutlich.

Kleine Diffs und Git-Disziplin

KI kann große Codeblöcke auf einmal erzeugen — Menschen reviewen große Diffs aber schlecht. Empfehlung:

• Ein Agent-Task = ein Commit — Message mit Plan-Zusammenfassung, damit git revert einfach bleibt
• Bei Chaos resetten — nicht weiter auf einem riesigen Diff patchen; git checkout -- . zum letzten grünen Punkt, dann kleinerer Umfang
• Branches für Experimente — besonders auf Cloud Mac oder in CI: git worktree oder eigener Branch isoliert „KI-Wildwuchs“

Kontextmanagement: Den Agent nicht im Datei-Meer ertrinken lassen

Das ganze Monorepo an den Agent zu geben, ist wie Signal in Rauschen suchen. Besser:

1. Mit @filename genau 3–5 relevante Dateien referenzieren, nicht „ganzes Projekt scannen“
2. Große Refactorings in mehrere Plans teilen: erst Interface, dann Implementierung, dann Tests — jeweils mit Verify
3. Ab 15+ Runden: neuen Chat mit „Spec + aktueller Stand“ statt mit historischem Ballast weiterarbeiten

Vier typische Endlosschleifen und Auswege

Wenn Sie komplexe Agent-Pipelines orchestrieren (z. B. Batch-Dokumente oder MCP-Toolketten), entspricht das Muster „Routen → Ausführen → Prüfen“ dem, was wir bei der PDF-Batch-Erkennung als Routing-Architektur beschreiben: erst entscheiden, dann handeln — nicht jede Aufgabe über den langsamsten, fehleranfälligsten Pfad.

Häufige Fragen

1. Hilft ein stärkeres Modell? — Stärkere Modelle reduzieren Syntaxfehler, aber Umfangskontroll-Probleme und Regressionen hängen kaum vom Modell-Tier ab; der Workflow ist entscheidend
2. Wie vereinheitlicht man im Team? — Rules, PR-Vorlagen und Abnahme-Checklisten ins Repo; beim Code Review prüfen: „kleine Commits?“
3. Kann man alles dem Agent überlassen? — Ausführung ja, aber Plan und Verify sollten menschliche Gates bleiben — besonders bei Zahlung, Auth und Migrationen
4. Wie passt das zu TDD? — Erst fehlschlagenden Test (Plan), dann Implementierung (Scoped Edit), grün dann refactor — passt natürlich zu den drei Phasen

Zurück zur Frage: wiederholte KI-Code-Änderungen reduzieren gelingt nicht durch „noch ein Versuch“, sondern durch die Disziplin Plan → Scoped Edit → Verify, klare Prompts, Rules im Repo und den Mut zu git revert. Wenn der Ablauf sitzt, verbringen Sie Zeit mit Problemanalyse — nicht mit dem N-ten Patch.