KI-gestützter Entwicklungs-Workflow: Claude, Cursor und die Grenzen der Automatisierung

Jeder Entwickler hat heute einen KI-Pair-Programmer auf Abruf. Die Frage ist nicht mehr, ob man ihn nutzt, sondern wie man ihn integriert, ohne technische Schulden schneller anzuhäufen, als die KI Code erzeugt. In diesem Beitrag geht es um den Workflow, auf den ich mich nach einem Jahr mit Claude und Cursor in Produktionsprojekten festgelegt habe.

Die grundlegende Spannung

KI-Modelle sind exzellent darin, plausibel aussehenden Code zu erzeugen. Sie sind schlecht darin, Ihre spezifischen Rahmenbedingungen zu verstehen: die Konventionen Ihres Teams, den Stolperstein, den Sie vor drei Monaten eingebaut haben, die Drittanbieter-Bibliothek mit dem undokumentierten Breaking Change. Die Aufgabe des Entwicklers hat sich verschoben — vom Schreiben von Boilerplate hin zum Bereitstellen von Kontext und Bewerten von Ergebnissen.

Das ist keine Warnung, KI seltener zu nutzen. Es ist ein Anstoß, sie anders zu nutzen.

Rollen der Werkzeuge

Ich behandle die beiden Tools als Werkzeuge mit unterschiedlichem Zweck:

Claude (in Claude Code / API) ist für Denkaufgaben — Architekturentscheidungen, das Debuggen einer subtilen Race Condition, das Reviewen eines PR auf Korrektheit, das Erklären, warum ein Stück Code tut, was es tut. Es arbeitet auf dem Gesprächskontext und kommt mit Mehrdeutigkeit gut zurecht.

Cursor ist für Code-Generierung innerhalb einer bestimmten Datei oder eines Moduls — das Implementieren einer Funktion, deren Schnittstelle bereits definiert ist, das Umstellen einer Komponente auf eine neue API, das Schreiben von Tests für eine bestehende Funktion. Es funktioniert am besten, wenn der umgebende Code im Kontext sichtbar ist.

Keines der Werkzeuge ersetzt das Design-Denken. Beide ersetzen das Tippen.

Kontext ist der Engpass

Die wichtigste Fähigkeit bei KI-gestützter Entwicklung ist das Schreiben wirksamen Kontexts. Ein vager Prompt erzeugt vagen Code:

❌ "Füge dem Blog Pagination hinzu"

✅ "Füge getMdxPosts() in lib/mdx.ts cursor-basierte Pagination hinzu.
   Die Funktion gibt aktuell alle Posts nach Datum absteigend zurück.
   Params: { cursor?: string; limit: number }.
   Rückgabe: { posts: BlogPost[]; nextCursor: string | null }.
   Der Cursor ist der Post-Slug des letzten Elements der vorherigen Seite."

Der zweite Prompt nennt die Datei, das aktuelle Verhalten, die Schnittstelle und den Rückgabe-Vertrag. Das Modell erzeugt etwas, das zur bestehenden Codebasis passt, statt einer generischen Pagination-Implementierung.

CLAUDE.md als dauerhafter Kontext

Eine der nützlichsten Funktionen von Claude Code ist die CLAUDE.md-Datei — projektweite Anweisungen, die in jede Session eingespeist werden. Ich nutze sie, um Dinge zu dokumentieren, die das Modell nicht aus dem Code ableiten kann:

## Teststrategie
Unit-Tests mocken Prisma via vi.mock() in __tests__/setup.ts — dieses Muster nicht ändern.
Niemals den Datenbank-Adapter mocken; den echten Prisma-Client gegen eine Test-Datenbank nutzen.

## API-Routen
Alle API-Routen brauchen Rate-Limiting via lib/rate-limit.ts.
logger.ts (Pino) verwenden, nicht console.log.

## Komponenten-Muster
UI-Komponenten folgen shadcn/ui-Mustern mit CVA für Varianten.
markdown

Das verhindert, dass das Modell „hilfsbereit" Ihr Test-Setup umstrukturiert oder console.log in den Produktionscode einführt.

Workflow für ein Feature

