Cursor AI: Feedbackschleifen macht den Unterschied!

Vor eineinhalb Jahren hatte ich eine Rezension zum gitHub Copilot geschrieben. Für 2023 war das beeindruckend, heute nicht mehr. Aktuell wird Cursor AI als eine der besten Programmier-AIs gehandelt. Grund genug, mir diese genauer anzuschauen (anhand eines realen Projektes). Dabei fand ich heraus, dass die Feedbackschleifen zwischen Anwender, Cursor AI und IDE den Unterschied machen. Im folgenden beschreibe ich:

• Warum KI so gut programmieren kann: Programmcode ist gleichzeitig für Menschen und Maschinen verständlich – das macht ihn ideal für KI-gestützte Anwendungen.
• Cursor AI: Eine eigenständige, auf VSCode basierende IDE mit nahtlos integrierter KI
• Feedbackschleifen in Cursor AI: Cursor ermöglicht dynamische Rückkopplung zwischen Nutzer, KI und IDE, wodurch Probleme iterativ und kontextbasiert gelöst werden.
• Beispiel: Typescript Refactoring: Ein reales Beispiel zeigt, wie Cursor Fehlerquellen analysiert, relevante Dateien in den Kontext zieht und Nutzeraktionen einbindet.
• Workflow-Kontrolle: Cursor bietet Funktionen wie Rollback-Checkpoints und Code-Diffs, die Nutzerkontrolle über KI-generierte Änderungen ermöglichen.
• Software-Infrastruktur für Feedbackschleifen: In der Softwareentwicklung existieren maschinenlesbare Feedbacksysteme schon lange.
• Feedbackschleifen im Systems Engineering fehlen: In der Produktentwicklung fehlen oft vergleichbare Strukturen, weshalb KI dort bisher weniger effektiv eingesetzt werden kann.
• Neue Werkzeuge als Enabler: Tools wie Flow Engineering oder Valispace versuchen, modellbasierte, integrierte Plattformen als Grundlage für KI-Nutzung zu etablieren.

Warum KI so gut programmieren kann

Software Code hat die Besonderheit, dass dieser sowohl für das Lesen von Menschen als auch von Maschinen konzipiert wurde. Microsoft hat dies frühzeitig erkannt, weshalb die Acquisition von gitHub in 2018 zum Ziel hatte, Trainingsdaten für das Joint Venture mit OpenAI bereitzustellen.

Software Code ist sowohl von Maschinen als auch von Menschen lesbar. Das macht Programmiercode so besonders.

Nicht nur das: Die in Code eingebetteten Kommentare beschreiben in der Regel das „Was“, welches im Code („Wie“) umgesetzt wird. Daher ist Unterstützung bei der Programmierung einer der einfachsten Anwendungsfälle für generative KI. Daher war der gitHub Copilot das erste KI-Produkt von Microsoft, das auf GPT von OpenAI basierte.

Was ist Cursor AI?

Cursor AI ist eine integrierte Entwicklungsumgebung (IDE) für die Programmierung. Cursor AI sieht Visual Studio Code (VSCode) von Microsoft zum Verwechseln ähnlich. Das ist nicht verwunderlich da VSCode Open Source-Software ist und Cursor dieses Projekt nutzt.

Cursor AI ist eine eigenständige IDE und nicht nur eine VS-Code-Erweiterung, weil die Architektur von VS Code nicht genug Kontrolle über die Benutzeroberfläche erlaubt. Nur durch das Forken von VS Code konnte Cursor die KI-Funktionen so nahtlos integrieren, wie dies heute der Fall ist.

Dieses Video zeigt einige der Features von Cursor und erklärt auch, warum Cursor AI VS Studio überlegen ist. Allerdings fehlt im Video das, was Cursor AI so überlegen macht: Feedbackschleifen!

Feedbackschleifen in Cursor AI

