Cursor AI Tutorial: vom leeren Editor zum geprüften Feature

• Projekt startet lokal
• Git-Status ist bekannt
• Secrets liegen nicht im Repository
• README nennt Start-, Test- und Buildbefehl
• Eine kleine Aufgabe ist eindeutig beschrieben

Beginne nicht mit „Baue mir eine komplette App“. Öffne ein kleines vorhandenes Projekt oder ein bewusst minimales Starter-Projekt und wähle einen Ablauf, den du selbst im Browser prüfen kannst.

Öffne vor der ersten Änderung die Projektstruktur und markiere Verzeichnisse, die nicht in den Kontext gehören, etwa Build-Artefakte, große Datendateien oder lokale Secrets. Ein kleiner, relevanter Kontext verbessert die Vorschläge und reduziert das Risiko, dass Cursor alte oder generierte Dateien als Architekturvorbild verwendet.

Untersuche zuerst, wie Formulare und Validierung in diesem Projekt umgesetzt sind.
Plane danach ein Kontaktformular mit Name, E-Mail und Nachricht.
Nutze vorhandene UI-Komponenten.
Zeige klare Lade-, Erfolgs- und Fehlerzustände.
Führe nach der Umsetzung die relevanten Tests aus.

Lies den vorgeschlagenen Plan: Werden bestehende Muster wiederverwendet? Ist klar, wo Daten validiert und verarbeitet werden? Gibt es eine Aussage zu Fehlerfällen? Erst danach sollte der Agent Dateien bearbeiten.

Verknüpfe den Auftrag mit konkreten Dateien nur dann, wenn du ihre Rolle bereits kennst. Andernfalls soll der Agent zuerst nach vergleichbaren Funktionen suchen und die vorhandene Konvention benennen. So entsteht die Lösung dort, wo das Projekt sie erwartet, statt in einer neuen Hilfsstruktur, die spätere Entwickler zusätzlich verstehen müssen.

1. 1

   Dateiliste prüfen

   Wurden nur relevante Dateien verändert?

2. 2

   Logik lesen

   Sind Validierung und Berechtigungen serverseitig?

3. 3

   Tests ausführen

   Kontrolliere die echte Ausgabe statt nur die Zusammenfassung.

4. 4

   UI bedienen

   Teste korrekte Eingabe, leere Felder und Serverfehler.

5. 5

   Konsole ansehen

   Warnungen und fehlgeschlagene Netzwerkanfragen beseitigen.

Prüfe im Diff nicht nur hinzugefügte Zeilen. Gelöschte Validierung, gelockerte Typen oder still geänderte Standardwerte können größere Folgen haben als das neue Feature. Teile einen umfangreichen Diff nach Verantwortungsbereichen auf und lehne kosmetische Nebenänderungen ab, damit die fachliche Wirkung klar überprüfbar bleibt.

Wiederkehrende Konventionen gehören in versionierte Projektanweisungen: Architektur, Benennung, erlaubte Befehle, Teststrategie und Bereiche, die nicht verändert werden dürfen. Halte Regeln kurz und konkret; widersprüchliche oder veraltete Regeln verschlechtern Ergebnisse.

Gute Regeln sind kurz, konkret und testbar. „Schreibe sauberen Code“ hilft wenig; „nutze vorhandene UI-Komponenten, prüfe Rechte serverseitig und führe vor Abschluss den Befehl npm test aus“ ist überprüfbar. Entferne veraltete Regeln zeitnah, sonst erzeugen widersprüchliche Anweisungen zufällige Ergebnisse zwischen Sitzungen.

1. 1

   Fehler reproduzieren

   Halte Eingabe, Umgebung und vollständige Meldung fest und bestätige, dass der Fehler wiederholbar ist.

2. 2

   Änderungsbereich begrenzen

   Vergleiche mit dem letzten stabilen Commit und identifiziere die kleinste verdächtige Änderung.

3. 3

   Hypothese prüfen

   Lass Cursor eine Ursache nennen und fordere eine konkrete Beobachtung an, die dafür oder dagegen spricht.

4. 4

   Regression absichern

   Ergänze einen Test für den Fehlerfall und ändere erst danach die betroffene Logik.

Vermeide Aufforderungen wie „repariere alles“, wenn mehrere Warnungen gleichzeitig auftreten. Sie führen leicht zu breiten Umbauten, bei denen Ursache und Wirkung nicht mehr zuzuordnen sind. Ein einziger reproduzierbarer Fehler pro Schleife schafft eine überprüfbare Lernspur und macht einen Rücksprung jederzeit möglich.

Wenn der Fehler nur gelegentlich auftritt, variiere jeweils genau eine Bedingung: Browser, Nutzerrolle, Datenzustand oder Netzwerk. Halte die Ergebnisse in einer kleinen Matrix fest. Cursor kann daraus gezielte Instrumentierung oder Tests ableiten, ohne die Anwendung auf Verdacht umzubauen. Nach der Korrektur entfernst du provisorische Ausgaben und prüfst zusätzlich einen benachbarten Erfolgsfall, damit der Fix nicht nur das sichtbare Symptom verschiebt.

Speichere nützliche Reproduktionsschritte in der Aufgabe oder im Testnamen, nicht ausschließlich im Agenten-Chat. Ein Teammitglied muss den Fehler später ohne deine lokale Sitzung verstehen können. Das verbessert zugleich künftige Cursor-Aufträge, weil erwartetes Verhalten und frühere Randfälle direkt im Repository auffindbar bleiben. Verlinke dabei den betroffenen Commit und die relevante Testdatei.