Dieser Leitfaden ergänzt den Blog-Artikel „AI-Code reviewen ist ein anderer Job" mit konkreten Ansätzen, die jedes Team — vom Junior bis zum Senior — sofort umsetzen kann.
Der Trichter: AI-Code in Schichten reviewen
AI-Code hat selten Probleme auf Zeilenebene. Die Fehler liegen weiter oben: falsche Stelle im System, falsches Pattern, falsche Annahme. Deshalb lohnt es sich, von außen nach innen zu arbeiten — und bei jeder Schicht zu entscheiden, ob man tiefer geht oder sofort zurückweist.
- Architektur: Gehört das hierhin? Welcher Service, welches Modul? Passt die Verantwortung? Wenn die AI ein neues Modul angelegt hat, das in einen bestehenden Service gehört — Reject auf Architekturebene. Gar nicht erst in den Code einsteigen. Dreißig Sekunden statt dreißig Minuten.
- Konventionen: Folgt das unseren Patterns? Fehlerbehandlung, Logging, Kommunikation zwischen Services, Modulstruktur. Ein Scan auf Strukturebene. Keine Zeile Logik lesen, nur schauen: Sieht das aus wie unser Code, oder wie generischer Lehrbuch-Code? Wenn es gegen Projektkonventionen verstößt — zurück, bevor man sich in Details verliert.
- Duplikate: Gibt es das schon? Schnelle Suche in der Codebasis. AI baut gerne neu, was es schon gibt. Wenn die generierte Utility-Klasse eine Kopie von etwas ist, das im Shared-Library-Repository liegt — zurück. Kein Grund, weiterzulesen.
- Implementierung: Erst jetzt der Code. Und auch hier nicht Zeile für Zeile, sondern gezielt: Wie geht es mit Fehlern um? Was passiert unter Last? Welche Annahmen stecken in den Tests? Welche Edge Cases fehlen?
Sechs Praktiken für den Alltag
- Vor dem Review: Kontext laden, nicht nur den Diff. Bevor du eine Zeile liest, schau dir an, wo der Code landet. Welcher Service? Welches Modul? Welche Nachbarn hat er? Welche Konventionen gelten dort? Fünf Minuten Orientierung sparen dreißig Minuten Fehlersuche.
- Die „Warum so?"-Frage als Standardfrage. Bei menschlichem Code kannst du den Autor fragen: Warum hast du das so gelöst? Bei AI-Code gibt es keinen Autor. Also stell dir die Frage selbst — für jede Designentscheidung im generierten Code. Wenn du keine Antwort hast, ist das ein Warnsignal.
- Gegen die Projektdokumente prüfen. ADRs, Coding Guidelines, Wiki-Einträge — was auch immer das Projekt hat. AI-generierte PRs explizit dagegen halten. Nicht weil die Doku immer aktuell ist, sondern weil die Abweichung die interessante Stelle markiert. Wenn der AI-Code anders macht, was die Doku vorschreibt, gibt es zwei Möglichkeiten: Die Doku ist veraltet, oder der Code ist falsch. Beides lohnt sich zu klären.
- Nach bestehendem Code suchen, bevor du neuen akzeptierst. AI weiß nicht, dass drei Module weiter eine Utility-Klasse existiert, die genau das tut. Oder dass das Team vor einem Jahr eine Shared Library für diesen Fall gebaut hat. Eine schnelle Suche in der Codebasis verhindert Duplikate, die langfristig Wartungsprobleme erzeugen.
- Nicht-funktionale Anforderungen aktiv einfordern. AI denkt im Happy Path. Was sie nicht einbaut: Timeout-Handling, Retry-Logik, Verhalten unter Last, Fehlerszenarien, die erst in Produktion auftreten. Einfache Checkliste: Was passiert, wenn der externe Service nicht antwortet? Was passiert bei tausend gleichzeitigen Requests? Wenn der AI-Code darauf keine Antwort hat, ist das Review nicht fertig.
- Ungeschriebene Regeln aufschreiben. Jede Konvention, die nur in Köpfen existiert, ist eine Konvention, die AI-Code brechen wird. Jede Architekturentscheidung, die nie dokumentiert wurde, muss bei jedem AI-generierten PR neu getroffen werden. Der Nachmittag, an dem das Team seine ungeschriebenen Regeln festhält, ist der Nachmittag, ab dem AI-Reviews halb so lang dauern.
Warum Dokumentation jetzt Pflicht wird
In einer Welt ohne AI waren Architecture Decision Records, gepflegte Coding Guidelines und dokumentierte Konventionen Fleißaufgaben. Gut, wenn sie da waren. Nicht tragisch, wenn nicht — weil das Wissen in den Köpfen des Teams steckte.
In einer Welt mit AI werden sie zur Voraussetzung.
AI kann nur den Kontext berücksichtigen, den sie bekommt. Wenn Projektkonventionen nirgendwo dokumentiert sind, wird AI-generierter Code sie ignorieren. Wenn Architekturentscheidungen nur in den Köpfen von drei Seniors leben, wird jeder PR gegen mindestens eine davon verstoßen.
Projekte, die ihre Konventionen dokumentiert haben, werden AI-Code mit weniger Reibung integrieren. Projekte, die es nicht haben, werden mehr Zeit mit Reviews verbringen als sie durch AI-Generierung einsparen.