KI-Coding Trick: Regeln für Agenten erstellen und: Die wichtigste Regel?

Geschrieben von Fachexperten: Timon Fiddike, CST®, Machine Learning seit 2005

Dies ist eine Ergänzung zum Artikel KI-Coding Lernen: Ein Weg in 10 Schritten: Ein Erfahrungsbericht, speziell zu Schritt 6. Die Schritte davor und danach geben Dir ggf. wertvollen Kontext für diesen Artikel.

Ich bin fast wahnsinnig geworden, als der Agent bei meinen ersten Experimenten (Artikel dazu siehe hier) immer wieder Antworten in schlechter technischer Qualität geliefert hat. Zum Glück habe ich dann die MDC-Regeln (Multi Document Context) entdeckt:

Mit Regeln können wir den Arbeitsablauf des Agenten steuern und technische Vorgaben setzen. Das funktioniert für mich subjektiv in mehreren Projekten sehr gut, in diesem Artikel möchte ich die Wirkung von MDC-Regeln objektiver untersuchen und demonstrieren:

Experiment: Unterschied durch Regeln

Um den Unterschied beurteilen zu können, gehe ich wie folgt vor:

• Wähle ein legacy Projekt mit offenen Baustellen (s.u., 9 Jahre Entwicklung)
• Bitte den Agenten um Vorschläge zur Verbesserung (noch ohne MDC-Regeln)
• Frischer Start: Entferne die Datei mit Vorschlägen, neuer Chat mit dem Agenten
• Erstelle MDC Regeln
• Bitte den Agenten um Vorschläge zur Verbesserung (nun mit MDC-Regeln)
• Vergleich der Vorschläge mit Kriterien objektivieren

Hintergrund: Projekt Retromat (9 Jahre)

Der Startpunkt: Das Experiment findet an dem Open Source Projekt Retromat statt (live, GitHub), wo ich seit 2016 involviert bin. Corinna hatte bereits eine funktionierende Version online, bei der alle Inhalte als ein einziges, großes JavaScript Array mit in die jeweilige HTML Seite eingebettet waren. Per PHP wurde eine solche Seite pro Sprache (Englisch, Deutsch, Spanisch uvm.) generiert. Das hat für Menschen hervorragend funktioniert. Suchmaschinen konnten die Inhalte allerdings nicht indizieren und zur Bearbeitung musste jeder Übersetzer zumindest auch rudimentär mit HTML und JavaScript umgehen können. Ich habe dann eine Symfony App aufgebaut, die jede Ansicht im UI als eigene HTML Seite bereitstellt, so dass Suchmaschinen diese indizieren konnten. Wir haben auf diese Weise damals sehr schnell mehr Sichtbarkeit bekommen. Die wichtigste Wirkung war erreicht. Seitdem gibt es eine Mischung aus Maintenance und langsamer Weiterentwicklung.

Vorschläge zur Verbesserung (ohne Regeln)

Prompt 1
Give me a prioritised list of possible improvements to the structure of this project. put it in improvement-ideas-01.md

Und schon beginnt der Agent seine Arbeit:

Das Datum (2024) hat wohl eher mit den Trainingsdaten zu tun (heute ist der 8.7.25):

Die „Biggest Challenge“ wurde korrekt erkannt, ich bin angenehm überrascht. Für den Moment lege ich die Datei in ein anderes Verzeichnis und öffne einen Chat mit frischem Kontext, um den weitern Verlauf des Experiments nicht zu stören.

Regeln erstellen

Bisher sind keine Regeln zum Symfony Framework vorhanden, ich lasse sie erstellen:

Prompt 1
Create .cursor/rules/symfony-5.4-best-practices.mdc with proper content to ensure this project will follow Symfony 5.4 best practices as describe here:
https://symfony.com/doc/5.x/best_practices.html
Keep the structure similar to the existing examples in .cursor/rules 
The new rule needs to be always considered, as it applies not just to .php, but also to directory structure and placement of any file within the project.

Um dem Agenten die Erstellung zu erleichtern, kopiere ich zunächst einige Meta-Regeln aus einem anderen Projekt. Diese beziehen sich auf den generellen Aufbau, Abelageort und sonstigen Umgang mit Regeln. Alle Regeln sind frei auf Github verfügbar, und zwar hier. Im Screenshot sind diese auf der linken Seite grün markiert:

Schon während der Erstellung der Regel für das Framework greift die Meta Regel „Rule Acknowledgement„. Für Menschen, die beginnen, mit MDC Regeln zu arbeiten oder die selbst neue Regeln entwickeln, ist diese Regel vielleicht schon die wichtigste Regel überhaupt, im letzten Abschnitt erkläre ich den Hintergrund

Die Zusammenfassung finde ich vielversprechend und der Blick in die Regeldatei symfony-5.4-best-practices.mdc bestätigt: Hier wurden, wie erbeten, Best Practices bezüglich Symfony zusammengetragen. Also schreiten wir gleich zur Anwendung:

Vorschläge zur Verbesserung (mit Regeln)

Frischer Start: Um ein möglichst unabhängiges Experiment zu erreichen, habe ich nach dem ersten Prompt die erste Datei mit Verbesserungsvorschläge (improvement-ideas-01.md) vorübergehend aus dem Verzeichnis entfernt, und außerdem einen neuen Chat mit dem Agenten begonnen, so dass der Kontext wieder frisch ist. Dann prompte ich genau wie zuvor:

Prompt 2
Give me a prioritised list of possible improvements to the structure of this project. put it in improvement-ideas-02.md

Die Regel „Rule Acknowledgement“ informiert uns wieder, welche Regeln erkannt bzw. beachtet wurden:

