Geschrieben von Fachexperten: Timon Fiddike, CST®, Machine Learning seit 2005
Zusammenfassung
Hier beschreibe ich konkret und technisch meine 10 Schritte vom Start mit KI-Coding bis hin zur produktiven Nutzung. Im Artikel Haltung zu KI-Coding: Von Vermeidung zu Realismus teile ich meine menschliche Erfahrung unterwegs. Beide Artikel richten sich an Entwickler und deren Führungskräfte.
Inhaltsverzeichnis
Wozu dieser Artikel? Hoffnungen dahinter
Ich hoffe, es ist in Ordnung, wenn ich „Du“ schreibe. In Workshops sind wir i.d.R. auch per Du. Wie in der Zusammenfassung skizziert, teile ich sowohl meine menschliche Erfahrung, als auch konkret und technisch meine Schritte 10 auf dem Weg (in diesem Artikel). Beide Artikel ruhen auf dem Boden der Tatsachen, ohne Übertreibung und ehrlich mit Abwegen und Umwegen. Hinter beiden Artikeln stecken mehrere Hoffnungen:
- Hoffnung 1: Als Entwickler bekommst Du konkrete Ideen für Deinen eigenen Weg.
- Hoffnung 2: Als Führungskraft gewinnst Du einen Eindruck, welche Schritte Deine Mitarbeiter gehen könnten. Vielleicht denkst Du darüber nach, ihnen andere Impulse und Unterstützung anzubieten als bisher.
- Hoffnung 3: Du bekommst einen ersten Eindruck von mir. Vielleicht nimmst Du Kontakt auf, wenn Du einen Impulsvortrag oder Workshop möchtest.
Reihenfolge der Schritte
Viele andere Reihenfolgen könnten auch funktionieren. Da dies ein Erfahrungsbericht ist, habe ich sie in der Reihenfolge aufgeschrieben, in der ich sie tatsächlich gegangen bin.
Schritt 1: Copy & Paste mit ChatGPT
Standard ChatGPT hat mich vor allem bei kleinen Refactorings immer wieder postiv überrascht. Per Copy & Paste ist es aber ziemlich umständlich, genug Kontext für größere Aufgaben zu geben. Dadurch gibt es hier mit kleinem Aufwand auch nur kleinen Nutzen.
Schritt 2: KI Code Vervollständigung
Viele IDEs oder Plugins bieten heute KI basierte Vervollständigung aka „Line Completion“ an. Manchmal errät das Modell am Zeilenanfang schon, wie die Zeile enden sollte. Oder wenn ich eine einfache Änderung an mehreren Stellen vornehmen möchte, geht es ab Schritt 2 sehr leicht mit Tab Tab Tab. Modelle sind hier sehr unterschiedlich, manche stören auch mehr, als sie nützen.
Schritt 3: IDE mit KI Chat und Agent
Cursor, Windsurf, und ähnliche IDEs sind durch den integrierten Chat praktischer als Copy & Paste mit ChatGPT. Dies habe ich lange vor mir her geschoben. Wie im Artikel Haltung zu KI-Coding: Von Vermeidung zu Realismus beschrieben, kam aber der Moment, an dem ich diesen nächsten Schritt gehen wollte.
Speziell bei Cursor steht die Modellauswahl anfänglich auf „Auto Select“, so dass im Hintergrund oft die GPT Modelle von OpenAI verwendet werden, weil es den Anbieter einfach weniger Geld kostet. Claude Sonnet liefert beim Coden meist bessere Ergebnisse:

Interessant wird es, wann man von „Ask“ auf „Agent“ umschaltet:

