Cursor Agent in großen Projekten: 7 Methoden gegen fehlende Dateien und falsche Änderungen

Der dritte Fehler blinkt auf dem Bildschirm.

Gerade hatte ich den Cursor Agent gebeten, das Login-Modul zu refactoren – fünf Dateien: Frontend-Formular, API-Route, Auth-Middleware, User-Modell und Redis-Cache. Nach zwei Minuten meldete der Agent selbstbewusst: „Fertig.“ Code starten – und alles bricht zusammen.

Bei der Analyse: Vier Dateien gefunden, nur drei geändert. Schlimmer: Die Middleware-Logik war korrekt, wurde aber „optimiert“ – plötzlich lieferten alle Login-Requests 401. Eine halbe Stunde manuelles Rollback, Abhängigkeiten sortieren, den Rest selbst erledigen.

In dem Moment fragte ich mich: Kann ein KI-Programmierassistent wirklich große Projekte?

Zwei Wochen lang habe ich Cursor Agent untersucht, Dutzende Artikel gelesen und in echten Projekten experimentiert. Daraus ist ein Ansatz gewachsen, der in großen Codebasen deutlich zuverlässiger ist. Die Erfolgsrate beim Refactoring mit dem Agent stieg von unter 50 % auf über 90 %.

Dieser Artikel teilt sieben Praxistipps in drei Dimensionen: Kontextverwaltung, Aufgabenaufteilung und Code-Review. Keine Theorie – Erfahrung aus echten Projekten.

Warum Agent in großen Projekten scheitert

Bevor es an die Tipps geht: Warum passiert das? Nicht, weil der Agent „dumm“ ist – drei harte Grenzen spielen mit.

Kontext ist der größte Engpass

Selbst Modelle mit 200k Token reichen in der Praxis oft nicht. Ein mittelgroßes Frontend-Backend-Projekt hat leicht hunderte Dateien à mehrere hundert bis tausend Zeilen – plus package.json, Config, Tests. Das sprengt das Kontextlimit.

Der Agent „sieht“ nie das ganze Projekt. Er bekommt die im Chat genannten Dateien plus das, was Cursors Index noch verknüpft. Wie jemand, der nur fünf Meter weit sehen kann und auf einem Fußballplatz etwas suchen soll – Lücken sind normal.

In einem React+Node.js-Projekt: gleiche Aufgabe – kleines Projekt (20 Dateien) ca. 85 % Erfolg beim ersten Versuch, mittel (50 Dateien) ca. 60 %, groß (100+) nur noch ca. 35 %.

Die „Kurzsichtigkeit“ des Agents

Agenten übersehen besonders indirekte Abhängigkeiten.

Sie ändern eine API-Route und den Controller – aber der Controller ruft eine Utility-Funktion auf, die wiederum ein Config-Modul braucht. Oft bricht die Kette schon in der zweiten Ebene ab.

Dazu kommt Recency Bias: zuletzt geöffnete oder im Chat erwähnte Dateien – auch wenn sie irrelevant sind – werden mitbearbeitet. Wichtige Dateien, die Sie nicht nennen, bleiben unsichtbar.

Kein Gesamtüberblick

Das trifft am härtesten.

Entwickler denken vorher: Welche Module? Wie kommunizieren sie? Beeinflusst A auch B? Der Agent nicht. Er optimiert lokal – sucht im sichtbaren Bereich die plausibelste Lösung und legt los.

Extrembeispiel: Datenbankabfrage optimieren – Indizes, besseres SQL, spürbar schneller. Drei Tage später: Speicher voll. Ursache: „Optimierung“ im Cache mit Vollständigem Vorladen aller Daten – Redis am Limit.

Der Agent kennt keine Architektur-Intention. Performanceproblem → Performance-Fix, Duplikat → Extract Function – ohne Rücksicht auf das Gesamtdesign.

Drei Kerntipps zur Kontextverwaltung

Wenn Sie wissen, wo es hakt, können Sie steuern. Kontext ist entscheidend – wer den sichtbaren Bereich kontrolliert, vermeidet viele Fehler.