• Die Best Practices zu Symfony 5.x werden beachtet – sehr gut
• Regeln rund um „Rules Management“ sind bei diesem Prompt nicht relevant – das stimmt
• Die Regel „code-quality-checks“ greift bei Änderungen am Code selbst und sorgt dann dafür, dass m.H. eine Shell Skripts verschiedene Quality Tools ausgeführt werden, d.h. mit Hilfe von PHPStan, PHP-CS-Fixer und Parallel-Lint werden sehr schnell statische Codeanalysen von geänderten Dateien durchgeführt und die Formatierung vereinheitlich. Da beim aktuellen Prompt keine Änderung Code ausgeführt wird, darf diese Regel, trotz thematischer Ähnlichkeit, in der Tat, als nicht relevant gelten – also korrekt

Dieser Satz von Vorschlägen (improvement-ideas-02.md) verweist auch gleich ganz oben schon auf die dokumentierten Best Practices für Symfony 5.x.

Die Zusammenfassung finde ich vielversprechend: Sie enthält, wie erhofft, spezifischere Themen als zuvor und der Blick in die Datei bestätigt: Hier wurden, wie erbeten, Vorschläge entwickelt, die sich an den Best Practices bezüglich Symfony orientieren.

Vergleich der Vorschläge objektivieren

Wie oben bereits erwähnt, habe ich beim Blick in die Dateien bereits selbst gesehen, dass die mit Hilfe von Regeln erstellte Liste eine deutlich höhere Anzahl an spezifischen Vorschläge enthält. Aber dabei muss es nicht bleiben: Schließlich leben wir im Jahr 2025 und wir können diese Überprüfung leicht objektivieren. Dazu habe ich zunächst (ohne die Dateien bereit zu stellen) ChatGPT gebeten, mir Kriterien vorzuschlagen, anhand derer man zwei Dokumente mit Lösungen von zwei verschiedene Kandidaten vergleichen könnte. Ich habe dann selbst die irrelevanten Kriterien aus der Liste entfernt, und mir (noch ohne Inhalt) eine Beispiel-Ergebnistabelle erstellen lassen. Diese habe ich so lange verfeinert, bis ich mit der Struktur zufrieden war.

Nachdem somit die Kriterien und das Ausgabeformat spezifiert waren, habe ich die beiden Dateien improvement-ideas-01-no-mdc.md und improvement-ideas-02-with-mdc.md bereitgestellt und die Analyse gestartet. Hier das Ergebnis:

Durch die Zahlen wird deutlich sichtbar, was ich mit den Augen schon entdeckt hatte: Die Liste auf Basis der MDC-Regeln ist in der Tat sowohl umfassender, als auch spezifischer.

Die wichtigste Regel?

Ausgaben der meta Regel „Rule Acknowledgement“ tauchten weiter oben schon in mehreren Screenshots auf:

Für Menschen, die beginnen, mit MDC Regeln zu arbeiten oder die selbst neue Regeln entwickeln, ist diese Regel vielleicht schon die wichtigste Regel überhaupt, denn:

Problem: Im Gegensatz zu der früher verwendeten einen .curserrules Datei liegt ein Vorteil von vielen kleinen separaten MDC-Regeln darin, dass der Kontext nicht unnötig durch irrelevante Regeln gefüllt wird. Das spart Zeit und Tokes, also letztlich Geld. Allerdings ist dies natürlich auch eine weitere Fehlerquelle: Wurden einzelne Regeln nicht geladen, entgehen einem die Vorteile der jeweiligen Regeln und man merkt es möglicherweise erst mit Verzögerung. Cursor bietet hier mittlerweile etwas mehr Orientierung als früher, in dem durch kleine Einblendungen schon beim Erstellen des Prompts gezeigt wird, welche Regeln beachtet werden. In einigen des Screenshots weiter oben ist dieser Effekt zu beobachten, die Einblendung taucht dann oberhalb vom selbst geschriebenen Prompt Text auf. Das hilft jedoch nur begrenzt weiter: Man weiß dann zwar, dass die Regel zumindest gelesen wird, es kann aber weiterhin sein, dass der Agent die Regel für die jeweilige Frage als nicht relevant erachtet und ignoriert.

Lösung: Die Meta Regel „Rule Acknowledgement“ wird dauerhaft eingebunden per „alwaysApply = true“ (siehe Zeile 4), und erzwingt dann bei jedem Prompt, dass der Agent kurz Stellung bezieht, darüber, welche Regeln von ihm als in diesem Fall(!) berücksichtigt werden.

Falls beim Erstellen neuer Regeln Unklarheiten entstehen, ist eine solche Meta Regel Gold wert, weil sie die Fehlersuche extrem erleichtert.

Alle im Artikel erwähnten Regeln sind frei auf Github verfügbar, und zwar hier.

Reflexion, Einladung und Angebot

• Hast Du als Entwickler konkrete Ideen für Deinen eigenen Weg bekommen?
• Hast Du als Führungskraft einen Eindruck gewonnen, welche Schritte Deine Mitarbeiter gehen könnten? Denkst Du darüber nach, ihnen andere Impulse und Unterstützung anzubieten als bisher?
• Hast Du einen ersten Eindruck von mir?

Nimm gerne Kontakt mit mir auf, wenn Du einen Impulsvortrag oder Workshop möchtest! Lass uns gemeinsam überlegen, welche Art von Unterstützung für Euch hilfreich sein kann. Ich erstelle Euch gerne ein Angebot. Du erreichst mich direkt oder (wg. Spam Filter) auch noch verlässlicher über unsere zentrale Kontakt E-Mail oder Telefon.

Über den Autor