Ein KI-Assistent kann aus einer kurzen Anfrage einen umfangreichen Diff machen. Bei einer klaren Aufgabe ist das hilfreich. Bei einer mehrdeutigen Aufgabe entsteht ebenso schnell eine überzeugende Implementierung einer Entscheidung, die niemand getroffen hat. Teuer wird es im Review, wenn das Team merkt, dass der Code eine andere Frage beantwortet.
Meine Regel für KI-gestützte Entwicklung ist einfach: Eine Entscheidung muss klein genug zum Prüfen sein, bevor ihre Implementierung groß genug zum Warten wird. Fortschritt bemisst sich an einer überprüften Verhaltensänderung statt an der Menge des erzeugten Codes.
Mit dem Verhalten beginnen, dann die Grenze benennen
Nehmen wir die Aufgabe, einem Marktplatz Stornierungen hinzuzufügen. Ein Button und ein Endpoint lassen sich leicht beschreiben. Schwieriger ist, wer stornieren darf, bis zu welchem Bestellstatus und was Kundinnen und Kunden sehen, während ein anderes System nachzieht. Bleiben diese Fragen offen, kann die Implementierung Produktregeln erfinden.
Vor dem Auftrag zum Programmieren hilft eine kurze Beschreibung, die das sichtbare Ergebnis vom Mechanismus trennt. Ein erster Schritt könnte lauten: Käufer können die Stornierung einer unbezahlten Bestellung anfordern; bezahlte Bestellungen werden abgelehnt; wiederholte Anfragen geben den bestehenden Stornierungsstatus zurück. Erstattungen und Benachrichtigungen an Verkäufer brauchen eigene Entscheidungen.
- Ergebnis: das Verhalten, das Nutzer oder Betrieb beobachten sollen.
- Rahmenbedingungen: bestehende Berechtigungen, Zustandsübergänge und Schnittstellen, die einzuhalten sind.
- Offene Fragen: Punkte, die eine Produktentscheidung oder Belege aus dem Repository brauchen.
- Nachweise: Beispiele, anhand derer sich die Richtigkeit prüfen lässt.
Diese Beschreibung macht Widerspruch günstig. Im Review lässt sich die Regel für bezahlte Bestellungen hinterfragen, bevor sie über UI, API und mehrere Tests verteilt ist. Der Prompt dient hier als kompakter Entscheidungsstand, der sich noch vor dem ersten Code korrigieren lässt.
Vor der Lösung eine Karte des Repositorys anfordern
Eine plausible Lösung kann trotzdem an der falschen Stelle landen. Der Assistent sollte den aktuellen Einstiegspunkt, den Ort der Geschäftsregel und die bestehende Test- oder Integrationsgrenze benennen. Dazu gehören Dateiverweise und eine Erklärung, welchen Weg eine Anfrage durch die Anwendung nimmt.
Diese Karte muss gelesen werden. Kann der Assistent die Berechtigungsprüfung nicht finden oder nicht erklären, wo der Bestellstatus gespeichert wird, fehlt der Kontext für eine breite Änderung. Dann hilft ein engerer Untersuchungsauftrag oder eine eigene Klärung. Mehr Implementierungsdetails reparieren kein falsches Bild des Systems.
Bestehende Konventionen verdienen Aufmerksamkeit, auch wenn eine neue Abstraktion elegant wirkt. Eine zweite Art der Request-Validierung zwingt spätere Maintainer zur Wahl zwischen zwei Mustern. Die Aufgabenbeschreibung sollte klären, ob das vorhandene Design erweitert oder ein Teil bewusst ersetzt werden soll.
Vorschlag und Umsetzung trennen
Bei Änderungen mit mehreren Teilen hilft zuerst ein kurzer Vorschlag: voraussichtlich betroffene Dateien, gewünschtes Verhalten und der wichtigste Fehlerfall. Ein guter Vorschlag benennt eine Abwägung. „Service-Schicht ergänzen“ beschreibt eine Form; „Stornierungsregeln bündeln, damit UI und Webhook nicht widersprechen“ liefert einen Grund.
Danach folgt ein Schritt, der sich eigenständig prüfen lässt. Im Stornierungsbeispiel beginnt das mit der Zustandsregel und dem API-Verhalten. Sobald beides feststeht, kommt die Interaktion hinzu. So wird eine falsche Annahme nicht zum Fundament eines großen Patches.
Auch kleine Änderungen brauchen vollständiges Verhalten. Ladezustände, Ablehnung und erneute Versuche gehören dazu, wenn sie Nutzer betreffen. Die Aufteilung soll Entscheidungen leichter prüfbar machen, ohne unfertiges Verhalten hinter einer erfolgreichen Demo zu verstecken.
Die wahrscheinlich falsche Annahme prüfen
Ein erfolgreicher Typecheck zeigt, dass die Implementierung zu den deklarierten Typen passt. Er belegt nicht, dass das gewünschte Verhalten richtig ist. Akzeptanzbeispiele sollten unabhängig vom vorgeschlagenen Code entstehen und anschließend dessen Prüfung leiten.
- Eine unbezahlte Bestellung des Käufers akzeptiert die Stornierung.
- Eine unbezahlte Bestellung eines anderen Käufers wird abgelehnt.
- Eine bezahlte Bestellung wird ohne Zustandsänderung abgelehnt.
- Eine wiederholte Anfrage liefert ein konsistentes Ergebnis und wiederholt keine Seiteneffekte.
- Konkurrieren Zahlung und Stornierung, folgt das Ergebnis der vereinbarten Regel für Zustandsübergänge.
Diese Beispiele sind eine Review-Checkliste; eine echte Implementierung muss die relevanten Fälle an der passenden Grenze prüfen. Das letzte Beispiel ist besonders wertvoll, weil es eine Annahme hinterfragt, die eine Happy-Path-Demo nicht berührt. Der passende Nachweis hängt von der Änderung ab: Eine reine Regel kann einen Unit-Test brauchen, konkurrierende Schreibvorgänge müssen am Speichermechanismus geprüft werden.
Der Assistent sollte berichten, was er tatsächlich ausgeführt hat, was bestanden wurde und was ungeprüft bleibt. Ist eine Integration nicht verfügbar, gehört diese Einschränkung in den Bericht. Fertigstellung muss sich auf Nachweise zurückführen lassen, die andere prüfen können.
Auch die Wartungskosten prüfen
Vor dem Merge lohnt es sich, den Diff aus Sicht der Person zu lesen, die später Fehler sucht. Kam eine Abhängigkeit hinzu? Wurde eine Geschäftsregel dupliziert, eine öffentliche Schnittstelle erweitert oder ein Fallback eingebaut, der Fehler verdeckt? Alles kann gerechtfertigt sein, braucht aber eine Begründung.
Eine hilfreiche Schlussfrage lautet: Könnte ein Kollege die Änderung anhand der Anforderung und des Diffs erklären, ohne den Chat zu öffnen? Falls nicht, gehört die fehlende Begründung in den Pull Request oder ins Repository. Die Unterhaltung ist Arbeitskontext; Maintainer brauchen eine dauerhafte Erklärung.
KI-Unterstützung ist für mich dann am nützlichsten, wenn sie den Weg von einer klaren Entscheidung zu einem überprüften Ergebnis verkürzt. Diesen Ablauf würde ich an Review-Aufwand, Fehlern und der Einfachheit der nächsten Änderung messen. Ein größerer Patch fällt schnell auf; ein leichter verständliches System ist das Ergebnis, auf das es ankommt.
Beispiele für Entscheidungen, die klare Grenzen brauchen, bietet Ein Marktplatz-MVP bauen, der seinen eigenen Erfolg übersteht.
