Tipps für den Einsatz von Cursor für Agentic Programming in produktiven Teams (ohne die Architektur zu kompromittieren)

Intro:

Cursor ist ein KI-gestützter Code-Editor, der Entwickler:innen dabei unterstützt, Code schneller zu lesen, zu verändern und zu erzeugen. Der zentrale Wandel besteht weniger darin, dass „KI Code schreibt“, sondern darin, dass der Editor heute zusammenhängende Änderungen über mehrere Dateien hinweg vorschlagen und Implementierungsarbeit übernehmen kann, die früher weitgehend manuell war.

Wer Cursor bisher primär als Autocomplete wahrgenommen hat, findet in agentischen Workflows eine deutlich weitergehende Ausprägung: Das Tool kann Änderungen über mehrere Dateien koordinieren und anhand von Feedback wie Build- und Testergebnissen iterieren. Der Mehrwert entsteht jedoch nur mit klaren Leitplanken und konsequenter Verifikation – andernfalls entsteht Output, der professionell wirkt, aber nicht zuverlässig zur Systemarchitektur passt.

Die folgenden Praktiken beschreiben, was sich in realen Teams bewährt hat: pragmatisch, öffentlich teilbar und auf wiederholbare Engineering-Ergebnisse statt Hype ausgerichtet.

Auch wenn dieses Dokument Cursor als konkretes Beispiel verwendet, sind die Learnings so formuliert, dass sie sich auf andere Tools wie GitHub Copilot oder Claude Code übertragen lassen.

Learning 1: Dokumentation als Code – Entscheidungen als Regeln codieren 

Ein Großteil klassischer Dokumentation ist passiv: Sie wird für Menschen geschrieben, inkonsistent gelesen und driftet schnell von der Realität ab.

Hoher Nutzen entsteht, wenn die wertvollste „Dokumentation“ als wiederholt anwendbare Constraints verstanden wird, etwa:

• Architekturgrenzen („was darf wovon abhängen?“)

• Konventionen zur Reduktion von Reibung (Fehlerbehandlung, Benennung, Layering)

• explizite „don’t do this here“-Regeln, die schleichende Erosion verhindern

  
  

Das schafft zwei Effekte: Das Tool muss weniger raten, und Onboarding wird schneller, weil „der normale Weg“ explizit ist und nah am Code liegt.

Entscheidend ist allerdings Rule Hygiene. Wenn Regeln zu langen Essays werden, sinkt ihre Akzeptanz – und das Tool behandelt sie als Rauschen.

Learning 2: Tooling aufbauen, mit dem die KI die eigene Arbeit deterministisch validieren kann

KI-Tools verhalten sich zunehmend wie ein probabilistischer Compiler: Intentionen werden in Code übersetzt, der oft plausibel ist – aber nicht garantiert korrekt. Um von „plausibel“ zu vertrauenswürdig zu kommen, braucht es einen Verifikations-Loop, der günstig, wiederholbar und deterministisch ist:

• One-Command Build und Typechecks

• One-Command Lint und Format

• schnelle, gezielte Tests (mit klaren Fehlermeldungen)

  
  

Konsequent eingesetzt, ermöglichen diese Checks:

• Selbstkorrektur: Wenn der Agent die Verifikation ausführen kann, wird auf konkrete Fehler iteriert statt zu raten.

• Engineering-Hygiene: Lokale Validierung und identische CI-Gates reduzieren vermeidbare Breakages; Reviews fokussieren stärker auf Intention und Risiko.

Learning 3: Kumulierte Verbesserungen – Learnings in wiederverwendbare Assets überführen

Ein häufiger Kostenfaktor in AI-assisted Development ist, dass dieselben Erkenntnisse wiederholt „neu gelernt“ werden.

Sobald etwas identifiziert ist, das nicht erneut passieren soll – Anti-Pattern, fehlende Konvention, bessere Prompt-Struktur oder Guardrail – lohnt es sich, diese Erkenntnis in wiederverwendbarer Form zu codieren:

• als Regel

• als Command/Script

• als Prompt-Template

• als Lint/Static Check

• als kleine automatisierte Validierung

  
  

