Wie ich Claude Code und Cursor nutze, um die Full-Stack-Entwicklung zu beschleunigen

In letzter Zeit werde ich das oft gefragt: „Lassen Sie den Code tatsächlich von KI schreiben?“ Die kurze Antwort ist ja: Claude Code und Cursor gehören in echten Kundenprojekten zu meinem täglichen Workflow. Die längere Antwort ist nützlicher, denn wie man diese Tools einsetzt, entscheidet darüber, ob man schneller ausliefert oder schneller Chaos produziert.

Dieser Beitrag ist ein praxisnaher Blick darauf, wo mir diese Tools bei der Full-Stack-Arbeit wirklich Zeit sparen, wo nicht, und wie ich das Ergebnis auf einem Qualitätsniveau halte, für das ich gern mit meinem Namen einstehe.

Zwei Tools, zwei Aufgaben

Viele werfen alle „KI-Coding-Tools“ in einen Topf, aber ich nutze sie für unterschiedliche Dinge.

• Cursor lebt im Editor. Es ist hervorragend für schnelle Änderungen im Kontext: eine Komponente refaktorieren, eine Funktion schreiben, während ich zusehe, die offensichtlichen nächsten Zeilen vervollständigen. Es hat auch einen eigenen Agent-Modus für größere Änderungen, aber seine Stärke liegt für mich dort, wo ich im Flow bin und darin bleiben möchte.
• Claude Code arbeitet auf Projektebene. Ich nutze es meist im Terminal (es gibt auch IDE-Erweiterungen, eine Desktop-App und eine Web-Version). Ich setze es für größere Aufgaben über mehrere Dateien ein, etwa „Binde diesen neuen Endpunkt durch Service, Controller und Typen hindurch an“ oder „Finde jede Stelle, an der diese alte API aufgerufen wird, und aktualisiere sie“. Es kann eine ganze Änderung besser im Blick behalten.

Keines der beiden ersetzt das Verständnis der Codebasis. Sie machen mich schneller bei Dingen, die ich ohnehin schon kann.

Beide Tools können inzwischen auch Agents im Hintergrund oder in der Cloud laufen lassen und einen fertigen Branch oder Pull Request zurückgeben. Das ist praktisch für klar umrissene Routineaufgaben, erhöht aber die Anforderungen an das Review: Je weniger ich von der Arbeit selbst mitverfolgt habe, desto sorgfältiger lese ich das Ergebnis.

Das geschäftliche Problem: Entwicklerzeit ist Ihre teuerste Ressource

Wenn Sie für eine Entwicklung bezahlen, bezahlen Sie in Wahrheit Stunden. Alles, was aus einer einstündigen Aufgabe eine fünfzehnminütige macht, ohne die Qualität zu senken, senkt direkt Ihre Kosten und verkürzt Ihren Zeitplan.

Der Haken liegt im Teil „ohne die Qualität zu senken“. KI-Tools können Code erzeugen, der fertig aussieht, es aber nicht ist. Die eigentliche Fähigkeit ist also nicht das Tippen von Prompts. Sie besteht darin zu wissen, welche Arbeit man delegiert, und das Ergebnis so zu prüfen wie den Pull Request eines Junior-Entwicklers.

Wo mir diese Tools wirklich Zeit sparen

Boilerplate und Infrastruktur

Jedes Full-Stack-Feature hat eine vorhersehbare Hülle: einen typisierten Endpunkt, Validierung der Anfrage, eine Datenbankabfrage, das passende Frontend-Formular, Lade- und Fehlerzustände. Das ist notwendige, aber wenig spannende Arbeit, und hier bringt KI den größten und sichersten Geschwindigkeitsgewinn. Ich beschreibe die Form, das Tool erstellt einen Entwurf, ich prüfe und passe an.

Repetitive, mechanische Änderungen

Einen Begriff über vierzig Dateien hinweg umbenennen, nach einer API-Änderung jede Aufrufstelle aktualisieren, einen Stapel Komponenten auf ein neues Muster umstellen. Von Hand ist das mühsam und fehleranfällig. Claude Code erledigt es schnell und konsistent, und ich prüfe den Diff, bevor ich ihn übernehme.

