Beim Review einer KI-gestützten Änderung liegt der Engpass selten im Prompt. Entscheidend ist, ob nachvollziehbar bleibt, welches Ziel die Änderung verfolgt, welche Annahmen eingeflossen sind und was bereits geprüft wurde. Fehlen diese Angaben, muss der Reviewer den Kontext aus Code, Tickets und Vermutungen zusammensuchen.
Eine vollständige Eingabehistorie ist dafür nicht nötig. Dein Team braucht eine kompakte Übergabe, die Entscheidungen nachvollziehbar macht. Der Pull Request wird damit zum Prüfauftrag statt zum Ablageort für fertigen Code.
Der Pull Request muss die Änderung prüfbar machen
Ein Pull Request, kurz PR, ist die Anfrage, eine Codeänderung vor der Übernahme in den Hauptentwicklungszweig zu prüfen. Bei manuell geschriebenem Code kann ein Reviewer häufig aus Tickets, Commits und bekannten Konventionen ableiten, wie die Änderung entstanden ist. KI-generierter Code sieht dagegen schnell plausibel aus, obwohl er Anforderungen ergänzt, Randfälle ignoriert oder unnötig große Bereiche verändert hat.
Deshalb reicht der Hinweis „mit KI erstellt“ nicht. Der Name des verwendeten Modells sagt nichts darüber aus, ob Berechtigungen geprüft, Datenbankänderungen verstanden oder bestehende Projektkonventionen eingehalten wurden.
Eine brauchbare Übergabe beantwortet stattdessen vier Fragen:
- Welches fachliche Ziel verfolgt die Änderung?
- Welche Dateien, Datenflüsse und Nutzergruppen sind betroffen?
- Welche Prüfungen wurden ausgeführt und mit welchem Ergebnis?
- Welche Annahmen oder Unsicherheiten bleiben offen?
Diese Informationen helfen unabhängig davon, ob ein Entwickler einen Chat-Assistenten, eine IDE-Funktion oder einen eigenständig arbeitenden Coding-Agenten verwendet hat. Das Werkzeug ist Kontext. Verantwortlich bleibt die Person, die den Pull Request eröffnet.
Definiere die Übergabe schon vor der Generierung
Eine schlechte Übergabe beginnt meist mit einer unklaren Aufgabe. Wenn die Anweisung nur „Baue einen CSV-Export für Bestellungen“ lautet, muss das Modell wesentliche Entscheidungen selbst treffen: Wer darf exportieren? Welche Spalten gehören hinein? Wie werden personenbezogene Daten behandelt? Gilt der aktuelle Filter? Wie groß darf der Export werden?
Diese Fragen verschwinden nicht, wenn der erzeugte Code funktioniert. Sie tauchen lediglich später im Review oder im Betrieb wieder auf.
Formuliere deshalb vor der KI-Nutzung einen kleinen Arbeitsrahmen. Er sollte das Ziel, die Grenzen und die Abnahmekriterien enthalten. Für den CSV-Export könnte er so aussehen:
- Der Export ist nur für bestehende Benutzer mit der Rolle „Verwaltung“ erreichbar.
- Er übernimmt den aktuell gesetzten Zeitraumfilter.
- Interne Notizen und Zahlungsdaten werden nicht ausgegeben.
- Die vorhandene Berechtigungsprüfung wird weiterverwendet.
- Änderungen an der Datenbankstruktur sind nicht Teil der Aufgabe.
- Bei unklaren Feldzuordnungen soll die Bearbeitung stoppen, statt neue Regeln zu erfinden.
Der letzte Punkt ist besonders nützlich. Eine Stop-Bedingung legt fest, wann die KI keine eigenständige Entscheidung treffen darf. Das verhindert nicht jeden Fehler, reduziert aber still ergänzte Anforderungen.
Wenn du Quellcode, Fehlermeldungen oder Beispieldaten in ein externes KI-System eingibst, musst du außerdem vorher klären, welche Informationen das Projekt verlassen dürfen. Der Artikel KI-Prompts in der Webentwicklung: Welche Projektdaten darfst du eingeben? zeigt, wie du dafür einen belastbaren Rahmen festlegst.
Dokumentiere Entscheidungen statt Chatverläufe
Ein kompletter Prompt-Verlauf wirkt gründlich, ist für Reviewer aber selten hilfreich. Er enthält verworfene Ansätze, Wiederholungen und Antworten, die im endgültigen Code keine Rolle mehr spielen. Der Reviewer müsste erst rekonstruieren, welche Aussagen noch gelten.
Halte während der Umsetzung stattdessen eine kurze Arbeitsnotiz fest. Darin landen ausschließlich Entscheidungen, Abweichungen und ungeklärte Punkte, die für die spätere Prüfung relevant sind.
Für das Export-Beispiel wären das etwa folgende Einträge:
- Die bestehende Berechtigungsrichtlinie konnte unverändert verwendet werden.
- Der erste Vorschlag hat ungefiltert alle Bestellungen geladen und wurde verworfen.
- Die Feldzuordnung für die Kundennummer wurde anhand des bestehenden Adminbereichs geprüft.
- Das Verhalten bei sehr großen Exporten ist nicht Bestandteil dieser Änderung und bleibt offen.
Diese Notiz beschreibt weder jeden Prompt noch jede Korrektur. Sie zeigt, wo das Ergebnis von der ursprünglichen Generierung abwich und wo der Reviewer genauer hinsehen sollte.
Baue die PR-Beschreibung als Prüfauftrag auf
Eine einheitliche PR-Struktur spart Rückfragen und verhindert, dass jede Person ihre eigene Form der KI-Offenlegung erfindet. Die Beschreibung muss nicht lang sein. Sie sollte jedoch konkrete Nachweise statt pauschaler Aussagen enthalten.
Ziel und Umfang
Beschreibe in wenigen Sätzen, welches Nutzerproblem gelöst wird und welche Bereiche verändert wurden. „CSV-Export ergänzt“ ist zu knapp. Besser ist: „Mitarbeiter mit Verwaltungsrolle können die aktuell gefilterte Bestellliste ohne interne Notizen als CSV exportieren.“
Ergänze ausdrücklich, was nicht zum Umfang gehört. Damit verhinderst du, dass ein Reviewer fehlende Funktionen mit übersehenen Anforderungen verwechselt.
Art der KI-Unterstützung
Notiere, wofür KI eingesetzt wurde. Mögliche Angaben sind die Erstellung eines ersten Entwurfs, die Überarbeitung einzelner Funktionen, die Generierung von Tests oder die Erklärung bestehenden Codes. Eine allgemeine Kennzeichnung des gesamten PRs ist weniger nützlich, wenn nur eine isolierte Hilfsfunktion betroffen war.
Die Modellversion ist nur dann relevant, wenn dein Unternehmen sie aus internen Gründen dokumentiert. Für die fachliche Prüfung sind Einsatzbereich und Ergebnis wichtiger als der Produktname.
Ausgeführte Prüfungen
Schreibe nicht lediglich „getestet“. Nenne die tatsächlich ausgeführten Prüfungen und die geprüften Fälle. Dazu können automatisierte Tests, eine manuelle Rollenprüfung, ein Export mit leerer Ergebnismenge oder die Kontrolle der CSV-Spalten gehören.
Grüne Tests belegen nur das Verhalten, das diese Tests abdecken. Wurden Tests und Implementierung aus derselben unklaren Anforderung generiert, können beide denselben Denkfehler enthalten. Mindestens ein Prüfpunkt sollte deshalb direkt aus dem fachlichen Akzeptanzkriterium abgeleitet sein.
Offene Annahmen und Risiken
Dieser Abschnitt darf nicht aus Gewohnheit mit „keine“ gefüllt werden. Notiere offene Entscheidungen, ungewöhnliche Abhängigkeiten und Bereiche, die bewusst nicht geprüft wurden. Auch ein scheinbar kleiner Hinweis wie „keine Prüfung mit mehr als 10.000 Datensätzen durchgeführt“ hilft dem Reviewer, die Reichweite der bisherigen Prüfung einzuordnen.
Hinweise für den Reviewer
Markiere die Stellen, an denen fachliche Aufmerksamkeit nötig ist. Beim Export wären das die Berechtigungsprüfung, die Auswahl personenbezogener Felder und die Übernahme des Filters. Der Reviewer muss dann nicht jede Datei mit derselben Intensität lesen.
Teile Verantwortung zwischen Autor und Reviewer sinnvoll auf
Der Autor des Pull Requests übernimmt die Verantwortung für die eingereichte Änderung. Er muss generierten Code lesen, offensichtliche Nebenänderungen entfernen und die genannten Prüfungen selbst nachvollziehen. „Die KI hat das so vorgeschlagen“ ist keine technische Begründung.
Der Reviewer prüft anschließend nicht die Qualität des Prompts. Er prüft, ob die Änderung zum Ticket passt, in das bestehende Projekt gehört und ausreichend abgesichert ist. Dabei sollte er besonders auf Stellen achten, an denen Modelle plausible Ergänzungen erzeugen können: neue Abstraktionen, zusätzliche Abhängigkeiten, erfundene Hilfsmethoden oder still veränderte Fehlerbehandlung.
Eine zweite KI kann das Review unterstützen, etwa durch Hinweise auf ungeprüfte Pfade. Sie ersetzt aber nicht die unabhängige Bewertung. Wenn dieselbe unvollständige Aufgabenbeschreibung sowohl Implementierung als auch Review steuert, bestätigt die zweite Ausgabe womöglich nur denselben falschen Ausgangspunkt.
Für die technische Einzelprüfung kannst du zusätzlich die Checkliste für generierten Code in Webprojekten verwenden. Die PR-Übergabe und die Codeprüfung erfüllen unterschiedliche Aufgaben: Die Übergabe liefert den Kontext, die Checkliste unterstützt die Kontrolle der Umsetzung.
Erhöhe die Prüftiefe nach Risiko
Nicht jede KI-gestützte Änderung braucht denselben Aufwand. Eine Textkorrektur im internen Administrationsbereich hat andere Folgen als eine Änderung an Anmeldung, Rollen oder Zahlungsabläufen. Lege deshalb im Team fest, welche Bereiche eine zusätzliche Freigabe benötigen.
Eine strengere Prüfung ist typischerweise sinnvoll bei Änderungen an:
- Anmeldung, Sitzungen und Passwortprozessen,
- Rollen, Berechtigungen und Mandantentrennung,
- Zahlungen, Rechnungen und verbindlichen Preisberechnungen,
- Verarbeitung oder Export personenbezogener Daten,
- Datenbankmigrationen und Löschvorgängen,
- öffentlichen Schnittstellen und Webhooks,
- neuen Paketen oder externen Diensten.
Für solche Änderungen kann dein Prozess eine zweite fachkundige Freigabe, zusätzliche Tests oder eine getrennte Prüfung der Datenflüsse verlangen. Bei einer kleinen, klar abgegrenzten Darstellungskorrektur genügt dagegen meist der normale Reviewprozess mit knapper KI-Notiz.
Diese Abstufung verhindert zwei Extreme: unsichtbare KI-Nutzung ohne Kontext und ein bürokratisches Sonderverfahren für jede generierte Zeile.
Führe den Workflow mit einem echten Pull Request ein
Eine neue Richtlinie wird schnell zu umfangreich, wenn sie alle denkbaren Fälle vorab regeln soll. Starte stattdessen mit einer PR-Vorlage und einer klaren Verantwortungsregel. Beides lässt sich an einer überschaubaren Änderung erproben.
- Wähle eine kleine Aufgabe mit klaren Akzeptanzkriterien.
- Definiere vor der Generierung Umfang, ausgeschlossene Bereiche und Stop-Bedingungen.
- Halte während der Arbeit nur relevante Entscheidungen und verworfene Vorschläge fest.
- Eröffne den Pull Request mit Ziel, KI-Einsatz, Prüfnachweisen und offenen Annahmen.
- Lass den Reviewer markieren, welche Informationen für die Prüfung fehlten oder überflüssig waren.
- Passe die Vorlage anhand dieses Feedbacks an und verwende sie anschließend verbindlich.
Nach einigen Änderungen wird sichtbar, welche Felder dein Team tatsächlich benötigt. Agenturen können zusätzlich projektspezifische Regeln ergänzen, wenn Kunden bestimmte Werkzeuge ausschließen oder besondere Anforderungen an den Umgang mit Projektinformationen stellen. Solche Vorgaben gehören in die Projektvereinbarung und nicht versteckt in einzelne Pull Requests.
Eine gute Übergabe macht KI-Code unspektakulär prüfbar
KI-generierter Code braucht keinen eigenen Parallelprozess. Er braucht einen Pull Request, der fachliches Ziel, betroffene Bereiche, ausgeführte Prüfungen und verbleibende Unsicherheiten offenlegt. Der Reviewer soll die Änderung beurteilen können, ohne Prompt-Verläufe zu lesen oder die Generierung nachzustellen.
Wenn dein Team diese Informationen verbindlich erfasst und die Prüftiefe am Risiko ausrichtet, wird KI-Unterstützung im Entwicklungsworkflow handhabbar. Entscheidend ist nicht, ob jede Zeile von einem Menschen getippt wurde. Entscheidend ist, ob ein Mensch die Änderung verstanden, geprüft und verantwortlich übergeben hat.
Häufige Fragen
Kurz beantwortet, damit du schneller einschätzen kannst, was für dein Projekt wichtig ist.
Muss jeder KI-generierte Code im Pull Request gekennzeichnet werden?
Das hängt von euren Projektregeln ab. Sinnvoll ist eine Kennzeichnung immer dann, wenn die KI wesentliche Teile der Lösung, Tests oder technische Entscheidungen beeinflusst hat. Eine feste Teamregel verhindert Einzelfalldiskussionen.
Sollte der vollständige Prompt-Verlauf in den Pull Request?
Meist nicht. Dokumentiere stattdessen das fachliche Ziel, relevante Annahmen, verworfene Vorschläge, ausgeführte Prüfungen und offene Risiken. Der komplette Verlauf erschwert häufig die Prüfung, statt sie zu unterstützen.
Wer trägt die Verantwortung für KI-generierten Code?
Die Person, die den Pull Request einreicht, muss den Code verstehen und für die Änderung einstehen. Das verwendete KI-Werkzeug übernimmt weder die fachliche Freigabe noch die Verantwortung für Folgen im Projekt.
Wann braucht KI-generierter Code eine zusätzliche Prüfung?
Eine zusätzliche Prüfung ist besonders bei Berechtigungen, personenbezogenen Daten, Zahlungen, Datenbankmigrationen, öffentlichen Schnittstellen und neuen Abhängigkeiten sinnvoll. Die Prüftiefe sollte sich am möglichen Schaden orientieren.
