Claude Code ändert die falschen Dateien: Ursachen & Schutz

Diese Seite erklärt, warum solche Abweichungen passieren, wie du dich mit vier Schutzebenen dagegen absicherst - und was zu tun ist, wenn es schon passiert ist.

Das Symptom: Wenn der Agent über den Auftrag hinausgeht

Typische Beispiele aus der Praxis:

• Eine Komponente sollte angepasst werden - stattdessen wurden auch drei benachbarte Dateien „konsistent" gemacht.
• Eine Konfigurationsdatei wurde „optimiert", obwohl sie nicht Teil des Auftrags war.
• Variablennamen wurden projektweit umbenannt, weil der Agent eine Inkonsistenz entdeckt hat.
• Eine Datei im Bereich Zahlung, Login oder Tracking wurde berührt, obwohl der Auftrag davon nichts sagte.

Jedes dieser Beispiele klingt für sich genommen harmlos oder sogar hilfreich. Das eigentliche Problem ist nicht die einzelne Änderung, sondern dass sie nicht Teil einer bewussten Entscheidung war.

Warum das passiert

Coding-Agenten arbeiten mit dem, was sie im Kontext sehen - und ohne explizite Grenze ist für sie das ganze Repository potenziell relevant. Die häufigsten Ursachen:

• Der Auftrag beschreibt ein Ziel, aber keinen Dateibereich.
• Es gibt keine dauerhaft hinterlegten Schutzbereiche in einer Projektdatei.
• Formulierungen wie „räum dabei gleich mit auf" laden aktiv zu Scope-Ausweitung ein.
• Der Diff wird vor dem Merge nicht vollständig gelesen, sondern nur überflogen.
• Bei mehreren parallelen Agenten fehlt eine klare Aufteilung, wer welchen Bereich bearbeiten darf.

Keiner dieser Punkte ist ein Fehler des Werkzeugs - es sind fehlende Leitplanken.

Die vier Schutzebenen

Vier Ebenen wirken zusammen. Keine davon reicht allein, aber gemeinsam senken sie das Risiko deutlich.

1. Prompt-Ebene

Jeder Auftrag benennt explizit den erlaubten Bereich, etwa „nur innerhalb von src/components/bezahlformular/", und eine kurze „nicht anfassen"-Liste für den konkreten Fall.

2. Projekt-Ebene (CLAUDE.md / AGENTS.md)

Wiederkehrende Schutzbereiche gehören nicht in jeden einzelnen Prompt, sondern dauerhaft in die Projektdatei, die der Agent ohnehin liest. Wie diese Datei sauber von temporärem Aufgabenkontext getrennt bleibt, erklärt AGENTS.md, CLAUDE.md und PROJECT_CONTEXT.md.

3. Diff-Ebene

Vor dem Merge wird die Liste der geänderten Dateien gegen den Auftrag gehalten, nicht nur der Inhalt der erwarteten Datei. Eine ausführliche Routine dafür steht in der Merge-Checkliste für AI-generierten Code.

4. Git-Ebene

Ein eigener Branch pro Aufgabe, kleine Commits und ein main-Branch, der jederzeit sauber bleibt, machen ein Zurücksetzen billig. Diese Ebene greift, wenn die ersten drei versagt haben - sie ist das Sicherheitsnetz, nicht die erste Verteidigungslinie.

Checkliste: Schutzbereiche definieren

Diese Liste deckt die Bereiche ab, die in den meisten Projekten unabhängig vom Einzelfall geschützt gehören. Ergänze projektspezifische Punkte.

SCHUTZBEREICHE - Startpunkt

[ ] Zahlung / Stripe / Preislogik
[ ] Authentifizierung / Login / Sessions
[ ] Datenbank-Migrationen und -Schemas
[ ] Tracking, Analytics, Consent-Logik
[ ] Rechtstexte (Impressum, Datenschutz, AGB)
[ ] CI/CD-Konfiguration und Deploy-Skripte
[ ] Secrets, .env, API-Schlüssel
[ ] Design-System-Basisdateien (globale Styles, Tokens)
[ ] Öffentliche API-Verträge / Schnittstellen zu Dritten

Diese Liste gehört in die Projektdatei, nicht in jeden einzelnen Auftrag - siehe AGENTS.md, CLAUDE.md und PROJECT_CONTEXT.md.

Was tun, wenn es schon passiert ist

• Ruhig bleiben und den Diff vollständig lesen, statt sofort alles zu verwerfen.
• Betroffene Dateien einzeln identifizieren - meist ist nur ein Teil der Änderung ungewollt.
• Gezielt zurücksetzen, statt den gesamten Branch zu löschen.
• Prüfen, ob unter den ungewollten Änderungen ein Schutzbereich betroffen war - falls ja, zusätzlich manuell verifizieren.
• Den nächsten Auftrag mit einer klareren Grenze und einer expliziten „nicht anfassen"-Liste versehen.

Ein ganzer verworfener Branch kostet oft mehr echte Arbeit, als eine gezielte Korrektur gekostet hätte - besonders wenn ein Großteil der Änderung tatsächlich richtig war.

Typische Fehler, die das Problem verschlimmern

• Den kompletten Branch verwerfen, obwohl nur eine Datei betroffen war.
• Dem Agenten „räum das auf" sagen, ohne einen Bereich zu benennen.
• Denselben ungenauen Auftragstyp beim nächsten Mal wiederholen.
• Keine Schutzbereiche dauerhaft dokumentieren, sondern jedes Mal neu improvisieren.
• Bei mehreren parallelen Agenten keine Bereichsaufteilung festlegen.

Was diese Seite nicht verspricht

Die vier Schutzebenen senken das Risiko spürbar, sie schließen es nicht vollständig aus. Kein Prompt und keine Projektdatei ersetzt einen Blick in den tatsächlichen Diff vor dem Merge. Diese Seite bewertet außerdem keine einzelne Modellversion und verspricht nicht, dass sich das Verhalten eines Agenten nie ändert - sie beschreibt ein Vorgehen, das unabhängig vom eingesetzten Werkzeug funktioniert.