In der Praxis bewährt sich eine zentrale „Rules/Recipes“-Library in Git, die teamübergreifend wiederverwendet wird, während projektspezifische Regeln separat bleiben (weil nicht jede Constraint generalisierbar ist).

Der Compounding-Effekt ist nicht „mehr Regeln“, sondern weniger wiederholte Fehler und konsistentere Ausführung. Damit ein Flywheel entsteht, muss das Beitragen zu Rules/Recipes bewusst niedrigschwellig sein.

Learning 4: Contract-driven Development – „Stahl in der Wand“

Viele KI-bedingte Probleme sind Ambiguitätsprobleme: unklare Inputs/Outputs, unscharfe Verantwortlichkeiten und implizites Verhalten.

Strikte Contracts reduzieren diese Ambiguität deutlich. Wenn Grenzen über starke Interfaces definiert sind – etwa Protobuf-Schemas oder ähnlich strikte Vertragsschnittstellen – entsteht „Stahl in der Wand“:

• Implementierungen erfolgen gegen eine stabile Spezifikation,

• Reviews werden an der Boundary nachvollziehbarer,

• Tooling kann Kompatibilität deterministisch prüfen.

  
  

Tests bleiben weiterhin erforderlich, aber eine große Klasse von „sieht richtig aus, ist subtil falsch“-Änderungen wird verhindert.

Learning 5: Microservices und modulare Grenzen funktionieren gut (netzwerkbasiert oder in-process)

Es geht nicht um „Microservices als Ideologie“, sondern um Bounded Contexts.

KI-Tools performen am besten, wenn Systeme in Einheiten mit folgenden Eigenschaften zerlegt sind:

• klare Verantwortung

• stabile Interfaces

• definierte Abhängigkeitsrichtung

• lokale Verifikation

  
  

Diese Grenzen können Netzwerk-Calls sein oder in-process Module. Entscheidend ist die Klarheit der Nahtstellen: Wenn Grenzen real sind, bleibt die Arbeit des Tools eingrenzbar und reviewbar.

Learning 6: Type Safety passt sehr gut zu LLMs

Typsysteme und generierte Interfaces liefern einen objektiven Feedback-Loop für AI-assisted Development:

• Compiler/Typechecker finden Mismatches früh,

• Fehler sind explizit und meist gut handhabbar, was Iteration beschleunigt.

  
  

Types ersetzen kein Verhaltenstesting, reduzieren jedoch die „unknown unknowns“, die aus locker spezifizierten Strukturen entstehen.

Learning 7: Architektur doppelt codieren – in Regeln und in deterministischer Durchsetzung

Regeln sind notwendig. Deterministische Enforcement macht sie im Maßstab zuverlässig:

• Dependency-Rules (Imports/Layer)

• Lint-Regeln gegen bekannte Bad Patterns

• Contract-Kompatibilitätschecks

• Architekturtests

• CI-Gates, die Boundary Violations verhindern

  
  

Ein nützliches Heuristik: Wenn eine Regel automatisch prüfbar ist, sollte sie automatisch geprüft werden.

KI kann helfen, Linters und Checks zu implementieren – entscheidend ist, dass das Guardrail selbst deterministisch, reviewbar und konsistent durchgesetzt ist.

Learning 8: Praktischer Hinweis zu „kleinen Diffs“ vs. „großem Scaffolding“

In bestehenden Codebases gewinnen meist kleine, kohärente Slices: Sie sind leichter zu reviewen, sicherer zu verifizieren und reduzieren versehentliche Kopplung. Ein Backlog mit „Next Slices“ ist häufig effektiver als das Vermischen vieler Themen in einem Lauf.

In neuen Projekten kann größeres Scaffolding effizient sein (Projektstruktur, Basismodule, Templates) – solange es ein kohärenter Architekturslice bleibt und die Verifikation unmittelbar erfolgt. Sobald reale Interfaces entstanden sind, ist inkrementelles Vorgehen in der Regel die robustere Standardstrategie.

Ein typischer Failure Mode besteht darin, aktuelle Tools mit zu vielen, nicht zusammenhängenden Zielen gleichzeitig zu überlasten.