Erst beim Ausprobieren fiel mir auf, was Cursor AI wirklich bemerkenswert macht: Cursor realisiert Feedbackschleifen zwischen drei Teilnehmern:

• Nutzer: Initiiert Anfragen, bestätigt bestimmte Aktionen und verfeinert
• Cursor AI: Sucht nach Lösungen für die Aufgabe des Nutzers. Dabei bezieht es punktuell weitere Ressourcen in den Kontext mit ein und fordert die Bestätigung von manchen Aktionen
• IDE: Die IDE reagiert auf Aktivitäten von Nutzer und Cursor AI, zum Beispiel mit Fehlermeldungen. Cursor greift Rückmeldungen der IDE auf, bspw. um den Erfolg einer Aktion zu überprüfen

Dazu ein einfaches Beispiel:

Beispiel: Typescript Refactoring

In diesem Beispiel stellte ich bestehenden JavaScript-Code auf Typescript um. Nach der Umstellung gab es Fehler. Ich habe den Konsolenoutput selektiert (Zeilen 1–56), den Cursor AI dann analysiert:

Cursor hat eine mögliche Ursache identifiziert, die Datei PanePage.vue. Diese ist jedoch nicht im aktuellen Kontext vorhanden. Daher stellt Cursor nun eine Anfrage an die IDE, wie im folgenden zu sehen ist:

Cursor hat also das erste Problem eliminiert: Die Datei existiert an der richtigen Stelle. Daher sucht Cursor weiter und bezieht die Tyescript-Konfiguration ebenfalls in den Kontext mit ein (tscconfig.json). Doch auch da findet Cursor kein offensichtliches Problem. Daher wird nun die nächste Konfigurationsdatei, package.json, in den Kontext mit einbezogen:

Hier erkennt Cursor ein Problem und schlägt eine Korrektur vor. Diese erfordert jedoch das Ausführen eines Befehls (npm) auf der Konsole des Rechners des Nutzers. Das ist eine „gefährliche“ Operation, die Cursor nicht ohne Einbeziehung des Nutzers durchführen wird. Daher muss der Nutzer den Befehl überprüfen und kann diesen durch einen Klick auf „Run command“ ausführen.

Nach der Ausführung prüft Cursor sofort, ob es Fehlermeldungen in der IDE gibt. Wenn ja, dann sucht Cursor weiter.

Workflow-Kontrolle: Rollback, Diffs, etc.

Die Änderungen, die Cursor während eines Chats durchführt, kann der Nutzer über Rollback-Checkpoints jederzeit rückgängig machen. Ich habe das zu schätzen gelernt, denn manchmal landet man mit Cursor in einer Sackgasse und möchte von vorne anfangen.

Bei Vielen Vorschlägen geht es natürlich um das Bearbeiten von Quellcode. Dafür stellt Cursor sowohl ein Inline-Diff im Chat bereit, integriert sich aber auch in den Codeeditor, wo wir einzelne Änderungen annehmen, ablehnen oder bearbeiten können.

Software-Infrastruktur für Feedbackschleifen besteht schon lange

In der Softwareentwicklung gibt es schon lange eine Infrastruktur für Feedbackschleifen. Diese Infrastruktur kann an vielen Stellen mit KI ergänzt werden, so wie Cursor es macht. Das funktioniert, da alle Artefakte natürgemäß von Maschinen verarbeitet werden können.

Um nur einen kleinen Überblick zu geben:

• Sofortiges Feedback aus dem Code-Editor zu:
  • Code-Syntax
  • Statischer Korrektheit
  • Code-Stil
  • Best practices
• Automatisierung beim lokalen Arbeiten:
  • Ausführen der Unit-Tests beim Speichern
  • Formatierung des Codes beim Speichern (Prettier, Black, etc.)
  • Linting beim Speichern oder vor dem Commit
  • Auto-Importe und Auto-Fixes
  • Live-Reload im Browser bei Änderungen
