- Die Frage, ob von KI geschriebener Code auch von KI reviewt werden sollte, ist spannend
- Bots wie Devin AI erstellen inzwischen die meisten PRs, und auch Reviews werden zunehmend von KI übernommen
- Es gibt zudem das Argument, dass LLMs zustandslos (stateless) sind und sich ihre interne Struktur beim Review und beim Schreiben unterscheidet, sodass eine Rollentrennung möglich ist
- Von KI generierter Code verursacht andere Arten von Bugs als menschlicher Code, und KI ist beim Finden genau dieser Bugs effektiver
- Insgesamt ist KI-Review bei der Erkennung praktischer Fehler menschlichen Reviews überlegen, auch wenn architektonische Entscheidungen und Stilrichtlinien weiterhin Sache des Menschen bleiben
Darf KI ihren eigenen Code reviewen?
- Die meisten Unternehmen halten sich an das Prinzip Autor ≠ Reviewer
- KI ist auf Basis von LLMs jedoch zustandslos und entscheidet bei jeder Anfrage neu
- Selbst bei derselben Engine kann man Schreiben und Review daher als zwei unterschiedliche „Autos“ betrachten
Scaffolding: Die Struktur von KI-Reviews
- KI für Reviews führt die folgenden spezifischen Workflows aus:
- Analyse von Code-Diffs
- Erkennung von Bugs
- Schreiben von Kommentaren und Einschätzung des Schweregrads
- Bezug auf Codebase-Dokumentation und verknüpfte Dateien
- Eine KI zur Code-Generierung arbeitet dagegen in einem völlig anderen Kontext, daher sind Review und Generierung funktional verschieden
Auch Menschen sind letztlich dieselbe „Engine“
- Selbst wenn PR-Autor und Reviewer verschieden sind, stammen beide aus derselben menschlichen Intelligenz
- In derselben Firma teilen sie ähnliches Wissen und ähnliche Erfahrung, geprägt durch dieselbe Ausbildung
- Letztlich ähneln sich KI und Mensch darin, dass beide „dieselbe Engine, anderer Fall“ sind
KI-Code braucht präzisere Reviews
-
Die Qualität von KI-Code ist etwas niedriger
- KI ist schnell, aber durch die Grenzen von Prompts werden Anforderungen oft ungenau vermittelt
- Selbst gute Entwickler reviewen KI-Code nicht so gründlich wie ihren eigenen Code
- Dadurch nivelliert sich die Gesamtqualität nach unten und nähert sich dem Mittelmaß an
-
KI-Bugs sind für Menschen schwer zu finden
- Die von KI erzeugten Bugs sind von einem Typ, den Menschen normalerweise nicht erzeugen
- Beispiele: unerwartete Änderungen an Zeilen, subtile Fehler in Bedingungen usw.
- Laut internen Tests von Greptile:
- KI (Sonnet) fand 32 von 209 „Hard“-Bugs
- Menschliche Entwickler fanden im Schnitt nur 5 bis 7
Fazit
- Dass KI ihren eigenen Code reviewt, ist technisch möglich und sinnvoll
- KI ist bei der Bug-Erkennung Menschen überlegen und in Reviews tatsächlich nützlich
- Die menschliche Interpretation von Absichten, Designentscheidungen und Code-Stil bleibt jedoch wichtig
- Den traditionellen Maßstab Autor ≠ Reviewer sollte man für KI neu interpretieren
3 Kommentare
Ich frage mich, wie es wäre, beim Review zwischen verschiedenen LLM-Modellen zu wechseln. Zum Beispiel Code, der mit Modell A geschrieben wurde, von den Modellen B, C und D reviewen zu lassen.
Ach, bei uns in der Firma machen wir das so: Wenn wir mit Cursor (Claude) geschriebenen Code als PR einreichen, lassen wir ihn von ChatGPT reviewen. Dann heißt es sozusagen: Kämpft jetzt gegeneinander. Seit o4-mini reagieren die Leute regelrecht begeistert. Man kann das auch direkt in Cursor ausprobieren, indem man das Modell wechselt und die Anfrage so stellt.
Hacker-News-Kommentare
Ich möchte diesen Punkt hervorheben: Ingenieure prüfen von AI erzeugten Code nicht so gründlich wie Code, den sie selbst geschrieben haben. Der Grund ist, dass ein LLM viel schneller Code erzeugt, als Menschen tippen können. Wenn man Code selbst schreibt, prüft man ihn dabei ganz natürlich mit; wenn AI ihn erzeugt, fällt dieser Schritt weg. Interessanterweise kann AI bei durchschnittlichen Ingenieuren die Codequalität sogar erhöhen. Je mehr AI eingesetzt wird, desto ähnlicher wird das Niveau des Codes, den gute und weniger gute Ingenieure produzieren. Code-Review, Design und Schreiben erfordern jeweils eine andere Denkweise, und das finde ich immer spannend
Menschen interagieren unterschiedlich, deshalb gibt es für jeden eine Methode, die besser passt. Für mich ist es einfacher, Code zu reviewen, als ihn zu schreiben. Beim Schreiben muss ich neben der Codebasis viel Kontext im Kopf behalten, während ich mich beim Review nur auf die Codebasis konzentrieren kann und dadurch schneller Muster erkenne. Leider liegt das Niveau von LLMs auf dem eines Junior Engineers, daher kosten PR-Reviews mehr Aufwand und Energie
Gute Ingenieure sind oft nicht automatisch gute Coder
Wenn man für Code-Review und zum Schreiben von Code unterschiedliche Bots und Prompts verwendet, lassen sich deutlich mehr Fehler finden. Selbst wenn man dasselbe Tool mehrfach laufen lässt, entdeckt es manchmal neue Probleme. Weder Menschen noch AI erzeugen auf Anhieb perfekten Code. AI-Tools entwickeln sich zwar weiter und sind inzwischen an dem Punkt, an dem sie ihren eigenen Code testen und vorab reviewen können, aber ich bin überzeugt, dass es nie schadet, wenn sowohl Menschen als auch AI PR-Code reviewen. Selbst mit meinem eigenen Tool Kamara habe ich oft Probleme in Code gefunden, den ich selbst geschrieben hatte. Es gab auch Probleme wie im greptile-Beispiel, bei dem Vorschläge auf völlig falsche Code-Stellen zeigten, aber das bekommen wir zunehmend in den Griff. Ein 100% perfektes Tool gibt es noch nicht, und bis AI alles übernimmt, wird es wohl noch etwas dauern
Als wir OpenHands (früher OpenDevin) gestartet haben, wurden von AI erstellte PRs unter einem AI-Account eingereicht. Das führte zu zwei ernsten Problemen: 1) Die Person, die die AI aufgerufen hatte, konnte ohne Code-Review direkt mergen, sodass ungeprüfter Code ausgeliefert werden konnte, 2) es gab keinen klaren Verantwortlichen für den PR, sodass unklar war, wer zuständig war, wenn er nicht gemergt wurde oder Probleme verursachte. Deshalb haben wir die Strategie geändert, sodass jeder PR einen menschlichen Owner hat und nur die Commits den AI-Namen tragen. Für den PR selbst ist vollständig ein Mensch verantwortlich
Ich fand den Punkt interessant, dass LLMs Bugs gut finden sollen. Ich frage mich, wie viele False Positives dafür in Kauf genommen wurden, um diese hohe reale Bug-Erkennungsrate zu erreichen. Meiner Erfahrung nach behaupten LLMs oft, es gebe einen Bug, obwohl keiner da ist
Das kann ich sehr gut nachvollziehen. Wenn ich ChatGPT etwas frage und mir der Vorschlag nicht gefällt, sage ich einfach: „Bei dem Teil bin ich mir nicht sicher?“ und schon ändert es die Antwort. Dabei könnte die erste Antwort sogar richtig gewesen sein, aber wenn der Nutzer nicht überzeugt wirkt, lässt es sich leicht beeinflussen. Deshalb ist es nicht einfach, solche Tools sauber zu validieren
In diesem Fall gab es in jeder Datei genau einen Bug, und der Bot wurde angewiesen, genau einen zu finden. Es waren alles False Positives; er hat Bugs an Stellen erfunden, an denen überhaupt kein Problem vorlag
Der Unterschied zwischen den verschiedenen AI-Code-Review-Tools am Markt liegt genau in der Abstimmung des Signal-Rausch-Verhältnisses. Manche Tools sind deutlich präziser und haben weniger False Positives
Die wichtigste Verantwortung eines Programmierers ist es, funktionierenden Code zu liefern, von dem er überzeugt ist. Ob dabei ein LLM verwendet wurde, spielt keine Rolle. Entscheidend ist die Haltung: „Ich bin sicher, dass diese Änderung das Problem löst, und ich kann dafür mit meinem Ruf einstehen.“ Deshalb braucht ein PR immer einen zweiten Prüfer, egal ob Mensch oder AI
Meiner Meinung nach ist der Ruf der entscheidende Punkt. Das gilt nicht nur für Code, sondern auch für Texte in natürlicher Sprache. Wir steuern auf eine Zeit zu, in der nicht der Autor, sondern die veröffentlichende Person, also der Publisher, die Verantwortung für den Inhalt trägt. Ob 5% oder 95% von einem Chatbot stammen: Wenn es Probleme gibt, sollte man mich kritisieren, weil ich den Text veröffentlicht habe. „Das hat der Chatbot gemacht“ ist keine Ausrede
Es ging nur um ein Beispiel wie Devin, also einen vollständig automatisierten Engineer; das ist etwas anderes als bei einem normalen Engineer
Viele Ingenieure werfen heute achtlos schlechten, von AI erzeugten Code in den Raum und hoffen, dass andere Kollegen die Probleme schon finden. Früher kam das seltener vor, weil allein die Code-Erzeugung mühsamer war
Ich stimme der Aussage sehr zu, dass deine Verantwortung darin besteht, vertrauenswürdigen Code zu erstellen. Aber auch schon vor AI wurden gute Code-Standards nicht immer eingehalten. Wir betrachten Programmieren zunehmend nur noch als Mittel zum Zweck oder zum Geldverdienen. Eigentlich ging es einmal um die Freude daran, Probleme zu lösen und die Welt zu verändern. Heute liegt der Fokus eher darauf, schnell Geld zu verdienen oder Schutzgräben aufzubauen. Entscheidend ist nicht, ob der Code schön ist, sondern ob das Problem elegant gelöst wurde. AI kann diese Kultur verschlechtern, aber letztlich hängt alles davon ab, wie man sie einsetzt
Ich frage mich: Wenn ein PR alle eigentlichen Probleme löst und nur kleine Bugs enthält, in welchem Fall wäre dieser PR dann Zeitverschwendung? Mich würde ein konkretes Beispiel interessieren
Code-Review ist der langsamste Schritt im Engineering. Auch ohne AI kann ich Code schnell schreiben, aber Code-Reviews werden dadurch nicht schneller. Deshalb lasse ich meinen Code vor dem eigentlichen Review von AI vorab prüfen, spare meinen Kollegen Zeit und finde Bugs früher, wodurch sich die Zeit bis zum Deployment oft um mehrere Tage verkürzt. AI hat für mich sowohl offensichtliche Bugs als auch versteckte Fehler gefunden und sogar schon wirklich tief sitzende Bugs aufgedeckt. Ich nutze einen Workflow, bei dem ich mit git cli und xclip den Diff kopiere und ihn dann in ein Logikmodell wie o3 einfüge, um ein Review zu bekommen
Einer der Vorteile von AI ist, dass sie viel schneller als Menschen große Mengen an Unit-Tests schreiben kann. Und Probleme, die sie selbst findet, kann sie auch selbst beheben. Der ideale Workflow wäre nicht nur Code-Review, sondern auch, dass AI automatisch ihre eigenen Tests ausführt und prüft, ob alles eine bestimmte Spezifikation erfüllt. Zu viele Tests können spätere Refactorings erschweren, etwa wenn sie von Implementierungsdetails abhängen; und wenn sie lästig sind, kann man im Zweifel auch nur die von AI geschriebenen Tests wieder verwerfen
Ich finde es großartig, Unit-Tests bei Bedarf einfach neu generieren zu können. Wenn ich ein Review einreiche, freue ich mich sehr über die Größe des Diffs, und ich spare die langweilige Zeit für das Schreiben von Tests, sodass ich mehr schaffen kann
Auch heute gibt es in der Programmierung noch lästige Aufgaben, aber im Idealfall sollte AI diese Ineffizienzen reduzieren, damit Menschen sich stärker auf kreative Bereiche konzentrieren können. In der Praxis dringt AI allerdings zunehmend auch in höherwertige kreative Arbeit vor
Tatsächlich kann man auch ohne AI mithilfe von Property-based-Testing-Frameworks automatisch Tests für eine große Zahl von Eingabewerten erzeugen
Ich habe beim Code-Review eine Regel: Wenn ich es mir nicht zutraue, den Code später selbst zu warten, genehmige ich ihn nicht. Wenn man ein LLM sowohl zum Schreiben als auch zum Reviewen von Code nutzt, könnte man sagen, dass man dieses Verantwortungsprinzip auch auf das Tool anwendet. Aber ich glaube nicht, dass ich lange in so einer Situation bleiben wollte
Ich frage mich, ob jemand schon einmal eine Pipeline ausprobiert hat, bei der ein LLM aus Anforderungen Gherkin-Skripte erstellt, ein anderes LLM daraus Code generiert und Cucumber dann das Ergebnis prüft. Natürlich müssten sowohl die Gherkin-Skripte als auch der Code trotzdem reviewt werden, aber ich würde gern wissen, welche Arten von Code sich auf diese Weise nicht erzeugen lassen. Ich betrachte AI als eine Art Entwickler, und genau wie menschliche Entwickler dürfte sie Bereiche haben, in denen sie nicht gut ist
Letztlich muss der Autor eines PR Verantwortung für die Auswirkungen und Ergebnisse seines Codes übernehmen. Da AI-Coding immer verbreiteter wird und es zugleich viele Junior Engineers gibt, wird diese Verantwortung noch wichtiger. Es ist sinnvoll, AI den ersten Review-Pass machen zu lassen, aber menschliche Reviewer müssen weiterhin aus einer externen Perspektive das Verständnis der Codebasis vertiefen und Probleme auf höherer Ebene erkennen. Ideal ist also eine Struktur, in der AI den ersten Review übernimmt, ein weiterer Engineer den Code im Hinblick auf Kontext oder Zusammenarbeit prüft, und der Autor am Ende die Verantwortung für alle Ergebnisse trägt