Vor kurzem habe ich an einem eigenen Tool für Entwicklerherz gearbeitet – nichts Großes, ein interner Service, den ich nebenbei baue. Ein AI-Agent hat einen Pull Request geliefert, der auf den ersten Blick tadelloser war als das meiste, was mir in fünfzehn Jahren Softwareentwicklung untergekommen ist. Saubere Methoden, vernünftiges Naming, Tests dabei, dokumentiert. Der Code hat funktioniert. Technisch gab es nichts zu beanstanden.
Was mir erst am nächsten Tag auffiel: Der Controller hatte eine eigene Fehlerbehandlung mitgebracht. Elegant gelöst. Nur existierte im Projekt bereits ein globaler ExceptionHandler – entstanden nach einem Bug, der mich einen Samstag gekostet hat. Das stand nirgendwo als Regel. Das steckte in meinem Kopf. Und weil ich es beim Review nicht aktiv gegengeprüft habe, ist es durchgerutscht.
Der Fehler lag nicht bei der AI. Der Fehler lag bei mir. Ich habe AI-Code reviewed wie menschlichen Code – Zeile für Zeile, von oben nach unten, mit dem Blick auf Korrektheit. Und dabei übersehen, dass die eigentliche Frage eine andere war.
Korrekt ist nicht genug
Es gibt einen Unterschied, der trivial klingt, aber alles verändert: Ein Kollege schreibt Code innerhalb eures Projekts. Eine AI schreibt Code, der in euer Projekt hineingesetzt wird. Der Unterschied ist Kontext.
Natürlich kann man einer AI Kontext geben. Man kann ihr Architektur-Dokumente mitliefern, Coding Guidelines, bestehende Module als Referenz. Je besser der Kontext, desto besser der Output – das ist inzwischen keine Neuigkeit mehr. Aber es gibt eine Sorte Kontext, die sich schwer in einen Prompt packen lässt: die gelebte Geschichte eines Projekts.
Warum der Service X über einen Umweg mit Service Y kommuniziert, obwohl eine direkte Verbindung naheliegender wäre. Warum eine Spalte als VARCHAR angelegt ist, wo ein ENUM sauberer wäre. Warum ein bestimmtes Modul eine eigene Fehlerbehandlung hat. Das sind keine technischen Entscheidungen – das sind Narben. Narben von Incidents, von Compliance-Audits, von Abhängigkeiten zu Drittsystemen, die sich nicht ändern lassen.
AI-Code, der diese Geschichte nicht kennt, kann trotzdem hervorragend sein. Aber er kann auch hervorragend daneben liegen. Und das Problem ist: Beides sieht von außen gleich aus. Sauberer Code, grüne Tests, ordentliche Struktur. Der Unterschied zeigt sich erst, wenn man weiß, wogegen man prüfen muss.
Warum der klassische Review-Workflow nicht reicht
Beim Review von menschlichem Code liest du den Denkweg eines Kollegen. Du siehst, wo er abgewogen hat, wo er sich unsicher war, wo er bewusst eine Abkürzung genommen hat. Das erkennst du, weil du selbst so denkst. Der Code erzählt eine Geschichte.
AI-Code erzählt keine Geschichte. Er ist Ergebnis ohne Herleitung. Sauber, oft sauberer als menschlicher Code, aber ohne die Spuren des Nachdenkens. Und damit fehlt dir als Reviewer etwas Entscheidendes: der Denkweg, den du mitliest und an dem du Fehler erkennst.
Das ist der Kern des Problems. Nicht dass AI-Code schlechter wäre – oft ist er besser. Sondern dass die Art, wie wir Reviews seit Jahren machen, auf eine Annahme gebaut ist, die bei AI-Code nicht mehr gilt: dass der Autor und der Reviewer im selben Kontext arbeiten.
Wenn ein Kollege einen PR stellt, hat er dieselben Meetings besucht, dieselben Retros gehört, dieselben Incidents miterlebt. Wenn eine AI einen PR generiert, hat sie nichts davon. Und kein noch so guter Prompt ersetzt die Tatsache, dass sie nicht dabei war, als das Team vor achtzehn Monaten entschieden hat, auf synchrone Aufrufe zwischen den Services zu verzichten.
Filtern statt lesen
Was mir nach dem Fehler mit dem ExceptionHandler klar wurde: Ich muss AI-Code anders angehen. Nicht gründlicher – das hilft nicht, wenn man an den falschen Stellen gründlich ist. Sondern in einer anderen Reihenfolge.
Bei menschlichem Code starte ich im Diff und lese mich durch. Bei AI-Code starte ich eine Ebene höher. Nicht „Ist die Methode korrekt?", sondern „Gehört diese Klasse überhaupt in dieses Modul?" Nicht „Sind die Tests grün?", sondern „Testen sie die Szenarien, die in unserem System tatsächlich auftreten?"
Ich arbeite inzwischen in Schichten. Zuerst die Architektur – stimmt die Verortung im System? Dann die Projektkonventionen – folgt der Code den Patterns, die das Team über Monate entwickelt hat? Dann ein schneller Check, ob die AI etwas neu gebaut hat, das es bereits gibt. Und erst wenn das alles passt, gehe ich in die Implementierung.
Das klingt nach Mehraufwand. Tatsächlich spart es Zeit. Weil ein PR, der am falschen Ort im System landet, nicht besser wird, wenn man ihn Zeile für Zeile durchliest. Die fünf Minuten, die ich in die oberen Schichten investiere, sparen mir die dreißig Minuten, die ich sonst in einem Detail-Review versenke, das am Ende trotzdem ein Reject wird.
Was sich für alle ändert
Das betrifft nicht nur den einzelnen Reviewer. Es verändert, wie Teams arbeiten und wie Unternehmen über Softwarequalität nachdenken.
- Für Entwickler
- Reviews werden anspruchsvoller. Die Zeiten, in denen ein Review hauptsächlich Syntax und Style war, sind vorbei. Wer AI-Code sinnvoll prüfen will, braucht ein Verständnis für das Gesamtsystem – nicht nur für die Sprache, in der es geschrieben ist. Das gilt für Juniors, die dieses Verständnis aufbauen müssen, genauso wie für erfahrene Entwickler, die es aktuell halten müssen.
- Für Unternehmen
- Dokumentation wird vom Nebenschauplatz zum Produktionsfaktor. Architecture Decision Records, gepflegte Coding Guidelines, dokumentierte Konventionen – das war bisher Fleißarbeit, die man gerne aufgeschoben hat. In einer Welt, in der AI-Agenten Code generieren, wird jede undokumentierte Konvention zum Review-Engpass. Nicht weil die AI sie nicht einhalten könnte – sondern weil niemand prüfen kann, ob sie eingehalten wurde, wenn sie nirgendwo steht.
- Für Team-Builder
- Es verschiebt sich, welche Fähigkeiten im Review wirklich zählen. Es geht weniger darum, ob jemand einen Bug in Zeile 47 findet. Es geht darum, ob jemand versteht, warum Zeile 47 so sein muss und nicht anders. Das ist ein Unterschied, der sich nicht in Jahren Berufserfahrung messen lässt, sondern in Jahren im selben Kontext.
Der eigentliche Punkt
AI macht Code-Produktion billiger und schneller. Das ist Fakt. Aber sie macht Code-Bewertung nicht einfacher. Im Gegenteil – sie macht sie anspruchsvoller, weil die Oberfläche sauberer wird und die eigentlichen Probleme tiefer liegen.
Das ist keine Kritik an AI. Ich nutze sie täglich, und der Output wird besser mit jedem Monat. Aber wer glaubt, dass guter AI-Output automatisch gute Software bedeutet, verwechselt Produktion mit Qualität. Guter Code ist Code, der funktioniert. Gute Software ist Code, der ins System passt, die Geschichte des Projekts respektiert und in einem Jahr noch wartbar ist.
AI schreibt Code, der funktioniert. Ob er passt, entscheidest du.