Warum KI-Modelle unterschiedliche Code-Probleme finden

Ich habe dasselbe 1000-Zeilen-Skript an drei Frontier-Modelle gegeben und sie um eine Code-Analyse gebeten. Gleiche Datei, gleiche Frage, kein Unterschied im Auftrag. Zurück kamen drei verschiedene Listen. Es gab eine Schnittmenge — die offensichtlichen Sachen fanden alle —, aber jedes Modell hatte auch Funde, die kein anderes hatte.

Mein erster Reflex war, das als Schwäche zu lesen: Wenn die Modelle sich nicht einig sind, kann ich keinem so recht trauen. Inzwischen sehe ich es umgekehrt. Genau diese Streuung ist der Grund, warum mehrere Modelle zusammen mehr finden als das beste Einzelmodell allein. Warum das so ist, will ich hier auseinandernehmen.

Ein LLM durchsucht Code nicht — es liest selektiv

Der erste Denkfehler steckt schon im Wort “durchsuchen”. Ein klassischer Static Analyzer geht eine Codebasis erschöpfend durch: jede Regel gegen jede Zeile, deterministisch, vollständig im Rahmen seiner Regelmenge. Was er kann, findet er immer, und zwar überall.

Ein Sprachmodell arbeitet anders. Es liest den Code nicht Zeile für Zeile gegen eine feste Checkliste ab, sondern richtet seine Aufmerksamkeit selektiv aus — getrieben davon, was im jeweiligen Kontext relevant erscheint. Das ist näher an einem erfahrenen Reviewer, der eine Datei überfliegt und an drei Stellen hängenbleibt, als an einem Linter, der mechanisch alles abklappert. Daraus folgt: Was ein Modell findet, hängt nicht nur davon ab, was im Code steht, sondern auch davon, worauf es in diesem Durchlauf seine Aufmerksamkeit gelegt hat.

Schon dasselbe Modell findet zweimal Verschiedenes

Bevor wir verschiedene Modelle vergleichen, lohnt der Blick auf ein einzelnes. Selbst wenn ich exakt dasselbe Modell zweimal mit derselben Datei laufen lasse, bekomme ich nicht zwangsläufig dasselbe Ergebnis.

Der Grund liegt im Sampling. Bei jedem Token wählt das Modell aus einer Wahrscheinlichkeitsverteilung. Die Temperatur steuert, wie stark es dabei vom wahrscheinlichsten Pfad abweichen darf. Liegt sie über null, ist ein Zufallselement im Spiel — und das pflanzt sich fort. Ein früh anders gewähltes Wort lenkt die folgende Analyse in eine andere Richtung. Diese Pfadabhängigkeit bedeutet: Ein Lauf, der früh auf ein Nebenläufigkeitsproblem stößt, gräbt dort weiter; ein zweiter Lauf desselben Modells fängt vielleicht beim Fehlerhandling an und landet woanders.

Begrenzte Aufmerksamkeit priorisiert — und das erzeugt die Differenzmenge

Der zweite Grund ist die begrenzte Aufmerksamkeit. Der Attention-Mechanismus eines Modells kann nicht alles gleich gewichten; er priorisiert. Bei 1000 Zeilen kann ein Modell nicht jede Zeile mit jeder anderen in voller Tiefe in Beziehung setzen. Es muss entscheiden, worauf es schaut.

Das erklärt das Muster sauber: Die Schnittmenge der Funde — das, was alle Modelle nennen — ist das Offensichtliche. Probleme, die so deutlich sind, dass sie unter fast jeder Priorisierung auffallen. Die Differenzmenge — das, was nur ein einzelnes Modell findet — ist das Subtile. Probleme, die nur sichtbar werden, wenn die Aufmerksamkeit zufällig oder durch Prägung genau auf diese Stelle fällt. Und genau die subtilen Bugs sind die teuren.

Modelle haben Schwerpunkte

Zum Sampling und zur Priorisierung kommt ein dritter Faktor: Modelle sind unterschiedlich geprägt. Training, Feinabstimmung und Ausrichtung führen dazu, dass Modelle Schwerpunkte mitbringen. Das eine fällt eher über Sicherheitslücken, das andere über Performance-Probleme, ein drittes über logische Inkonsistenzen oder fehlende Randfälle.

Diese Prägung ist kein Zufall pro Lauf, sondern eine systematische Neigung. Sie ist der Grund, warum die Differenzmenge nicht nur Rauschen ist, sondern oft komplementär: Modell A bringt die Security-Funde mit, die Modell B übersieht, und umgekehrt. Drei verschiedene Schwerpunkte decken zusammen mehr Fläche ab als dreimal derselbe.

Was der reale Test ergeben hat

