Arbeitsprozess
Der KI-Coding-Workflow für verlässliche Software
Gute Ergebnisse entstehen nicht durch einen magischen Prompt. Sie entstehen durch einen kurzen, wiederholbaren Loop, in dem Ziel, Kontext, Umsetzung und Verifikation klar getrennt sind.
Das Wichtigste in Kürze
- Akzeptanzkriterien sind wichtiger als lange Wunschlisten.
- Kleine Diffs sind leichter zu prüfen und zurückzurollen.
- Browser- und Produktionsprüfung sind Teil der Entwicklung.
- Der nächste Schritt beginnt erst, wenn der aktuelle Stand nachvollziehbar stabil ist.
Der Loop in sechs Phasen
- 1
Ziel
Beschreibe beobachtbares Nutzerverhalten und klare Nicht-Ziele.
- 2
Kontext
Relevante Dateien, Konventionen, Fehlermeldungen und Constraints sammeln.
- 3
Plan
Datenfluss, Dateien, Fehlerfälle und Testweg vor der Änderung prüfen.
- 4
Implementierung
Den kleinsten vollständigen vertikalen Schritt umsetzen.
- 5
Verifikation
Tests, Build, Browser, Konsole und Netzwerk prüfen.
- 6
Lernen
Diff bereinigen, Entscheidung dokumentieren und stabilen Stand sichern.
Die Schleife bleibt nur dann kontrollierbar, wenn jeder Durchlauf klein genug für einen vollständigen Review ist. Begrenze nicht allein die Zahl der Dateien, sondern die fachliche Wirkung: Eine Änderung sollte genau ein beobachtbares Verhalten hinzufügen oder korrigieren. So lassen sich fehlgeschlagene Ansätze entfernen, ohne bereits geprüfte Teile wieder aufzureißen.
Anatomie eines guten Auftrags
| Baustein | Beispiel |
|---|---|
| Ziel | Nutzer kann eine Rechnung als PDF herunterladen |
| Kontext | Bestehende Rechnungs-API und UI-Komponenten wiederverwenden |
| Constraints | Keine neue PDF-Abhängigkeit; Berechtigung serverseitig |
| Akzeptanz | Eigene Rechnung 200, fremde 404, mobile Schaltfläche sichtbar |
| Verifikation | API-Test, Build und Browser-Happy-Path |
Ergänze im Auftrag ausdrücklich relevante Nicht-Ziele. Wenn eine Validierung geändert wird, kann etwa feststehen, dass Datenmodell, Texte und API-Format unverändert bleiben. Nicht-Ziele schützen vor gut gemeinten Nebenverbesserungen des Agenten und machen im Diff sofort sichtbar, ob der vereinbarte Änderungsbereich überschritten wurde.
Debugging ohne Prompt-Pingpong
- Exakte Fehlermeldung sichern
- Minimalen reproduzierbaren Ablauf notieren
- Letzten funktionierenden Stand bestimmen
- Konsole, Netzwerk und Serverlog trennen
- Eine Ursache als Hypothese formulieren
- Gezielten Test vor der nächsten Änderung definieren
Fordere bei jeder Hypothese eine überprüfbare Beobachtung aus Log, Test oder Quellcode. Aussagen wie „wahrscheinlich ein Cache-Problem“ sind erst nützlich, wenn ein Experiment sie von anderen Ursachen unterscheidet. Lösche temporäre Logs nach der Diagnose oder gestalte sie datenschutzkonform, damit Debugging keine sensiblen Informationen dauerhaft in Produktion hinterlässt.
Wann ist eine KI-Änderung fertig?
- Akzeptanzkriterien sind nachweislich erfüllt.
- Relevante automatische Tests laufen.
- Happy Path und wichtigster Fehlerfall wurden visuell geprüft.
- Keine neuen Konsolen- oder Netzwerkfehler.
- Diff enthält keine unbeabsichtigten Nebenänderungen.
- Rollback-Weg ist klar.
Die Definition of Done sollte auch den Betrieb abdecken: Migration rückwärts kompatibel, Monitoring angepasst, Supporttext aktualisiert und Rückrollweg geprüft. Nicht jeder Punkt gilt für jede Änderung. Entscheidend ist, die Liste nach Risiko zu verkleinern, statt sie pauschal zu ignorieren, weil ein umfangreicher Standardprozess im Alltag zu schwer wäre.
Ein kompaktes Review-Protokoll für Agenten-Änderungen
Vier kurze Nachweise reichen oft, um eine Änderung später sicher zu verstehen und weiterzuführen.
- Ziel und Akzeptanzkriterien sind im Commit oder in der zugehörigen Aufgabe nachvollziehbar.
- Der Diff enthält keine unerklärten Dateien, Abhängigkeiten oder Formatierungsänderungen.
- Automatische Tests und ein manueller Kernablauf wurden mit Ergebnis dokumentiert.
- Bekannte Grenzen, verbleibende Risiken und ein Rückrollweg sind ausdrücklich benannt.
Das Protokoll muss kein langes Dokument sein. Eine präzise Commit-Beschreibung oder ein kurzer Abschnitt in der Aufgabe genügt, solange eine andere Person das Ergebnis reproduzieren kann. Besonders wichtig sind negative Informationen: Welche Alternative wurde verworfen, welcher Randfall bleibt offen und warum ist die aktuelle Lösung für den gegebenen Umfang vertretbar?
Bewahre auch fehlgeschlagene Prüfergebnisse in knapper Form auf. Wenn ein Test wegen einer bekannten externen Abhängigkeit nicht laufen konnte, ist das kein grüner Nachweis und darf nicht stillschweigend verschwinden. Markiere den offenen Punkt mit Verantwortlichem und Termin. So verhindert der Workflow, dass Zeitdruck eine unbekannte Lücke in eine vermeintlich abgeschlossene Änderung verwandelt.
Überprüfe regelmäßig, ob der Prozess tatsächlich kleinere Fehler und schnellere Reviews erzeugt. Wenn Protokolle nur kopiert werden, aber niemand offene Risiken verfolgt, reduziere die Vorlage auf die entscheidenden Felder. Ein guter Workflow macht Unsicherheit sichtbar und erleichtert Entscheidungen; er soll keine zusätzliche Dokumentationsschicht ohne Wirkung schaffen. Besprich wiederkehrende Lücken im nächsten Team-Rückblick und passe die Prüfschritte an.
Häufige Fragen
FAQ
Wie groß sollte ein Auftrag an einen Coding-Agenten sein?
So klein, dass du das Ergebnis in einem Diff verstehen und mit einem klaren Ablauf testen kannst. Ein vollständiger Nutzerfluss ist eine gute Einheit.
Soll die KI selbst Tests schreiben?
Ja, aber du definierst, welches Verhalten abgesichert werden muss, und kontrollierst, ob die Tests tatsächlich den Fehler erkennen.
Wie verhindere ich, dass der Agent zu viel ändert?
Nenne relevante Dateien und Nicht-Ziele, verlange zuerst einen Plan und prüfe nach der Umsetzung Dateiliste und Diff.
Wie groß sollte ein einzelner Schritt im KI-Coding-Workflow sein?
Er sollte ein beobachtbares Verhalten vollständig ändern und noch in einem konzentrierten Review verständlich bleiben. Wenn mehrere unabhängige Akzeptanzkriterien, Migrationen und Oberflächen betroffen sind, teile die Arbeit in nacheinander testbare Schritte.