KI-generierter Code braucht trotzdem einen Verantwortlichen

KI kann in wenigen Minuten Komponenten, API-Routen, Tests und Migrationsskripte erzeugen. Das ist produktiv – bis niemand mehr erklären kann, warum der Code so gebaut wurde.

Das eigentliche Risiko von AI-assisted Coding ist nicht, dass jede Ausgabe schlecht wäre. Das Risiko ist Geschwindigkeit ohne Verantwortung. Mehr Code erreicht schneller das Repository, während Review, Architekturverständnis und Dokumentation nicht automatisch mitwachsen.

Der falsche Produktivitätsindikator

Viele Teams messen, wie schnell ein Ticket abgeschlossen oder ein Pull Request eröffnet wird. Für den Betrieb zählt aber etwas anderes:

• Ist die Änderung verständlich?
• Passt sie zur bestehenden Architektur?
• Sind Fehler- und Missbrauchsfälle abgedeckt?
• Kann das Team sie später sicher ändern?
• Ist klar, wer die Entscheidung verantwortet?

Ein AI-Tool kann Review-Hinweise liefern. GitHub weist jedoch ausdrücklich darauf hin, dass Copilot-Code-Reviews Kommentare hinterlassen und keine erforderliche menschliche Freigabe ersetzen. Genau diese Grenze ist wichtig: Automatisches Feedback ist eine zusätzliche Prüfung, kein Eigentümer der Änderung.

Wo KI-generierter Code teuer wird

1. Er löst das sichtbare Problem, nicht das Systemproblem

Ein Prompt beschreibt meist die gewünschte Funktion, aber nicht alle Architekturregeln, Datenflüsse, Compliance-Anforderungen und historischen Kompromisse des Projekts. Das Ergebnis kann lokal funktionieren und trotzdem eine zweite konkurrierende Abstraktion einführen.

2. Sicherheitsannahmen bleiben unsichtbar

Authentifizierung, Autorisierung, Rate Limits, Datenvalidierung, Secret Handling und Logging müssen im Kontext bewertet werden. Ein plausibel aussehender Endpoint ist nicht automatisch sicher.

3. Tests bestätigen nur die erzeugte Annahme

Wenn dieselbe Generation Implementierung und Tests schreibt, können beide denselben Denkfehler teilen. Gute Tests brauchen unabhängige Akzeptanzkriterien und reale Fehlerszenarien.

4. Niemand fühlt sich zuständig

„Das hat die KI geschrieben“ ist keine technische Erklärung und keine Incident-Strategie. Jede Änderung braucht einen Menschen, der sie geprüft hat und im Zweifel vertreten kann.

Ein praktikables Review-Modell

AI-generierter Code sollte nicht gesondert stigmatisiert, aber konsequent geprüft werden. Ein sinnvoller Prozess umfasst:

1. Problem und Akzeptanzkriterien vor der Generierung festhalten. Sonst bewertet das Team nur, ob der Code überzeugend aussieht.
2. Kleine Diffs bevorzugen. Große generierte Änderungen sind schwerer zu verstehen und leichter durchzuwinken.
3. Architektur- und Sicherheitsgrenzen dokumentieren. Repository Instructions helfen Tools, ersetzen aber nicht Review.
4. Unabhängige Prüfungen ausführen. Typecheck, Tests, Linting, Dependency Checks und Security Scans müssen außerhalb der Modellantwort laufen.
5. Kritische Pfade manuell testen. Login, Rollen, Zahlungen, personenbezogene Daten, Uploads und Webhooks verdienen echte End-to-End-Prüfung.
6. Entscheidungen dokumentieren. Warum wurde diese Lösung gewählt, welche Alternativen wurden verworfen und welche Risiken bleiben?

Schnelltest für Teams

• Können Reviewer erkennen, welche Teile AI-assisted entstanden sind, ohne daraus eine Ausrede zu machen?
• Gibt es klare Regeln für sicherheitskritische Änderungen?
• Müssen generierte Migrationen und Berechtigungen separat geprüft werden?
• Werden Tests aus Anforderungen abgeleitet statt nur aus der Implementierung?
• Verhindern Branch-Regeln das Mergen ohne menschliche Freigabe?
• Gibt es jemanden, der die Änderung nach dem Merge betreiben kann?

Wenn mehrere Antworten nein lauten, beschleunigt das Tool vermutlich nicht nur Delivery, sondern auch technische Schulden.

Was Website-Pflichtencheck prüfen würde

Ein technischer Review betrachtet nicht, ob KI benutzt wurde, sondern ob der resultierende Entwicklungsprozess belastbar ist. Geprüft werden Review-Regeln, Branch Protection, Testabdeckung, Sicherheitsgrenzen, Dependency-Änderungen, Dokumentation, Observability und Wartbarkeit kritischer Pfade.

Das ist besonders sinnvoll nach schnellen MVP-Phasen, größeren AI-assisted Refactorings oder wenn ein Projekt viele Funktionen gewonnen, aber wenig gemeinsames Architekturverständnis aufgebaut hat.

KI darf Code erzeugen. Verantwortung kann sie nicht übernehmen. Wenn niemand eine Änderung erklären, testen und im Incident vertreten kann, war sie nicht wirklich fertig – nur schnell gemergt.