Dies ist ein Wendepunkt. Agenten wie „Cursor Compose“ können, von einem Prompt ausgehend, selbstständig größere Änderungen an mehreren Dateien vornehmen, Tests und externe Tools ausführen. Auf eine einzelne Anweisung hin würde der Agent z.B.
- Code in 5-10 Dateien erstellen, ausführen, Fehler bemerken und korrigieren
- Automatisierte Tests erstellen, ausführen, Fehler bemerken und korrigieren
- Qualitätstools wie statische Codeanalyse, Formatierung etc. ausführen, Fehler bemerken und korrigieren
Als Entwickler habe ich hier noch die volle Kontrolle. Der Agent führt die Tätigkeiten Schritt für Schritt aus. Zwischen den Schritten kann man dem Agenten sogar auch bei seinen Selbstgesprächen zuschauen, wenn man ein „thinking“ Modell wie Claude 4 Sonnet ausgewählt hat (zu erkennen am 🧠 Symbol, siehe erster Screenshot). Änderungsvorschläge für den Code kann man prüfen und das Ausführen von Befehlen (Tests, Quality Tools etc.) wird nur vorgeschlagen. Die Ausführung erfolgt erst, wenn der Entwickler „Accept“ klickt.
Mit der Zeit wird man geschickter darin, Anweisungen zu geben und klickt dann immer wieder „Accept“, bis man den Autorun Mode entdeckt:
Schritt 4: Agent mit Auto-Run Mode in VM
Wer schon einmal mehrere Minuten damit verbracht hat, immer wieder „Accept“ zu klicken, wünscht sich ggf., dass der Agent die Anfrage bis zum Abschluss bearbeitet, und zwar ohne Rückfragen. Am Ende will ich immer noch das Ergebnis prüfen, aber eben nicht mehr jeden Zwischenschritt.
In Cursor hieß dieser Modus zunächst „Yolo Mode“ (kurz für „You only live once“). Mittlerweile wurde die Bezeichnung auf „Auto-Run“ geändert:

Der Auto-Run Mode ist Fluch und Segen zugleich. Er kann eine Erleichterung sein, sich aber auch wie ein bedrohlicher Kontrollverlust anfühlen. Im Artikel Haltung zu KI-Coding: Von Vermeidung zu Realismus entspricht dies dem Abschnitt „Größere Schritte“. Befürchtungen aller Art sind hier vollständig berechtigt, denn:
Die im Screenshot gezeigten Einstellungen würde dem Agenten erlauben, beliebige Befehle aus einem externen KI Modell ohne Rückfrage mit allen meinen Benutzerrechten auf meinem Gerät auszuführen. Falls mein Account Admin oder Sudo Rechte hat, lässt sich damit beliebig viel Schaden anrichten. Und ich bin sehr skeptisch, was die Wirksamkeit der in Cursor eingebauten Schutzmaßnahmen betrifft, denn da gab es auch schon große Lücken:

Wer Zugriff auf schützenswerte Daten hat, entwickelt hier besser ein Schutzkonzept.
Ich selbst verwende deswegen Cursor mit Auto-Run Mode im Moment in einer virtuellen Maschine, die alle nötigen Werkzeuge für die Entwicklung enthält UND SONST NICHTS. Gleiches gilt natürlich auch für Claude Code, Windsurf, Aider, und andere KI-Coding Tools.
Schritt 5: Mehr technischer Kontext
Mein erstes KI-Coding Projekt habe ich vom Agenten „auf der grünen Wiese“ erstellen lassen und die Qualität war furchtbar. Alles stand in einem riesigen Skript, ohne Klassen, sogar auch ohne Funktionen, stattdessen aber fünf verschachtelte IF-Statements und Schleifen.
Die Wahrscheinlichkeit für Ergebnisse, die aus technischer Sicht sinnvoll und für Menschen verständlich sind, können wir steigern, indem wir bezüglich der technischen Umsetzung möglichst viel Kontext strukturiert bereit stellen.
Viele Entwickler verwenden nun wieder technische Frameworks (wie Python Django oder PHP Symfony), selbst, wenn sie es als Mensch nicht unbedingt bräuchten, denn:
- Die Dateien des Frameworks an sich geben dem Agenten schon Orientierung und
- mit dem Shortcut @Docs kann Cursor die gesamte aktuelle Dokumentation des Framworks in den Kontext des Modells ziehen. Das geht sehr schnell, weil für viele beliebte Frameworks die Dokumentation schon vorab von Cursor indiziert wurde. Zusätzlich kann man für das Framework der eigenen Wahl auch Dokumentation selbst indizieren lassen, siehe hier.
Tools wie Context7 erlauben ebenfalls, den Kontext anzureichern, und funktionieren mit Cursor, Windsurf, VS Code, Claude Code etc. Ich selbst bevorzuge im Moment der Einfachheit halber das eingebaute @Docs von Cursor.
Schritt 6: Regeln für den Agenten
Mit Regeln können wir den Arbeitsablauf des Agenten steuern und technische Vorgaben setzen.
- Dem Cursor Agenten kann man mit einer Datei „.cursorrules“ sehr genau sagen, wie er arbeiten soll, dafür gibt es auch Bibliotheken, z.B. awesome-cursorrules (backup Fork hier). Die Entwicklung ist hier sehr schnell, dieser Mechanismus funktioniert noch, ist aber offiziell schon abgekündigt, aktuell empfohlen wird:
- MDC (Multi Document Context) ist heute der Menchanismus der Wahl in Cursor, auch hierfür gibt es schon umfangreiche Sammlungen, z.B. awesome-mdc (backup Fork hier). Das Prinzip ist ähnlich wie bei den .cursorrules, mit dem entscheidenden Unterschied, dass man die Regeln auf viele Dateien verteilen kann, und über Muster wie *.html, *.py etc. steuert, welche Regeln für welche Dateien gelten.
Im Screenshot zeige ich meinen aktuellen Regelsatz für eine Webanwendung, die ich mit Python Django entwickle. Ich gebe dem Agenten also strukturiert Kontext durch:
- Verwendung eines Frameworks einschließlich Referenzen via @Docs (Schritt 5, s.o.)
- MDC Regeln über die Arbeitsweise mit dem Framework
- MDC Regeln über meinen Qualitätsanspruch (regelmäßig Tests und Quality Tools ausführen, und auftretende Fehler direkt korrigieren bevor ich als Mensch darauf schaue)
- MDC Regeln über die Interaktion: Der Agent erklärt mir jeweils, welche Regel ihn dazu gebracht hat, eine Sache auf eine bestimmte Art umzusetzen, oder fragt nach, falls Regeln im Konflikt stehen sollten