• Automatisierung im Versionskontrollprozess:
  • Bauen der „Deployable Units“ beim Commit
  • Pre-Commit Hooks (Tests, Linter, Format Checks)
  • Automatische Codeanalyse im Pull Request
  • Automatisches Erstellen von Changelogs aus Commit-Nachrichten
  • Automatisches Tagging und Versionierung (Semantic Versioning, z. B. via Conventional Commits)
• CI/CD-Pipeline:
  • Automatisierter Integrationstest (Continuous Integration, CI)
  • Automatisiertes Deployment (Continuous Deployment, CD)
  • Automatisiertes Rollback bei fehlerhaftem Deployment
  • Canary Releases oder Blue-Green Deployments
  • Automatisches Provisionieren von Infrastruktur (Infrastructure as Code, z. B. mit Terraform)
• Qualitätssicherung und Überwachung:
  • Automatisiertes Monitoring nach dem Deployment
  • Automatische Fehlerberichte (z. B. via Sentry)
  • Visuelle Regressionstests
  • Performance-Tests im CI-Prozess
  • Sicherheits-Scans (z. B. Dependency Scanning, SAST, DAST)
• Dokumentation und Kommunikation:

Feedbackschleifen im Systems Engineering fehlen

Doch das ist das Problem im Systems Engineering: Diese Infrastruktur von maschinenlesbaren Artefakten fehlt oder ist lückenhaft.

Konkretes Beispiel: Testautomatisierung. Häufig werden Tests händisch durchgeführt. Manche Tests können auch über Simulationen durchgeführt werden, zum Beispiel in Simulink. Doch der Wert ist begrenzt, wenn diese Tests nicht in die Abläufe integriert sind.

Ich habe Teams gesehen, die sich entsprechende Automatisierungen selbst gebaut haben. Das erfolgreichste Beispiel ist SpaceX, die damit enorm kurze Entwicklungszyklen realisieren. Doch für die meisten Teams ist das kein gangbarer Weg: Oft fehlen die Kompetenzen im Team, schließlich soll ja das Produkt entwickelt werden, nicht die Entwicklungswerkzeuge. Selbst wenn die Kompetenzen vorhanden sind, hängen solche Abläufe oft an einer einzelnen Person, die Zuverlässigkeit der Automatisierungen kann ebenfalls selten gewährleistet werden.

Neue Werkzeuge als Integrationsplattform

Daher bin ich skeptisch, ob wir eine ähnliche KI-Unterstützung in der Produktentwicklung in der nahen Zukunft sehen werden: Die Infrastruktur fehlt. Eine Weile hatte ich die Hoffnung, dass OSLC ein Teil der Lösung werden könnte. Doch in der Praxis habe ich in diese Richtung noch nichts gesehen.

Am vielversprechendsten erscheint mir im Moment der Ansatz von Flow Engineering. Das Werkzeug von Flow legt großen Wert auf die Integration von Modellen und das Propagieren von Parametern. Damit stellt es eine Infrastruktur von verzahnten Modellen zur Verfügung, die von Maschinen und Menschen lesbar sind.

Auch Valispace verfolgt einen ähnlichen Ansatz. Valispace ist insofern bemerkenswert, da das Werkzeug schon seit Jahren mit eingebauter KI-Assistenz experimentiert.

Fazit

Cursor AI zeig in beeindruckender Weise, wie schnell KI-basierte Lösungen sich weiterentwickeln. Cursor zeigt auch, dass von Mensch und Maschine gleichermaßen lesbare Artefakte ein wichtiger Enabler sind. Also maschinenlesbar ohne KI. Solche Artefakte nennen wir im Allgemeinen „Modelle“. Softwarecode ist ein solches Modell.

Im Systems Engineering bzw. in der Produktentwicklung haben wir dies leider so gut wie gar nicht. Bevor das nicht gelöst ist, erwarte ich auch nicht dieselben Quantensprünge, die wir zur Zeit in der Softwareentwicklung sehen.