Tipp 1: Project Rules richtig konfigurieren

Viele laden alle Regeln im always-Modus – der größte Fehler.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

always heißt: bei jedem Chat alle Regeln laden. Frontend, Backend, Tests, Doku – jede mit eigenen Konventionen. Ein Drittel der Token ist weg, bevor der Agent anfängt.

Besser: Auto Attached + glob

Beispiel aus einem Frontend-Backend-Projekt:

# .cursorrules (Projektroot)

# Allgemeine Regeln (nur das Wichtigste)
- type: always
  rules:
    - TypeScript verwenden
    - ESLint-Konfiguration einhalten
    - Alle async-Operationen mit Fehlerbehandlung

# Frontend (nur bei Frontend-Dateien)
- type: auto
  glob: "src/frontend/**/*.{ts,tsx}"
  rules:
    - React Hooks verwenden
    - Komponenten mit PropTypes oder TypeScript-Typen
    - Tailwind CSS, keine Inline-Styles

# Backend
- type: auto
  glob: "src/backend/**/*.ts"
  rules:
    - API-Routen mit Input-Validierung
    - DB-Operationen in Transaktionen
    - Keine sensiblen Daten in Logs

# Tests
- type: auto
  glob: "**/*.test.ts"
  rules:
    - Jeder Test mit klarer Beschreibung
    - Jest describe/it-Struktur

Der Agent lädt Regeln nur bei Bedarf. In Tests: ca. 70 % weniger Token, weniger Ablenkung.

Praxis-Tipp: Am Ende einer Regel „Bei Unsicherheit zuerst nachfragen“ – der Agent fragt bei Grenzfällen nach statt zu raten.

Tipp 2: Long Context und Summarized Composers

Zwei unterschätzte Funktionen.

Long Context

Schalter für komplexe Aufgaben. Größeres Kontextfenster, mehr Code sichtbar.

Nicht dauerhaft an – hoher Token-Verbrauch, längere Antwortzeit. Meine Gewohnheit:

• Normal (Funktion, kleiner Bug): aus
• Komplex (Modul-Refactoring, Feature): an
• Sehr komplex (modulübergreifend): an + Schlüsseldateien per @

Summarized Composers

Zugriff auf Zusammenfassungen früherer Chats statt voller Historie – ideal für Langzeitprojekte.

Gestern Utility-Funktion gebaut, heute erweitern: „Die Funktion von gestern“ findet der Agent oft nicht. Mit Summarized Composers durchsucht er Summaries und findet den Kontext.

Mein Workflow: Nach jedem größeren Modul neuer Chat mit Satz wie „Projekt hat bereits XX unter XX/ implementiert.“ Historie nutzen, ohne von Details erdrückt zu werden.

Tipp 3: Kontext aktiv steuern

Am wichtigsten – und am leichtesten vergessen.

Verlassen Sie sich nicht darauf, dass der Agent alle Dateien findet. Sagen Sie, was er sehen und was er meiden soll.

Schlüsseldateien mit @

Refactor den User-Auth-Flow, betrifft diese Dateien:
@src/routes/auth.ts (Auth-Route)
@src/middleware/jwt.ts (JWT-Middleware)
@src/models/User.ts (User-Modell)
@src/utils/password.ts (Passwort-Hashing)

Keine anderen Dateien ändern.

„Keine anderen Dateien ändern“ senkt Fehländerungen von ca. 30 % auf unter 5 %.

Scope begrenzen

In src/frontend/components/auth/ eine Passwort-vergessen-Komponente hinzufügen,
keine anderen Verzeichnisse ändern.

Fortgeschritten: Whitelist + Blacklist