Schritt 7: Ausführlicher Planen
Mache Entwickler fangen an, extrem umfangreich vorab zu planen. Einige schwören darauf, ein anderes Modell zum Planen zu verwenden, als um Coden. Also z.B. Planen mit einem GPT Modell, Anforderungsdokument speichern, z.B. „Requirements.md“, Coden mit einem Claude Modell, Fortschritt pflegen z.B. in „Implemented.md“.
Ich möchte anerkennen, dass dies für größere Neuentwicklungen sinnvoll sein kann und:
Bei bestehenden Anwendungen helfen ganz andere Tricks, um bei der Planung weniger Worte zu brauchen. In diesem Beispiel mit Screenshots zeige ich eine solche Technik: Ich habe selbst drei neue Buttons ohne Funktion eingebaut, aber mit selbsterklärender Beschriftung. Ausgehend davon habe ich das Modell planen lassen, wie sich die Anwendung nun verhalten sollte: Schnelles Planen mit Platzhaltern und Rückfragen
Abschließend stelle ich fest: Planen ist extrem hilfreich, um Agenten in die richtige Richtung laufen zu lassen, mit einigen Tricks kann man die Planung aber auch sehr kurz halten.
Schritt 8: Schnellere Feedbackschleifen
Angenommen ein Mensch einwickelt eine Web-Anwendung systematisch mit automatisierten Tests und es funktioniert etwas nicht wie erwartet. Früher oder später wird er im Browser mit eigenen Augen nachschauen.
Über das Model Context Protocol (MCP) können Tools wir Cursor, Claude Code usw. z.B. einen lokalen MCP Server ansprechen und damit einen Browser steuern.
Das ermöglicht mir Arbeitsabläufe wie in diesem Beispiel mit Screenshots:
- Als Mensch prompte ich sinngemäß „Bitte prüfen und reparieren“, s.o.
- Der Agent prüft das Web UI mit dem Chrome Browser per MCP, bemerkt ein Problem, repariert, prüft erneut. In diesem Beispiel braucht der Agent mehrere solche Anläufe, bis die neue Funktionalität vollumfänglich korrekt funktioniert.
- Als Mensch prüfe ich nur das Endergebnis kurz und abschließend selbst
Bei diesem Schritt geht es nicht primär um eine Technologie (wie MCP), sondern darum, dass der Agent selbst Dinge prüfen kann, ohne auf einen Menschen zu warten. Im o.g. Artikel kommt weiter unten auch vor, dass Cursor mit Hilfe von Curl einen HTTP Endpunkt prüft. Dafür ist kein MCP nötig, Cursor kann das direkt per Kommandozeile. Es geht schnell und direkt. So oder so: Als Mensch möchte ich erst dann ein Ergebnis sehen, wenn der Agent schon technisch und visuell geprüft und sicher gestellt hat, dass auch wirklich alles funktioniert. Dadurch kann ich als Mensch mit wenig Zeit viel mehr bewirken.
Schritt 9: Aus Fehlern lernen
Bei dieser Ebene von Lernen geht es nicht mehr um Details. Durch das schnelle und direkte Feedback (Schritt 8) kann der Agent kleine Probleme unmittelbar selbst erkennen und lösen, aber:
Wenn der Agent doch noch einmal etwas grundsätzlich falsch macht, kann man dies hinterfragen und korrigieren lassen. Zum Abschluss lässt man ihn eine MDC Regeldatei erstellen, die das Problem in Zukunft vermeidet. Danke für diesen Tip an Geoffrey Huntley, (siehe Stdlib , lokales PDF Backup).
Und auch diesen Verbesserungsprozess kann man strukturiert unterstützen. Man kann auch Regeln über das Erstellen und Ablegen von Regeln formulieren. Die in Schritt 6 erwähnte Awesome-MDC Bibliothek enthält sogar auch dafür schon Beispiele.
Disclaimer: Lerne nur ich als Mensch, oder lernt auch die Maschine? Ich (Timon hier) hatte beim automatischen Erstellen von Regeln bisher gemischten Erfolg. Manchmal ergibt sich ein guter Startpunkt, aber bisher habe ich die Regeldateien jeweils noch mit der Hand präzisiert. Diese Zeit ist gut investiert, denn der Hebel ist groß. Mit meinem aktuellen Set aus 11 Regeln (siehe Screenshot im Abschnitt Schritt 6) verhält sich der Agent schon fast immer so, wie ich es brauche und der Unterschied zum Rodeo von früher ist enorm.
Schritt 10: Mehr auf Agenten verlassen
Wenn man die Techniken der Schritte 5-9 systematisch anwendet und weiter verfeinert, kann man sich mit der Zeit immer mehr auf den Agenten verlassen. Wer schon oft die Erfahrung gemacht hat, dass der Agent z.B. innerhalb von 20 Minuten, ohne menschliche Intervention, ein gutes Ergebnis erstellt, fängt vielleicht damit an, 2-3 Sessions parallel laufen zu lassen. Die abschließende Überprüfung durch den Menschen wird dann zum Flaschenhals.
Manche Erfahrungsberichte sind eher nüchtern und sachlich gehalten, z.B. dieser von Sankalp, der auch schön die Historie der Interaktionsmuster über die letzten Jahre beschreibt. Andere wirken eher reißerisch, z.B. dieser von Harper Reed, was mich persönlich eher skeptisch macht. Ich versuche dann, nicht alles wörtlich zu nehmen und prüfe eher für mich, welche Inspiration ich draus ziehen kann. Manche Ideen sind wertvoll für mich, andere nicht:
Einzelne Entwickler beschreiben, dass sie den Quellcode nicht mehr anschauen, vom Agenten direkt ins Repository committen lassen und deswegen auch keine IDE mehr verwenden. Tools wie Aider und Claude-Code werden dann nicht mehr als Ergänzung zur IDE verwendet, sondern als primäres Arbeitswerkzeug.
Disclaimer: Ich (Timon hier) verlasse mich mehr als früher, aber sicher noch nicht vollständig, auf Agenten. Ich verfeinere die Techniken der Schritte 5-9 systematisch weiter und ich bin weiterhin ein Fan von Leitplanken: Nach verschiedenen Erfahrungen aus Schritt 4, laufen die Tools bei mir in einer virtuellen Maschine. Automatisches Committen ist für mich ein no-go, ich schaue den Code weiterhin durch und verwende deswegen auch weiterhin eine IDE.
Mehr als je zuvor erkenne ich in Demut, dass es unglaublich viele Dinge gibt, die ich gern wüsste und könnte. Und es werden jeden Tag mehr. Zumindest weiß ich nun genauer als früher, wonach ich suche. Diese Reise fängt gerade erst an und sie wird länger.
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

Dr. Timon Fiddike
- Seit 2010 auf dem Pfad der Agilität
- Seit 2005 KI, AI, Machine Learning, siehe Werdegang
- Erfahrung als Entwickler im Team, Product Owner, Scrum Master, Geschäftsführer und Coach
- Höchste Zertifizierung: Certified Scrum Trainer® (weltweit ca. 220 Personen) für die Scrum Alliance®
- Erfahrung in Startup, Mittelstand & Konzern
- Integraler Coach – Ausbildung nach ICF ACTH-Standard
- Unterstützt mit Begeisterung das menschliche Wachstum, das agile Arbeit ermöglicht
- Geschäftsführer Agile.Coach GmbH & Co. KG