So durchläuft ein typisches Feature die Werkzeugkette:

1. Im Gespräch entwerfen

Bevor Sie Code anfassen, beschreiben Sie das Feature Claude und diskutieren Sie den Ansatz:

"Ich muss einen Newsletter-Anmelde-Endpoint hinzufügen. Wir nutzen Resend für E-Mail.
Der Endpoint soll: das E-Mail-Format validieren, via Prisma auf Duplikate prüfen,
eine Willkommens-E-Mail senden und eine rate-limit-bewusste Antwort zurückgeben.
Was ist die einfachste Implementierung, die zum bestehenden api/-Muster passt?"

Das bringt Architekturentscheidungen zutage — wo das Rate-Limiting sitzt, wie Fehlerantworten aussehen — bevor sie im Code festgeschrieben sind.

2. Mit Cursor generieren

Sobald die Schnittstelle klar ist, nutzen Sie Cursors Inline-Generierung zur Umsetzung. Der umgebende Datei-Kontext (bestehende Routen) gibt den Stil vor.

3. Das Ergebnis kritisch prüfen

KI-generierter Code hat vorhersagbare Schwachstellen:

• Over-Engineering: Abstraktionen, die durch die aktuellen Anforderungen nicht gerechtfertigt sind
• Fehlende Fehlerbehandlung an den Rändern: gute interne Logik, schwache Validierung am Rand
• Optimistische Nebenläufigkeit: keine Berücksichtigung von Race Conditions (zwei gleichzeitig anmeldende Nutzer)
• Halluzinierte APIs: Funktionen, die richtig aussehen, in der installierten Version aber nicht existieren

Lesen Sie das Ergebnis wie den PR eines Junior-Entwicklers. Übernehmen Sie die korrekten Teile, schreiben Sie den Rest neu.

4. Die Tests selbst schreiben

Tests sind die Spezifikation. Sie selbst zu schreiben zwingt Sie, Randfälle durchzudenken, die die KI nicht berücksichtigt hat. Nutzen Sie KI, um das Test-Gerüst zu erzeugen (describe-Blöcke, Mock-Setup), aber schreiben Sie die Assertions von Hand.

Wann man KI nicht nutzen sollte

Manche Aufgaben sind mit KI-Unterstützung sogar langsamer:

Debugging von Produktionsproblemen — Das Modell hat nicht Ihre Logs, Ihre echten Daten oder Ihre Infrastruktur. Es schlägt plausibel klingende Fixes vor, die die Ursache nicht treffen. Nutzen Sie zuerst Observability-Tools.

Sicherheitskritischer Code — Auth-Logik, Eingabe-Sanitisierung, Kryptografie. KI macht das auf subtile Weise falsch, die das Code-Review übersteht. Schreiben Sie das von Grund auf und lassen Sie es auditieren.

Dateiübergreifendes Refactoring — Das Kontextfenster des Modells begrenzt seinen Blick auf Abhängigkeiten. Große Refactorings plant man besser im Gespräch und führt sie dann manuell oder mit einem eigens gebauten Skript aus.

Den tatsächlichen Geschwindigkeitsgewinn messen

Anekdotisch: Routine-Implementierungen (CRUD-Endpoints, Formular-Komponenten, Utility-Funktionen) sind 3–4× schneller. Architektur und Debugging sind etwa gleich schnell — die Planungszeit dominiert.

Der größere Gewinn ist psychologisch. Die Kosten, einen Ansatz auszuprobieren, sinken gegen null. Sie können in der Zeit, die früher eine Implementierung kostete, drei verschiedene prototypisieren, sie vergleichen und die schwächeren zwei verwerfen. Das verändert, wie Sie Design-Entscheidungen treffen.

Fazit

Die wirksamsten KI-gestützten Entwickler, die ich gesehen habe, teilen ein Muster: Sie verbringen mehr Zeit mit Kontext und Review, nicht weniger. Das Modell übernimmt die Synthese; der Entwickler übernimmt das Urteil. Der Workflow, der den meisten Wert herausholt, ist einer, in dem Sie jederzeit genau wissen, welche dieser beiden Aufgaben Sie gerade erledigen.