Mit jeder neuen Generation von Coding-Modellen entsteht mehr Code in kürzerer Zeit, und der Tenor in jedem zweiten Dev-Thread ist derselbe: Code wird heute schneller geschrieben, als ein Mensch ihn lesen kann. Wenn ein Modell in einer Minute einen ganzen Service hinstellt — wozu dann noch ein statischer Analyzer, der dieselben Zeilen nochmal durchkämmt? Sind SonarQube, SonarCloud und Konsorten nicht das Faxgerät unter den Dev-Tools, kurz vor dem Aussterben?
Die kurze Antwort: nein. Die etwas längere, die ich hier vertrete: Genau jetzt, wo KI den Code-Output vervielfacht, wird die deterministische Qualitäts-Schranke wertvoller, nicht überflüssiger. Wer viel produziert, muss viel prüfen — und zwar mit etwas, das nach festen Regeln urteilt statt selbst zu raten.
Kurz gesagt — Ein LLM schreibt Code; ein Static Analyzer urteilt reproduzierbar über jede Zeile, bei jedem Commit, nach derselben Regel. Das eine ersetzt das andere nicht. Die KI beschleunigt, Sonar verifiziert. Und genau diese Trennung ist es, die KI-Code auf Produktionsniveau hält.
Die falsche Frage
„KI oder statische Analyse" ist ein Scheingegensatz. Die beiden lösen nicht dasselbe Problem — sie sitzen an verschiedenen Stellen der Pipeline und haben grundverschiedene Eigenschaften.
Ein KI-Review ist kontextstark, aber wahrscheinlichkeitsbasiert (probabilistisch). Es versteht Intent, erkennt „der Code tut nicht, was der Kommentar verspricht", und argumentiert über Geschäftslogik. Aber es ist nicht reproduzierbar: derselbe Diff, zweimal vorgelegt, liefert nicht garantiert dasselbe Urteil. Es sieht meist nur den Diff, selten die ganze Codebase. Und es kennt kein Pass/Fail, an dem eine Pipeline hart abbrechen kann.
Ein Static Analyzer ist das Gegenteil: kontextarm, aber deterministisch. Dieselbe Regel, dieselbe Zeile, dasselbe Ergebnis — heute, morgen, in jedem Branch. Er scannt 100 % der Codebase, nicht nur den Diff. Er liefert ein hartes Quality Gate, das im CI blockiert. Und er hält jede Messung über Monate als Trend fest.
Wenn aber beides gebraucht wird, lohnt der genaue Blick darauf, was jedes Werkzeug beiträgt — und wo das eine strukturell scheitert, während das andere glänzt.
Was ein Analyzer kann, was ein LLM strukturell nicht kann
Vier Dinge, die kein noch so gutes Modell aus seiner Natur heraus liefern kann:
Reproduzierbarkeit. Eine Aussage wie „dieser Release enthält keine neuen Vulnerabilities der Severity Blocker" muss bei jeder Wiederholung gleich ausfallen — sonst trägt sie weder im Audit noch im Vertrag noch vor dem Kunden. Ein deterministischer Scanner garantiert das. Ein Sampling aus einem Wahrscheinlichkeitsmodell nicht.
Vollständige Abdeckung. Sonar analysiert den gesamten Baum bei jedem Lauf. Ein KI-Reviewer bekommt typischerweise den Diff und ein Stück Kontext — was außerhalb des Fensters liegt, bleibt ungeprüft. Über viele Services und eine große Codebasis hinweg ist „außerhalb des Fensters" der Normalfall, und genau dort fährt sonst ein Risiko unbemerkt mit.
Ein hartes Gate. sonar.qualitygate.wait=true lässt die Pipeline auf das Urteil warten und bricht ab, wenn neue Issues die Schwelle reißen. Das ist eine binäre, automatisierbare Entscheidung, an der fehlerhafter Code hängenbleibt, bevor ihn ein Mensch übersieht. „Das Modell findet den PR eher okay" ist keine.
Trend über Zeit. Maintainability-Rating, Coverage-Verlauf, Security-Hotspots pro Sprint, Duplication-Quote — Sonar hält das als Zeitreihe. Ein LLM hat kein Projektgedächtnis über Sessions hinweg; es weiß nicht, ob die technische Schuld seit März steigt oder fällt. Sonar weiß es auf den Tag genau.
Dazu kommt die Security-Dimension: Taint-Analysis verfolgt, wie nicht vertrauenswürdiger Input durch den Code bis in eine SQL-Query oder einen Shell-Aufruf fließt — über Methodengrenzen hinweg, mit Mapping auf OWASP und CWE. Das ist reproduzierbarer, auditierbarer Security-Nachweis, kein „sieht mir sicher aus". Und je mehr Code automatisch entsteht, desto mehr Zeilen müssen durch genau diesen Filter.
KI schreibt schnell — wer prüft das Volumen?
Womit wir beim eigentlichen Hebel sind. Die vier Punkte oben klingen nach „nice to have", solange ein Mensch in überschaubarem Tempo Code schreibt. Mit KI kippt das.
Wenn ein Team mit KI-Unterstützung das Drei- oder Fünffache an Code produziert, skaliert die Reviewer-Kapazität nicht mit. Der menschliche Review wird zum Flaschenhals, und die Versuchung, KI-Output „sieht gut aus, merge" durchzuwinken, steigt. Genau dann brauchst du eine objektive, unermüdliche Schranke, die jede einzelne generierte Zeile am selben Maßstab misst — egal ob sie ein Mensch um drei Uhr nachts oder ein Modell in 200 Millisekunden geschrieben hat. Sie ist nicht das, was KI-Tempo ausbremst; sie ist das, was KI-Tempo überhaupt erst verantwortbar macht. Ohne sie ist mehr Output schlicht mehr ungeprüftes Risiko.
Ich nutze KI massiv in der eigenen Entwicklung. Aber alles, was generiert wird, läuft durch dieselbe SonarQube-Instanz wie handgeschriebener Code — same rules, same gate. Das ist kein Misstrauen gegen die KI. Es ist der Grund, warum ich der KI so viel Code überhaupt anvertrauen kann. Wie das konkret aussieht, zeigt das nächste Beispiel.
Praxis: ein eigenes Produkt
Eines meiner eigenen Produkte — ein KI-Ernährungsassistent — ist in .NET gebaut, mit mehreren Backend-Services und Apps für Web, iOS, Android und Watch. Jeder Service, jede App hat ihr eigenes SonarQube-Projekt, alles läuft gegen eine selbst gehostete SonarQube-Instanz in einer Kubernetes-Umgebung. Kein Code verlässt meine Infrastruktur — für einen datenschutzsensiblen Anwendungsfall ist das kein Detail, sondern Voraussetzung.
Der Backend-Scan hängt im GitLab-CI hinter den Testjobs, damit der Scanner die Coverage-Reports einsammelt:
dotnet sonarscanner begin \
/k:backend \
/d:sonar.host.url="$SONAR_HOST_URL" \
/d:sonar.cs.opencover.reportsPaths="**/coverage.opencover.xml" \
/d:sonar.coverage.exclusions="**/Program.cs,**/Migrations/**,**/Configuration/*Options.cs" \
/d:sonar.pullrequest.key="$CI_MERGE_REQUEST_IID" \
/d:sonar.qualitygate.wait=true
Auf Merge Requests blockiert das Quality Gate — aber es beurteilt nur die Änderungen des MR, nicht die gesamte Altlast. Pre-existing Debt hält also keinen unbeteiligten PR auf. Das ist das „Clean as You Code"-Prinzip: Der neue Code muss sauber sein, der Altbestand wird separat und planbar abgetragen (SonarSource: Clean as You Code).
Das Projekt hält ohnehin strenge Code-Regeln ein — Sonar ist die Ebene, die sie über die ganze Codebase und über die Zeit durchsetzt, nicht nur lokal beim Build. So weit, so rund. Bis man entdeckt, dass genau dieses Setup auf eine tückische Art lügen kann.
Eine Zahl, die nicht stimmte
Hier kommt der Teil, den die „lass die KI das eben einrichten"-Fraktion unterschätzt. Ein Scanner aufzusetzen ist trivial. Ihn so aufzusetzen, dass er die Wahrheit sagt, ist die eigentliche Arbeit — und der teuerste Fehler ist unsichtbar. Er wirft keinen Error. Er meldet grün und lügt.
Bei mir fing es harmlos an: Die Pipeline war grün, das Quality Gate zufrieden. Stutzig machte mich eine einzelne Zahl, die nicht passte — ein Service, von dem ich wusste, dass er nahezu vollständig getestet war, kam mit 46 % Coverage zurück. Der nächste Lauf, ohne jede Code-Änderung, zeigte wieder einen anderen Wert. Eine Coverage, die ohne Zutun zwischen Läufen springt, ist kein Messwert — sie ist ein Symptom.
Die Ursache lag nicht in den Tests, sondern im Zuschnitt der Pipeline. Der Sonar-Job lief im selben Workdir wie der vorausgehende Build-Job. Ein inkrementeller dotnet build überspringt dann die Kompilierung bereits gebauter Projekte — und der SonarScanner für .NET sieht nur die Dateien der Projekte, die in seinem Fenster tatsächlich kompiliert werden. Was übersprungen wurde, fiel still aus der Analyse: keine Roslyn-Analyzer, keine Coverage, keine Spur im Report. Je nachdem, was der vorherige Job zufällig schon gebaut hatte, schrumpfte die analysierte Codebasis — und mit ihr die gemeldete Coverage auf besagte 46 % statt der realen ~97 %.
Der Fix ist am Ende eine einzige Zeile: --no-incremental im Sonar-Build erzwingt eine vollständige Kompilierung, damit jeder Analyzer über jede Datei läuft. Load-bearing — eine Zeile, ohne die alle Zahlen im Dashboard Fiktion sind.
Das ist der Kern: Statische Analyse ist genau deshalb wertvoll, weil sie nicht rät — aber dieser Wert steht und fällt mit der Konfiguration. Und dieselbe KI, die den Code generiert, ist nicht die Instanz, die ihr eigenes Prüf-Setup absegnen sollte. Das ist die Handwerks-Seite. Die andere Seite ist Governance — und die sieht man am besten im Enterprise.
Praxis: ein Enterprise-Mandat
In einem meiner Enterprise-Mandate — ein Industriekonzern mit vielen Teams — zeigt sich die zweite Hälfte des Bilds: nicht ein Repo sauber halten, sondern Qualität über viele Teams hinweg wiederholbar machen. Hier laufen die .NET-Services über Azure DevOps Pipelines, und die Sonar-Integration kommt aus einem zentralen, geteilten Template-Repo (DevOps/sonar-templates), das jede Service-Pipeline als Ressource einbindet:
resources:
repositories:
- repository: sonar_templates
type: git
name: 'DevOps/sonar-templates'
ref: 'refs/heads/master'
Der Effekt: Quality-Profile, Gate-Schwellen und Scanner-Setup sind einmal zentral konfiguriert und nicht in dutzende Pipelines kopiert, die langsam auseinanderdriften. Ein Standard gilt für alle, Änderungen passieren an einer Stelle. Ein skipSonar-Parameter existiert — als bewusste, sichtbare Ausnahme für Sonderfälle wie Hotfixes, nicht als stiller Default, an dem die Prüfung unbemerkt verschwindet. Und SonarLint liegt mit committeter Regel-Konfiguration (.sonarlint/) direkt in der IDE, sodass dieselben Regeln schon beim Tippen greifen, nicht erst im CI.
Das ist der Unterschied zwischen „ein Tool, das jemand mal angeworfen hat" und einer gepflegten Qualitäts-Infrastruktur: zentral versioniert, konsistent über Teams, mit Audit-Trail und Approval drum herum. Konkret heißt das: derselbe Qualitätsstandard in jedem Repo, ein nachvollziehbarer Nachweis für jedes Audit, und kein Setup, das mit der einen Person verschwindet, die es eingerichtet hat. Genau diese Ebene liefert dir kein Modell nebenbei. Womit sich der Kreis schließt — zur Frage, wie KI und Sonar eigentlich zusammenspielen.
Sonar und KI sind Komplemente, keine Konkurrenten
So setze ich beide zusammen ein, und so empfehle ich es:
| KI-Modell (LLM) | Static Analysis (Sonar) | |
|---|---|---|
| Stärke | Intent, Logik, Kontext, Geschwindigkeit | Determinismus, Vollabdeckung, Trend |
| Rolle | Generieren + erklärendes Review | Hartes Gate + Security-Nachweis |
| Findet | „tut nicht, was gemeint war" | „reißt Regel X, neue Vulnerability Y" |
| Schwäche | nicht reproduzierbar, Diff-Sicht | versteht Intent nicht, False Positives |
Die KI generiert und gibt das schnelle, kontextstarke Feedback. Sonar zieht die deterministische, auditierbare Linie, die im CI hält. Wo Sonar False Positives produziert, hilft die KI beim Einordnen. Wo die KI Logikfehler übersieht, fängt sie der menschliche Review — den beide Tools entlasten, aber keiner ersetzt. Mehr zur Security-Seite dieses Zusammenspiels in Wie KI-Agents Zugangsdaten leaken.
„Aber moderne Modelle vermeiden viele Funde doch selbst?"
Das stimmt — und es ist das ehrlichste Gegenargument. Die aktuelle Generation von Coding-Modellen räumt beim Generieren bereits viele klassische Sonar-Funde ab: ungenutzte Variablen, offensichtliche Null-Referenzen, triviale Code Smells. Wer das als „dann braucht es Sonar nicht mehr" liest, verwechselt allerdings, wofür das Tool eigentlich da ist.
Genau dadurch verschiebt sich der Wert von Sonar — weg von Style- und Lint-Fragen, die das Modell ohnehin erledigt, hin zu dem, was ein Modell strukturell nicht liefert: Reproduzierbarkeit, ein hartes Gate, Trend über die Zeit, auditierbarer Security-Nachweis. Die billigen Funde verschwinden; die teuren — die, bei denen Verlässlichkeit und Nachweisbarkeit zählen — bleiben genau dort, wo der deterministische Scanner unverzichtbar ist. Das Werkzeug wird also nicht überflüssig — es rückt nur an seine eigentliche Stelle.
Fazit
Am Ende stehen zwei verschiedene Aufgaben nebeneinander: Ein Modell erzeugt Code, ein Analyzer verifiziert ihn. Die KI macht gerade die erste billig — die zweite bleibt, und mit ihr die deterministische Instanz, die im CI hart Nein sagt, wenn etwas die Regeln reißt.
Wie das in der Praxis schiefgeht, hat die 46 %-Episode gezeigt. Deshalb baue ich solche Setups selbst und halte sie in Schuss — und kann mich gerade darum auf KI für den schnellen Teil verlassen.
Wenn du KI-Geschwindigkeit in deiner Delivery willst, ohne die Qualitäts- und Security-Schranke aufzugeben — und ein Setup brauchst, das die Wahrheit sagt statt nur grün zu leuchten — lass uns reden.