Tests, die ich sonst weglassen würde

Unter Zeitdruck fallen Tests als Erstes weg. KI macht es günstig, genau die Fälle zu schreiben, die ich sonst auslassen würde: die leere Liste, das abgelaufene Token, die doppelte Übermittlung. Mehr Abdeckung bei weniger Aufwand ist ein klarer Gewinn.

Fremden Code verstehen

Wenn ich in ein bestehendes Projekt einsteige, kann ich Claude Code bitten zu erklären, wie ein Teilsystem zusammenhängt, statt jede Datei unvorbereitet zu lesen. Das ist ein schnellerer Einstieg, und ich überprüfe trotzdem, was es mir sagt.

Wo ich mich nicht auf sie verlasse

Die Grenze, die ich für mich gezogen habe, hat eigentlich nichts mit dem Tool zu tun. Es sind zwei Fragen: Wie leicht lässt sich diese Änderung rückgängig machen, und kann ich beweisen, dass sie korrekt ist? Ist etwas günstig zurückzunehmen und leicht mit Tests zu verifizieren, lasse ich die KI gern viel davon erledigen. Schafft es langlebige Einschränkungen, ist die KI höchstens Entwurfsschreiber, und die endgültige Entscheidung bleibt bei mir.

• Architektur und Datenmodellierung. Diese Entscheidungen wirken sich langfristig aus. Ich treffe sie selbst und nutze KI nur, um die Optionen auf die Probe zu stellen. Ein Schema, das gut aussieht und in dreißig Sekunden generiert ist, kann Sie Wochen später einholen.
• Alles Sicherheitsrelevante. Authentifizierung, Berechtigungen, Zahlungsabläufe, Mandantentrennung. Das schreibe und prüfe ich sorgfältig. KI erzeugt bereitwillig einen Endpunkt ganz ohne Berechtigungsprüfung.
• Subtile Geschäftslogik. Wenn die Regeln ungewöhnlich sind oder echtes Geld daran hängt, soll ein Mensch die Details vollständig in der Hand haben.
• Fehlerbehandlung. Der Erfolgsfall wird wunderbar generiert; bei Teilausfällen, Wiederholungen und Idempotenz rät die KI still und leise falsch, und das merkt man erst, wenn es in Produktion läuft.

Das tiefere Risiko ist meist nicht der Code selbst. Es sind die Annahmen, die er einbaut, ohne es Ihnen zu sagen. Eine generierte Funktion kann jeden Test bestehen und dabei stillschweigend annehmen, „dieses Feld ist immer vorhanden“ oder „diese Liste wird nie groß“. Niemand hat das aufgeschrieben, also überwacht es auch nichts. Mein eigentlicher Filter lautet: Kodiert dieser Code eine betriebliche Annahme, die sonst nirgends geprüft wird? Bei Validatoren, CRUD und UI-Zuständen sind diese Annahmen lokal und sichtbar, da bin ich entspannt. Beim Datenmodell und an den Schnittstellen der Integration sind sie global und unsichtbar, und genau dort übersteht eine selbstbewusste falsche Annahme das Review.

Ein realistisches Beispiel

Viele meiner jüngsten Arbeiten drehten sich um Multi-Tenant-SaaS-Plattformen und Ticketing-Systeme, also Projekte mit einem NestJS- oder Node-Backend, einem typisierten React- oder Next.js-Frontend und viel CRUD-Fläche über zahlreiche Module hinweg: Nutzer, Events, Tickets, Zahlungen, Benachrichtigungen.

In einer solchen Codebasis ist das Muster bewusst repetitiv: Jedes Modul ähnelt dem vorherigen. Genau das ist der ideale Einsatzbereich für KI-Unterstützung. Ich kann die Endpunkte, DTOs, Validierung und Frontend-Formulare eines neuen Moduls in einem Bruchteil der üblichen Zeit aufsetzen und meine eigentliche Aufmerksamkeit auf die Teile richten, die sich unterscheiden: die Berechtigungsregeln, die Randfälle, wie es in die bestehende Architektur passt.

