KI-Code prüfen ist eine Vertrauensfrage, kein Diff, sagt eine Studie von JetBrains und Lund
Serguey Asael Shinder2 Min. LesezeitJetBrains Research und Forscher der Universität Lund haben eine Studie darüber veröffentlicht, wie Werkzeuge zur Prüfung von KI-generiertem Code funktionieren sollten. Der Beitrag wird auf der Empirical Software Engineering International Week (ESEIW) 2026 im Oktober vorgestellt. Die zentrale These verdient Aufmerksamkeit, weil sie ein Problem beschreibt, das jedes Team mit Coding-Agenten bereits hat.
Warum die üblichen Review-Instinkte versagen. Beim Code eines Kollegen hilft ein unsichtbares Gerüst: Man weiß, wie erfahren er ist, welche Teile er überhastet, und kann ihn in Slack fragen. Bei einem Modell fehlt all das. Schlimmer noch: Ein Sprachmodell zeigt jede Zeile mit derselben scheinbaren Sicherheit, egal wie unsicher es tatsächlich war — die Authentifizierung und die wacklige Datenbankmigration lesen sich gleich. Die vernünftige Reaktion wäre, jede Zeile zu lesen, und das skaliert nicht, wenn Agenten immer größere Änderungen erzeugen.
Der Perspektivwechsel. Die Autoren argumentieren, dass die Prüfung großer, mehrere Dateien umfassender Änderungen eines Modells kein Diff-Problem, sondern ein Problem der Vertrauenskalibrierung ist: die Fähigkeit, den Prüfaufwand am Risiko jedes Abschnitts auszurichten, wenn man den Autor nicht nach seiner Sicherheit fragen kann. Die Diff-Ansicht ging davon aus, dass man verstehen muss, was sich geändert hat; für das, was ein Agent geschrieben hat, sei sie womöglich nicht das richtige Werkzeug.
Der Vorschlag. Ein dreistufiger Ablauf nach Shneidermans Prinzip der Informationsvisualisierung — erst Überblick, dann Zoomen und Filtern, dann Details auf Abruf: Der Prüfer bildet Hypothesen auf hoher Ebene und geht gezielt in die Tiefe, um sie zu prüfen. Der Entwurf entstand in vier Workshops mit 17 Praktikern und einer anschließenden Umfrage unter 43 Softwarefachleuten.
Wo Werkzeuge heute stehen. Die Autoren nennen Teilentsprechungen: Prosa-Zusammenfassungen von Pull Requests bei CodeRabbit, mehrere Review-Agenten mit Schweregraden in Claude Code und die gestapelten Pull Requests von Graphite als nächste Entsprechung zur Aufteilung einer Änderung in prüfbare Stücke. Ihr Punkt: Noch kein Werkzeug zeigt Risiko und Sicherheit dort, wo Prüfer tatsächlich hinschauen.
Warum das zählt. Die praktische Lehre lässt sich auch ohne neue Werkzeuge anwenden: den Agenten bitten, seine Änderung aufzuteilen und zu sagen, wo er unsicher war, und diese Teile zuerst prüfen.