KI-gestützte Behebung von Findings aus der statischen Code-Analyse bedeutet, erkannte Qualitätsprobleme automatisiert durch ein Large Language Model korrigieren zu lassen. Der betroffene Code und die Problembeschreibung werden an das Modell übergeben, das einen Korrekturvorschlag erzeugt. In rund zwei Dritteln der Fälle liefern aktuelle Modelle verwendbare Ergebnisse, im verbleibenden Drittel ist der Output fehlerhaft oder ungültig.
Das Wichtigste in Kürze
- KI-gestützte Fixes auf Basis statischer Analyse-Befunde funktionieren in rund zwei Dritteln der Fälle gut genug, um direkt oder mit kleinen Anpassungen übernommen zu werden.
- Das verbleibende Drittel produziert unbrauchbare oder schlicht falschen Code, und der Prüfaufwand ist dort genauso hoch wie eine manuelle Korrektur von Anfang an.
- Large Language Models verweigern eine Antwort fast nie: In einem Benchmark aus hundert Findings sagten die Modelle nur zweimal “weiß ich nicht” und produzierten stattdessen lieber fehlerhaften Code.
- Closed-Source-Code schneidet in LLM-basierten Security-Analysen deutlich schlechter ab als öffentlich verfügbarer Code, weil er schlicht nicht in den Trainingsdaten enthalten ist.
Statische Analyse liefert zu viele Funde, um sie von Hand abzuarbeiten
Statische Analyse wirft auf großen Systemen so viele Probleme aus, dass die manuelle Behebung an einer schieren Mengengrenze scheitert. Ein typischer Regelsatz umfasst Hunderte bis über tausend Regeln. Das Ergebnis: ein paar tausend, ein paar zehntausend, in Einzelfällen Millionen von Befunden in einem einzigen Codebestand.
Diese Funde sind sehr unterschiedlich schwer. Manche sind trivial, etwa ein fehlender Kommentar an einer Methode. Andere wiegen schwer, zum Beispiel eine potenzielle SQL-Injection oder eine mögliche Null-Pointer-Dereferenzierung. Der Schweregrad streut also stark.
In der Praxis führt diese Flut oft zu Vermeidung. Benjamin Hummel beschreibt zwei verbreitete Muster: Teams schalten Regeln ab, oder sie schauen gar nicht mehr in die Ergebnisse hinein. Das Abschalten ist dabei noch die konstruktivere Variante. Die Empfehlung lautet bewusst, zuerst die schwerwiegenden Funde anzugehen und sich nicht von der Masse überfluten zu lassen.
Warum große Sprachmodelle beim Beheben von Funden überhaupt helfen
Sprachmodelle verschieben die Behebung von der reinen Syntax-Ebene auf eine Ebene, die Code und natürliche Sprache zugleich versteht. Genau das war mit klassischer statischer Analyse kaum möglich.
Statische Analyse ist gut darin, Code zu parsen, Syntaxbäume aufzubauen und Datenflüsse nachzuvollziehen. Das bleibt aber syntaktisch und sprachsemantisch. Die natürliche Sprache, die in Kommentaren, Namen und Beschreibungen steckt, lag bisher außerhalb ihrer Reichweite.
Ein Beispiel macht den Sprung greifbar: ein fehlender Methodenkommentar. Frühere Dokumentationsgeneratoren nahmen den Methodennamen, fügten Leerzeichen ein und produzierten weitgehend sinnlose Texte. Steckt man heute den ganzen Methodeninhalt in ein Sprachmodell, entsteht eine brauchbare Zusammenfassung samt sinnvoller Details. Das Verstehen von Code ist hier erstaunlich weit fortgeschritten.
Der eigentliche Hebel liegt deshalb nicht im Generieren von neuem Code, sondern im Verbessern von bestehendem. Statt selbst von null anzufangen, bekommst du einen Vorschlag, den du nur noch prüfen und nachschärfen musst.
Wie ein KI-gestützter Fix konkret entsteht
Der naive und überraschend tragfähige Ansatz: man gibt dem Modell das betroffene Code-Stück, die Beschreibung des Problems aus der statischen Analyse und, falls vorhanden, den Erklärtext dazu, warum es ein Problem ist und wie typische Fixes aussehen. Das Modell liefert daraufhin den korrigierten Code.
Das funktioniert über ein breites Spektrum an Problemklassen. Es reicht von ergänzten Kommentaren über das Entfernen ungenutzter Imports bis hin zu komplexeren Refactorings.
Gerade bei längeren Methoden zeigt sich, wie weit das trägt. Ein Modell schlägt vor, zwei sinnvoll benannte Methoden herauszuziehen, und das Ergebnis ist in sich konsistent. Das ist keine Kleinigkeit, denn selbst von Hand erfordert die Entscheidung, an welcher Stelle eine Methode geschnitten wird, einiges an Überlegung.
Die Trefferquote liegt bei zwei Dritteln, der Rest ist Rauschen
Über einen systematischen Benchmark zeigt sich: In etwa zwei Dritteln der Fälle funktioniert die KI-gestützte Behebung wirklich gut. Das verbleibende Drittel ist Rauschen.
Für die Auswertung wurden rund 100 Verletzungen aus einem größeren Projekt gezogen und mit verschiedenen Modellen durchgespielt. Die Modelle wechseln gefühlt im Monatstakt, deshalb war der Vergleich mehrerer Modelle nötig. Die Bewertung selbst war Handarbeit: jeder der 100 Fälle pro Modell wurde manuell geprüft, ob die Lösung sinnvoll ist, ob der Code valide bleibt und ob er weiterhin das tut, was er vorher tat.
Das gute Drittel-Bild im Detail: Die brauchbaren Vorschläge kann man direkt übernehmen oder mit kleinen Anpassungen, etwa einer Umbenennung, weiterverwenden. Das spart spürbar Arbeit.
Das schlechte Drittel ist heikler. Hier kommt unbrauchbarer Code heraus, teilweise sogar Code, der nicht einmal valide ist. Der Aufwand, einen solchen Vorschlag zu prüfen und auf subtile Fehler abzuklopfen, ist oft genauso hoch oder höher, als die Stelle gleich selbst aufzuräumen.
Modelle wollen gefallen, statt zuzugeben, dass sie nicht weiterwissen
Ein zentrales Problem: Sprachmodelle sind stark darauf trainiert, eine Lösung zu präsentieren, selbst wenn sie das Problem erkennbar nicht beherrschen. Auch wenn der Prompt offen formuliert ist und ausdrücklich erlaubt, mit einem “weiß ich nicht” abzulehnen, passiert das kaum.
Über alle Experimente hinweg gab es nur zwei Fälle, in denen ein Modell eingestanden hat, dass es die Lösung nicht kennt. Stattdessen versuchen die Modelle, mit Gewalt irgendeine Lösung zu produzieren.
Genau dieses Verhalten bereitet mehr Probleme als ein ehrliches Aufgeben. Würde das Modell sagen “weiß ich nicht”, wüsstest du sofort, dass du die Stelle von Hand machst, ohne viel darüber nachzudenken.
Die Modelle sind sehr stark darauf trainiert, eine Lösung zu präsentieren, selbst wenn man den Eindruck hat, die können das gar nicht. Sie wollen gefallen. — Benjamin Hummel
Mainstream-Sprachen funktionieren, Exoten und Closed Source brechen ein
Die Qualität der Vorschläge hängt direkt an der Menge der Trainingsdaten zur jeweiligen Sprache. Mainstream-Sprachen wie Java oder JavaScript laufen gut, weil sie reichlich in den Trainingsdaten vertreten sind.
Bei Nischen kippt das Bild. Für Bereiche wie ABAP-nahe SAP-Entwicklung gibt es deutlich weniger Open-Source-Trainingsdaten als etwa für Python. Dort ist mit schlechteren Ergebnissen zu rechnen. Das deckt sich mit dem Verhalten von Code-Generatoren allgemein: Bei exotischen Sprachen produzieren sie merklich schwächere Ergebnisse.
Noch deutlicher wird der Effekt beim eigenen, nicht öffentlichen Code. In einer laufenden Abschlussarbeit zur Security-Analyse mit Sprachmodellen wurden zwei Datensätze verglichen: ein gängiger Benchmark und eigener, garantiert nicht in Trainingsdaten enthaltener Code. Auf dem eigenen Code waren die Ergebnisse deutlich schlechter.
Diese Lücke ist praktisch relevant. Ein Großteil der Unternehmenssoftware wird Closed Source entwickelt und taucht damit nicht in Trainingsdaten auf. Genau dort, wo die Verfahren im Alltag laufen müssten, schwächeln sie am stärksten.
KI-Linter verpacken oft nur Ergebnisse klassischer Tools
Bei vielen Werkzeugen, die automatische Code-Reviews auf Plattformen wie GitHub versprechen, läuft im Hintergrund ein klassischer Open-Source-Linter. Die Funde werden anschließend von einem Sprachmodell sprachlich umformuliert.
Das erzeugt den Eindruck, die KI leiste die eigentliche Analyse. Tatsächlich verpackt sie vor allem die Befunde des Linters. “KI” auf der Verpackung ist heute zum Verkaufsargument geworden.
Die generelle Qualität echter KI-Funde bleibt durchwachsen. Es werden Probleme gemeldet, die keine sind, und viele echte Probleme bleiben unentdeckt. Die fehlende Vollständigkeit teilt die KI allerdings mit jeder statischen Analyse, vollständig ist keines dieser Verfahren.
Findings dort beheben, wo du ohnehin am Code arbeitest
Für alte, gewachsene Systeme ist KI nicht die naheliegende Antwort. Die bewährte Strategie bleibt: Probleme genau dort beheben, wo gerade ohnehin gearbeitet wird.
Wer etwa wegen einer Gesetzesänderung ein Modul zur Steuerberechnung anfasst, räumt sinnvollerweise die Funde in genau diesem Modul mit auf. In Teilen, die niemand berührt, lohnt das Aufräumen kaum. Eine Ausnahme bilden Hochrisikothemen wie SQL-Injection-Risiken, auf die man gezielt schaut. Mit dieser schrittweisen Methode landet man nach und nach bei einem besseren System.
Gegen das proaktive, flächige Aufräumen mit KI spricht die Fehlerwahrscheinlichkeit. Selbst bei 99,9 Prozent korrekter Fixes baust du beim Wegräumen von 100.000 Funden rechnerisch 100 neue Fehler ein. Das will niemand.
Für die schlimmsten Stellen, also stark verschachtelte Module, die architektonisch kaum noch zu überblicken sind, hilft KI derzeit nicht. Hier bleibt nur die ernsthafte Entscheidung, solche Teile gezielt neu zu bauen und mit Tests abzusichern.
Generierter Code ist nicht neu, aber KI nimmt ihm das Vertrauen
KI-generierter Code wirft eine alte Frage in neuer Schärfe auf: Wie viel Lesbarkeit braucht Code, in den kein Mensch mehr hineinschaut? Code aus Generatoren gibt es längst, etwa Parser aus Grammatiken oder Anwendungscode aus domänenspezifischen Sprachen. An solchen generierten Code legt man andere Lesbarkeitsansprüche an, weil man bei Änderungen das Ausgangsmodell anpasst und neu generiert.
Der entscheidende Unterschied zur KI liegt im Vertrauen. Klassische Generatoren und Compiler sind deterministisch: Gleiche Eingabe, gleiches Ergebnis. Sie werden über lange Zeit entwickelt und getestet, deshalb sucht heute kaum jemand den Fehler zuerst im Compiler. Sprachmodelle dagegen halluzinieren, irren sich und liefern durch ihren probabilistischen Faktor unterschiedliche Ausgaben.
Daraus folgt ein konkretes Risiko. Wenn die KI ein System baut, das du als Mensch nicht mehr nachvollziehst, und du auch jede Änderung wieder der KI überlässt, stehst du am Punkt, an dem es nicht mehr weitergeht, ohne Handhabe da. Genau dort werden Tester wichtiger, denn die Frage, ob das System noch das Richtige tut, bleibt offen.
