Cursor und Claude Code verbinden sich per MCP mit CodeGraph für Vue- und Spring-Boot-Ketten

API mit Cursor oder Claude Code geändert, Backend gemergt, Frontend vergessen — kommt oft vor. Dieser Beitrag beantwortet nur drei Fragen: warum etwas fehlt, wie man den Fall OrderDTO erkennt, wie CodeGraph hilft. Stack: Vue 3 + Spring Boot getrennt; Tool: CodeGraph über MCP.

Kurz: Vor Änderung an OrderDTO.amount codegraph_impact ausführen — listet Java-Service, Vue createOrder und Pinia-Store in einem Durchgang; genau die Schicht, die Agents oft überspringen.

Warum Cursor das Frontend übersieht

Fehlende Dateien sind selten „das Modell kann nicht coden“. AI Coding sieht quellobergreifende, sprachübergreifende Referenzen schlecht. Bei Vue + Spring Boot reichen meist drei Ursachen:

1. Kontextfenster: nur die geöffnete Datei

Cursor-@-Dateien und Claude Code-Read sind begrenzt. Der Agent starrt auf OrderController.java und erfährt nicht, dass frontend/src/api/order.ts dasselbe DTO-Feld nutzt. Neuer Chat, neuer Branch — „was wir schon geändert haben“ geht verloren (schlimmer mit Cursor-Vergessen über Wochen).

2. grep: Text ja, Aufrufketten nein

Exploration läuft über grep. Suche nach amount liefert Logs, Tests, tote Konstanten — nicht, wer OrderService.createOrder aufruft oder welcher @PostMapping-Handler zuständig ist. Tokens fließen in „Einstieg finden“, nicht in „vollständige Blast Radius“.

3. Kein Impact: eine Datei fix, zehn verwaist

Menschen fragen: wenn ich dieses Feld ändere, was bricht sonst? Ohne strukturierten impact endet der Agent nach Java; TypeScript, Pinia, Tests wandern in eine Runde, die Sie nie planen — ein Chat wirkt fertig, Sie haben zwei Runden Schulden.

Es braucht nicht immer ein größeres Modell, sondern abfragbare Aufrufgraphen, Kanten, Routen-Einstiege. Das Order-API-Beispiel zeigt es.

Praxis: OrderDTO.amount

Aufgabe: bei POST /api/orders amount von number auf string (z. B. große Beträge oder formatierte Strings). Repo: backend/ (Controller → Service → OrderDTO), frontend/ (api/order.ts → Pinia → Checkout).

Ohne CodeGraph: was Cursor / Claude Code oft übersieht

Nur Geschäftsbeschreibung, keine @-Dateien. Typisches Ergebnis:

  • ✅ OrderDTO.java, OrderService angepasst
  • ❌ Payload-Typen in frontend/src/api/order.ts für createOrder
  • ❌ useOrderStore-Mapping für amount
  • ❌ Checkout-v-model noch numerische Validierung

mvn compile kann grün sein, pnpm build manchmal auch — erst Integration oder Produktion bricht. Das ist „API geändert, Frontend vergessen“.

Gegenüberstellung: impact-Liste (Auszug)

codegraph_impact
  symbol: "OrderDTO.amount"

→ OrderService.createOrder
→ OrderController.create
→ frontend/src/api/order.ts :: createOrder
→ stores/order.ts :: useOrderStore

Die letzte Zeile ist die Pinia-Schicht, die grep früher am häufigsten verpasste. Gegen die Liste in Cursor / Claude Code arbeiten senkt die Fehlquote.

So findet CodeGraph die Auswirkungen

CodeGraph indexiert lokal per Tree-sitter (Java / TS / Vue script), speichert Aufrufkanten in .codegraph/, stellt codegraph_* über MCP bereit. Daten bleiben standardmäßig auf der Maschine — gut für private Repos.

Für diese Order-API feste Reihenfolge:

  1. codegraph_context — Controller, DTO, Frontend-API-Einstieg als Task-Paket (ohne vorher Pfade per @ anzugeben)
  2. codegraph_trace — Spring: OrderController.create → OrderMapper.insert
  3. codegraph_impact — von OrderDTO.amount zu Java + Vue + Store
  4. codegraph_explore — nur relevante Methoden, kein 800-Zeilen-Service-Dump

Fehlen symbol-Kanten zwischen HTTP-Pfad und axios-Strings, reicht impact vom DTO zum Frontend — der „besser als erwartet“-Schritt hier. Tool-Vergleich: Code-Wissensgraph-Auswahl; Installation unten.

In AGENTS.md festhalten: vor DTO-Änderung codegraph_impact, frontend/src/api und Pinia auflisten — zuverlässiger als „Frontend nicht vergessen“.

Installation (~5 Min.)

Im Repo-Root mit frontend/ + backend/ (macOS):

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# oder: npx @colbymchenry/codegraph

codegraph install --target=cursor --yes
cd /path/to/your-repo
codegraph init -i
codegraph status

Erster Vollindex: je nach Größe ca. 10–20 Min.; node_modules, target, dist ausschließen. Speichern debounced ~2s inkrementell; bei ⚠️ Pending sync Quelle per Read nachziehen.

Vergleich

AnsatzTool-Aufrufe (gleiche Aufgabe, informal)Frontend auf der Liste?
nur grep + Read~15+Pinia / API oft fehlend
CodeGraph MCP zuerst~5–6impact listet Front und Back

Offizieller Java-Benchmark (OkHttp ~645 Dateien): Median 10→3 (2026-05-29). Vue + Spring fühlte sich ähnlich an. Graph ersetzt keine Tests — vor Merge mvn test + pnpm test:unit.

Indexierung bei großen Repos

Erster codegraph index: hohe CPU, SQLite-Schreiblast, Lüfter — parallel IDEA für Spring und pnpm build für Vue, und selbst Cursor-MCP wird träge.

Viele Teams legen Klon + Vollindex + geplante Rebuilds auf Mac mini, CI oder Cloud Mac; das Notebook nur für Code und MCP. Ich indexiere auf einem tageweise gemieteten Macstripe-M4, versetzt zum lokalen Build; Worktree: Enterprise-Mac-CI-FAQ.

„CodeGraph auf Cloud Mac“ verdient einen eigenen Artikel — hier nur: Indexierung und Interaktion trennen stabilisiert die Erfahrung.

Fazit

Cursor übersieht beim API-Ändern oft das Frontend, weil Kontext begrenzt + grep ohne Aufrufe + kein impact zusammenwirken. Mit CodeGraph-MCP context → trace → impact rücken DTO-Änderungen Front und Back in eine Liste; Exploration sinkt von vielen grep-Runden auf wenige strukturierte Abfragen.

Fester Ablauf: init → impact (vor DTO) → Liste abarbeiten → Tests. Konzeptposts, Claude Code auf riesigen Repos, Cloud-Mac-Deployment als Serie — Links unten.

Weiterlesen