Das ehrliche Ergebnis ist keine Magie. Die langweiligen 70 % gehen schneller, und dadurch bleibt mehr Zeit und Energie für die 30 %, die entscheiden, ob das Feature wirklich gut ist.

Typische Fehler, die ich sehe

• Große KI-Änderungen übernehmen, ohne sie zu lesen. Je größer der Diff, desto wahrscheinlicher ist etwas Subtiles falsch.
• Prompten statt denken. Wenn Sie nicht wissen, wie gut aussieht, kann die KI es Ihnen nicht sagen. Sie produziert dann einfach irgendetwas.
• Den Schritt zum Datenmodell überspringen. Ein von der KI überhastetes Schema ist eines, mit dem Sie monatelang kämpfen.
• Keine Tests. Geschwindigkeit ohne Sicherheitsnetz bedeutet nur, dass Sie Dinge schneller kaputtmachen.
• Den Stil abdriften lassen. Ohne Vorgaben schreibt die KI Code in ihrem eigenen Stil, nicht in dem des Projekts. Ich halte ihn passend zum umgebenden Code und schreibe die Konventionen des Projekts in die Anweisungsdatei des jeweiligen Tools (eine CLAUDE.md für Claude Code, Projektregeln für Cursor), damit es von den richtigen Mustern ausgeht.
• Subtile Kopplungen ignorieren. Der teure Fehler ist selten die Syntax. Es ist der eine generierte Helfer, der unbemerkt zu dem Ort wird, an dem Authentifizierung, Abrechnungsstatus und Produktannahmen aufeinandertreffen. Er ist schnell ausgeliefert und kostet später Zinsen.
• Keine Übersicht, wer KI wofür einsetzt. Sie können eine makellose Review-Disziplin haben und trotzdem Schiffbruch erleiden, wenn das halbe Team Produktionsschemas in ein KI-Tool füttert, ohne es jemandem zu sagen. Governance, ohne dabei paranoid zu werden, ist ein eigenes Thema.

Wie ich die Qualität hoch halte

1. Kleine, überprüfbare Änderungen: Ich steuere lieber zehn fokussierte Änderungen, als eine riesige zu übernehmen.
2. Alles lesen: Jede von der KI geschriebene Zeile bekommt dasselbe Review wie der PR eines Teamkollegen.
3. Tests für die wichtigen Pfade: besonders für die Fehlerfälle.
4. Bestehende Muster übernehmen: Der Code soll aussehen wie der Rest der Codebasis, nicht wie aus einem anderen Projekt.
5. Menschliche Entscheidungen bleiben menschlich: Architektur, Sicherheit und Geldlogik bleiben in meiner Hand.
6. Jede KI-Änderung muss Rechenschaft ablegen: Bei allem, was nicht trivial ist, soll die Änderung offenlegen, was sie tatsächlich berührt hat: welche Tabellen, Routen oder Berechtigungen sich geändert haben, was Daten beschädigen oder zwischen Mandanten durchsickern könnte, Nachweise für vorher und nachher, hinzugefügte oder bewusst ausgelassene Tests und ein Weg zurück. Dieser Beleg ist wichtiger als die Frage, welches Tool den Code erzeugt hat.

Wenn Sie das große Ganze interessiert, wie man auf diese Weise schlanke Produkte baut, habe ich darüber geschrieben, wie KI-gestützte Entwicklung MVPs schneller entstehen lässt, ohne an Qualität zu verlieren.

Sie suchen einen Entwickler, der moderne Tools richtig einsetzt?

KI gut einzusetzen ist eine Fähigkeit. Sie macht den Unterschied zwischen einer schnelleren, saubereren Entwicklung und einer teuren Aufräumaktion später. Ich nutze diese Tools jeden Tag, um Full-Stack-Web- und Mobile-Projekte schneller auszuliefern, ohne an den Stellen zu sparen, auf die es ankommt.

Wenn Sie genau so einen Entwickler für Ihr Projekt suchen, werfen Sie einen Blick auf meine Arbeit oder melden Sie sich und erzählen Sie mir, was Sie bauen.