Ich habe das nicht nur theoretisch durchdacht, sondern an einem konkreten kritischen Skript getestet. Dieselbe Datei, verschiedene Modelle und Einstellungen, jeweils bewertet nach Summe der validen Funde.

| Rang | Modell / Setup | Σ Funde | Anmerkung | | --- | --- | --- | --- | | 1 | Opus 4.8 xHigh DeepThink, Multi-Agent | 15 | stärkste Liste, aber teuer | | 2 | Gemini 3.1 Pro High | 14,5 | bester Single-Pass, Preis-Leistungs-Sieger | | 3 | Opus 4.8 Med DeepThink | 13,5 | | | 4 | Sonnet 4.6 | 13 | mit Zeilen-Ankern, gut verifizierbar | | 5 | Gemini 3.5 Flash High | 12 | überrascht positiv | | 6 | Google Flash 3.5 Low | 10,5 | einziger False-Positive (#8) | | 7 | Haiku 4.5 | 10,5 | verpasst den Top-Bug (#1) |

Ein achter Lauf mit Opus, der vorab schon Kontakt mit der Datei hatte, lief außer Konkurrenz — das Ergebnis war durch den Vorkontakt kontaminiert und damit nicht vergleichbar.

Die Pointe steht in der ersten Spalte. Zwischen Platz eins und zwei liegen 0,5 Punkte. Der Abstand an der Spitze ist winzig. Der große Sprung in der Tabelle kommt nicht daher, dass ein Modell radikal stärker wäre als das nächste — er kommt aus der Orchestrierung. Der Multi-Agent-Lauf führt, weil er mehrere Sichten zusammenführt, nicht weil ein einzelnes Modell überlegen ist.

Was ich als Nächstes teste

Aus dieser Beobachtung folgen drei Tests, die ich konkret vorhabe.

Erstens den Determinismus messen. Ich lasse dasselbe Modell bei Temperatur null mehrfach über dieselbe Datei laufen. Wenn die Ergebnisse dann stabil bleiben, kann ich Zufall vom Können trennen — und sehe, wie groß der Sampling-Anteil an der Streuung wirklich ist.

Zweitens eine Ground Truth bauen. Ich baue bekannte Bugs gezielt in ein Skript ein, sodass ich genau weiß, was drinsteckt. Erst dann lässt sich Recall sauber messen: Welcher Anteil der tatsächlich vorhandenen Probleme wird gefunden? Ohne diese Referenz vergleiche ich nur Listen gegeneinander, nicht gegen die Wahrheit.

Drittens ein bewusst gestreutes Ensemble gegen den besten Single-Pass antreten lassen. Wenn die Streuung wirklich die Stärke ist, muss eine Orchestrierung aus absichtlich verschieden geprägten Modellen den stärksten Einzellauf schlagen — und zwar reproduzierbar.

Fazit

Drei Modelle, drei Listen — das ist kein Defekt, sondern Information. Die Übereinstimmung zeigt das Offensichtliche, die Abweichung das Subtile. Sampling, begrenzte Aufmerksamkeit und unterschiedliche Prägung sorgen gemeinsam dafür, dass kein einzelnes Modell die ganze Fläche abdeckt. Der reale Test bestätigt es: Der Vorsprung an der Spitze ist klein, der Hebel liegt im Zusammenführen. Ob sich das sauber messen lässt, klärt der nächste Durchgang — die Tests stehen, das Ergebnis ist offen.

Die praktische Lehre gilt aber schon jetzt: Eine Streuung aus Modellen schlägt jedes Einzelmodell — und genau darum geht es, sie als orchestriertes Ensemble laufen zu lassen, statt alles auf eines zu setzen.

Entdecke mehr

Blog

Effort-Level und Deep Thinking: zwei unabhängige Achsen bei KI-Aufgaben

Effort skaliert Breite, Deep Thinking skaliert Tiefe. Wann welche Stufe sinnvoll ist — mit drei klaren Beispielen und einer Faustregel.

Glossar

Ensemble / Multi-Modell-Orchestrierung

Ensemble bezeichnet das Kombinieren mehrerer bewusst variierter LLM-Läufe oder Modelle, deren Funde sich ergänzen. Multi-Modell-Orchestrierung steuert diese Läufe über Orchestratoren mit Sub-Agenten, sodass die Vereinigung der Ergebnisse größer ist als jeder Einzellauf.

Lexikon

Function Calling / Tool Use

Wie ein LLM Werkzeuge aufruft: Tool-Definition als Schema, Modell wählt Funktion und Argumente, Ergebnis zurück ins Gespräch — der Grundbaustein jedes Agenten.

Themenuebersicht

KI-KonzepteAgentenKI-Werkzeuge