Erlaubt: alle Dateien unter src/api/**
Verboten: src/api/legacy/** (Legacy, wird abgelöst)

Gewohnheit: Vor jeder Aufgabe kurz „Wie viele Dateien höchstens? Welche Ordner?“ – und das dem Agent mitteilen. Wenig Aufwand, viel weniger Nacharbeit.

Zwei goldene Regeln für Aufgabenaufteilung

Kontext löst „nicht alles sehen“ – zu große Aufgaben scheitern trotzdem. Dann hilft Aufteilung.

Tipp 4: Nach Verantwortung, nicht nach Dateien

Mein größter Anfängerfehler.

User-Registrierung – so dachte ich:

1. Frontend-Formular
2. Backend-API
3. Datenbankmodell

Klingt logisch, scheitert in der Praxis:

• Frontend ohne API-Spec – raten
• Backend passt nicht zu Frontend-Parametern – zurück
• DB-Feld falsch – alles noch einmal

Richtig: nach Feature-Verantwortung

Schritt 1: Basis-Registrierung (Minimalversion)

Aufgabe 1: Minimale User-Registrierung
- Frontend: Formular nur Benutzername + Passwort
- Backend: Register-API + Basisvalidierung
- DB: User-Modell (Minimalfelder)
Ziel: End-to-End registrieren können

Schritt 2: Validierung und Sicherheit

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Aufgabe 2: Validierung und Sicherheit
- E-Mail-Format
- Passwortstärke
- Duplikat-Schutz
- Passwort gehasht speichern

Schritt 3: UX

Aufgabe 3: Registrierungs-UX
- Live-Validierung im Formular
- Auto-Login nach Registrierung
- Willkommens-E-Mail

Jede Aufgabe ist vertikal – Frontend, Backend, DB als abgeschlossener Punkt.

Vorteile:

1. Jede Aufgabe testbar – nach Aufgabe 1 läuft der Flow
2. Weniger Rework – Schnittstellen sofort sichtbar
3. Klares Ziel für den Agent

Erfolgsrate beim ersten Versuch: von ca. 60 % auf ca. 85 %.

Tipp 5: Klare Checkpoints setzen

Hat mich oft gerettet.

In großen Projekten: lange gearbeitet, Richtung falsch, kaum zurück. Der Agent fragt nicht „Soll ich vorher speichern?“ – und schon sind dutzende Dateien geändert.

Checkpoint-Funktion

Cursor Checkpoint ist stark unterschätzt.

Vor der Aufgabe:

# In Cursor: Cmd/Ctrl + Shift + P
# „Create Checkpoint“
# Notiz: vor Refactoring Login-Modul

Agent arbeitet. Bei Problemen: ein Klick zurück zum Checkpoint.

Gewohnheit:

• Neues großes Thema: Checkpoint
• Nach Agent: Tests OK → Checkpoint löschen; Fehler → Rollback
• Mehrere kleine Schritte: alle 2–3 Aufgaben ein Checkpoint

Maximaler Verlust: ein kleiner Arbeitsschritt.

Testgetriebene Entwicklung (TDD)

Noch einen Schritt weiter: erst Tests, dann Implementierung.

1. Tests schreiben (erwartetes Verhalten)
2. Tests laufen – rot (Feature fehlt)
3. Agent implementiert bis grün
4. Bleibt rot → Verständnis falsch, stoppen

Tests sind ein klares Stop-Kriterium. Kein endloses Driften – Ziel: Tests grün.

Auth-Modul in einem Node.js-Projekt: mit TDD sieben Durchläufe, ohne Abdrift. Ohne Tests über zehn Durchläufe mit Bugs.

Zwei Schlüsselpraktiken für Review und Monitoring

Alles oben reduziert Fehler – null ist unrealistisch. Review und Monitoring sind die letzte Linie.

Tipp 6: Mehrstufige Review-Standards

Missverständnis: Mit KI braucht man kein Code Review.

Gegenteil: wichtiger. Agent-Fehler sind oft subtil – Syntax OK, Logik plausibel, fachlich falsch.

Automatisches Review in Cursor Rules

# .cursorrules (Review-Teil)
code_review_rules:
  critical:
    - "Keine hardcodierten Passwörter, API-Keys o. Ä."
    - "DB mit parametrisierten Queries (SQL-Injection)"
    - "Externe Eingaben validieren und bereinigen"

  warning:
    - "Funktionen max. ca. 50 Zeilen, sonst aufteilen"
    - "any vermeiden, Typen explizit"
    - "Async mit try-catch oder .catch()"

  info:
    - "Unit-Tests erwägen"
    - "Komplexe Logik kommentieren"
    - "Duplikate extrahieren"

Nach jeder Aufgabe:

Aufgabe fertig. Prüfe den Code nach code_review_rules in .cursorrules
und liste alle critical- und warning-Punkte.

Oft findet der Agent eigene Fehler beim zweiten Blick.

Mensch + Agent

Nur Agent: unzuverlässig. Nur Zeile für Zeile: zu teuer. Stufen:

1. Agent-Vorprüfung: Syntax, Konventionen
2. Manuell, fokussiert:
   • Geschäftslogik
   • Randbedingungen
   • Performance (N+1, Leaks)
   • Sicherheit (SQLi, XSS)
3. Tests: nichts Bestehendes kaputt

Nicht jede Zeile – Kernlogik und Risiken, Rest Tools und Tests.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Ca. 15–20 % der Agent-Änderungen in großen Projekten haben Probleme:

• 5 % schwer (Logik, Sicherheit)
• 10 % Qualität (Performance, Wartbarkeit)
• 5 % läuft, widerspricht Konventionen

Ohne Review tauchen sie Wochen später mit hohen Kosten auf.

Tipp 7: Git als letzte Absicherung

Basis – wird oft ignoriert.

git diff nutzen

Nach dem Agent zuerst:

git diff

Welche Dateien, welche Änderungen? Ich prüfe:

• Umfang plausibel? (Dutzende Dateien → Alarm)
• Fremddateien?
• Kritische Logik angefasst?

Schnellüberblick:

git diff --stat

# Beispiel:
# src/api/auth.ts          | 25 +++++---
# src/models/User.ts       | 12 ++--
# src/utils/password.ts    |  3 +-
# src/config/database.ts   | 150 ++++++++++++++++++++++++++++++++++++++++++++++

150 neue Zeilen in database.ts, obwohl die Aufgabe das nicht verlangte – sofort nachsehen.

Checkpoint + Git

1. Vor der Aufgabe:
   - git checkout -b feature/xxx
   - Cursor Checkpoint

2. Nach dem Agent:
   - git diff
   - Tests
   - OK → git commit
   - Nicht OK:
     - klein: manuell oder gezielt Agent
     - groß: Checkpoint oder git reset --hard

3. Danach:
   - git push
   - Pull Request

• Checkpoint: schnelles Rollback
• Branch: Isolation vom main
• Commits: nachvollziehbare Historie

Gewohnheit: Commit-Message markieren:

git commit -m "feat: User-Registrierung (by AI Agent)"

Später sieht man sofort: hier war der Agent im Spiel – vorsichtiger debuggen.

Fazit

Zurück zur Szene um ein Uhr nachts.

Heute würde ich das Login-Modul so angehen:

1. Kontext: .cursorrules nur für Auth; @ für fünf Schlüsseldateien; „nur diese fünf Dateien“
2. Aufteilung: erst Basis-Login, dann Validierung, dann Cache
3. Review: nach jedem Schritt git diff, Tests, dann weiter

Ergebnis: fehlende Dateien von ca. 50 % auf unter 10 %; falsche Änderungen von ca. 30 % auf unter 5 %. Extra-Aufwand pro Aufgabe: etwa 5–10 Minuten.

KI-Programmierung ersetzt keine Architektur, kein Fachwissen, keine Qualitätsverantwortung. Richtig eingesetzt verdoppelt sie aber oft die Effizienz – wenn Sie den Agent führen.

Kontext, Aufteilung, Review – alle drei nötig. Kontext: der Agent sieht richtig. Aufteilung: er macht das Richtige. Review: Sie schlafen ruhiger.

Heute 10 Minuten: Project Rules prüfen, always durch auto + glob ersetzen – oft sofort spürbar weniger Token und bessere Ergebnisse.

Tools ändern sich; Prinzipien bleiben: klare Anforderungen, kleine Schritte, kontinuierlich prüfen. Gilt für KI und jedes komplexe Projekt.

Welche Fallen sind Ihnen mit Cursor Agent passiert? Teilen Sie gern in den Kommentaren.