Das eigene Defekt-Profil von KI-Code — warum grüne Tests nicht mehr reichen

Wir messen die falsche Dimension

Wenn du in den letzten zwei Jahren AI-generierten Code reviewt hast, kennst du den Reflex: Tests laufen durch, der Algorithmus sieht plausibel aus, die Schnittstelle ist stimmig — Pull Request approved. Dieser Reflex ist antrainiert. Zehn Jahre lang haben wir Junior-Code so reviewt, und der Reflex passt zu Junior-Code. AI-Code ist nicht Junior-Code. Er hat ein eigenes Defekt-Profil.

Im selben Forschungsfenster Anfang Mai 2026 sind zwei Papers erschienen, die diesen Befund aus zwei unterschiedlichen Richtungen quantifizieren — und beide treffen dieselbe Wunde.

Die erste Studie kommt von einer Gruppe an der Concordia University in Montréal (Cai Zhu, Tsantalis, Rigby, 2026). Sie haben eine systematische Audit von Technical Debt in AI-generierter Software durchgeführt: 90 zufällig gezogene Probleme aus dem CodeContest-Dataset, sechs Modelle (Gemini 2.5 Pro, Llama 3.3-70b, deepseek-coder, Qwen3-coder in zwei Größen) plus Human-Baseline. Resultat: Die Korrelation zwischen Code-Volumen (Total Lines of Code) und architektonischem Verfall liegt bei Spearman ρ = 0.94, p < 0.001. „Fast perfekt", schreiben die Autoren — und mit p < 0.001 ist das nicht Anekdote, sondern statistisch belastbar.

Die zweite Studie kommt von Mukund Pandey (2026). Er nimmt sich die Eval-Seite vor: Sieben Production-Failure-Modes für agentische Systeme, getestet gegen die Standard-Metriken-Toolbox — ROUGE, BERTScore, Accuracy/AUC, plus die agentischen Benchmarks HELM, MT-Bench, AgentBench, BIG-bench. Resultat: Vier der sieben Failure-Modes werden komplett übersehen. Drei weitere werden nur nach mehreren Eval-Zyklen erkannt — also zu spät, um in Production zu reagieren. Sieben von sieben sind unter Standard-Metriken nicht zuverlässig fassbar.

Beides zusammen ergibt eine konkrete Diagnose: AI-generierter Code hat ein eigenes Defekt-Profil, und unsere Standard-Werkzeuge messen die falsche Dimension. Funktionale Korrektheit ist nicht das Problem; Architectural Complexity Management ist es. Wie sich Code-Review und Production-Eval daran anpassen müssen — am Ende des Artikels.

Die maschinelle Signatur — was Production-Audits an KI-Code finden

Cai Zhu et al. nennen ihre Studie eine "systematic audit of technical debt in AI-generated software", und das ist die richtige Lesart: keine Anekdote, kein Twitter-Befund, sondern Multi-Scale-Analyse von 90 algorithmischen Problemen plus 20 Application-Scenarios. Das Tool für die Smell-Detection ist PyExamine, ein etablierter statischer Analyzer für Python; gemessen werden drei Smell-Klassen — Code-Level (kleine Patterns wie überlange Zeilen), Structural (mittlere Patterns wie überlange Methoden) und Architectural (große Patterns wie zyklische Modul-Abhängigkeit, Hub-Like Dependency, Circular Dependency).

Diagramm mit drei Spearman-Korrelations-Werten zwischen Code-Volumen (TLoC) und Code-Smell-Anzahl auf den drei Smell-Ebenen: Code-Level ρ=0,53, Structural ρ=0,59, Architectural ρ=0,94. Die Architektur-Korrelation ist nahezu perfekt.

Das Volume-Quality Inverse Law

Die zentrale Korrelation des Papers ist nicht eine, sondern drei. Die Total Lines of Code korrelieren mit:

Code-Level-Smells: ρ = 0.53 (p = 0.017)
Structural-Smells: ρ = 0.59 (p = 0.007)
Architectural-Smells: ρ = 0.94 (p < 0.001)

Spearman ρ misst den monotonen Rang-Zusammenhang zweier Größen auf einer Skala von −1 bis +1; der p-Wert quantifiziert die Restwahrscheinlichkeit, dass der Befund Zufall ist (hier unter 0,1 %). Auf der untersten Ebene ist die Korrelation moderat. Auf der Architektur-Ebene ist sie fast perfekt. Das ist die Form des Befunds: Je mehr Code AI generiert, desto stärker zerfällt die Architektur — nicht linear, sondern fast deterministisch. Du kannst aus dem reinen Code-Volumen mit hoher Sicherheit den Architektur-Schaden vorhersagen, ohne den Code überhaupt zu lesen.

Das Paper formuliert das als „Volume-Quality Inverse Law". Der Begriff ist Marketing-tauglich, aber er hält dem Datenpunkt stand. ρ = 0.94 ist der härteste Befund aus den letzten zwei Jahren AI-Coding-Empirie, der mir untergekommen ist.

Der Reasoning-Complexity-Trade-off

Der zweite Befund schlägt direkt gegen eine andere Standard-Annahme: dass „bessere" Modelle „besseren" Code erzeugen. Cai Zhu et al. messen Long-Method-Instanzen pro Modell auf den 90 CodeContest-Problemen:

Modell	Long-Method-Instanzen (Zero-Shot)
Qwen-Coder-480b	11
Gemini-2.5-pro	5
Llama-3-70b	0
Mensch (Baseline)	1

Die Reihenfolge ist nicht die der „Modell-Stärke" auf klassischen Benchmarks. Auf Benchmarks würde Qwen-480b vor Gemini-2.5-pro vor Llama-70b liegen. Auf Method-Bloat liegt sie genau anders herum: das fähigste Modell schreibt am meisten aufgeblähten Code.

Das Paper-Quote bringt es präzise: "greater model capability did not correlate with cleaner code...it correlated with method bloat." Wer ein „capable model" einsetzt, kauft sich nicht weniger Defekte — er kauft sich eine andere Defekt-Klasse: aufgeblähten, gekoppelten, schwer wartbaren Code.

Few-Shot-Prompting macht es schlechter

Der dritte Sub-Befund ist der für die Praxis schmerzhafteste. Wenn die Standard-Antwort auf KI-Code-Probleme „besseres Prompting" ist — strukturierte Few-Shot-Beispiele, präzisere Spezifikation, mehr Kontext —, dann sollte das den Decay reduzieren. Cai Zhu et al. messen das auch.

Das Resultat: Few-Shot-Prompting verschlechtert Method-Bloat. Qwen-480b geht von 11 auf 13 Long-Method-Instanzen, Gemini-2.5-pro von 5 auf 8. Die Spezifizität der Anforderungen (welche Stage des Application-Scenarios) hat keinen statistisch signifikanten Effekt auf Smell-Counts: p > 0.8 in jeder Smell-Kategorie. Mit anderen Worten: Prompting-Engineering bekämpft nicht den Decay; es verschiebt ihn höchstens.

Das ist die maschinelle Signatur. Nicht weniger Defekte, sondern eine andere Defekt-Klasse. Funktionale Korrektheit bleibt erreichbar; architektonische Maintainability erodiert systematisch. Im nächsten Kapitel zeigt sich, warum unsere Eval-Werkzeuge dieses Phänomen nicht messen können.

Die Eval-Lücke — was Standard-Metriken nicht messen

Bevor wir in die zweite Studie einsteigen, eine Vorbemerkung: Pandey ist Independent Researcher; sein Framework PAEF wird in vier kontrollierten Experimenten mit synthetischen Traces validiert, nicht an echten Production-Logs eines Unternehmens. Das macht es zum Vorschlag, nicht zum etablierten Standard. Wir behandeln es entsprechend — als belastbare Diagnose der Eval-Lücke, nicht als fertige Production-Lösung.

Sieben Failure-Modes, die in Lab-Bedingungen nicht passieren

Pandeys Beobachtung ist die: bestehende Eval-Frameworks (HELM, MT-Bench, AgentBench, BIG-bench) und die klassischen Metriken (ROUGE, BERTScore, Accuracy/AUC) sind für kontrollierte, single-session Lab-Settings gebaut. Was in Production bricht, sieht anders aus. Er nennt sieben Failure-Modes:

Cascading Decision Error: Eine frühe falsche Entscheidung propagiert downstream und akkumuliert Folge-Belege, die intern kohärent wirken — das System ist konsistent falsch, nicht zufällig falsch.
Silent Degradation via Availability-Truth Decoupling: Tools liefern schema-valide aber inhaltlich unvollständige Antworten. Der Agent baut korrekt aussehende Entscheidungen auf fehlender Information.
Distribution Collapse: Output-Verteilungen werden progressiv enger; die Diversität erodiert, während aggregierte Metriken stabil bleiben.
Consistency Collapse Across Entry Points: Identische Anfrage über API, UI und Batch produziert unterschiedliche Entscheidungen — das Modell ist surface-sensitiv.
Explanation-Decision Decoupling: Korrekte Entscheidung mit inkorrekter Post-hoc-Erklärung. Die attribuierten Features sind nicht die kausal wirksamen.
Silent Correctness Erosion Under Latency Pressure: Hard-Latency-Budgets triggern degradierte Inference-Pfade. SLA-Metriken passen, Qualität sinkt still.
Proxy Goal Convergence: Reward Hacking auf Systemebene. Das System optimiert messbare Proxies weg vom echten Ziel.

Lies die Liste zweimal. Das sind nicht akademische Edge-Cases. Das sind die Production-Pathologien, die Teams jeden Tag erleben — meistens, ohne es zu merken.

Detection-Matrix der sieben Production-Failure-Modes gegen Standard-Eval-Metriken und das PAEF-Framework: vier Modes komplett übersehen, drei nur mit Lag erkannt, PAEF detektiert alle sieben binnen eines Eval-Zyklus.

Sieben von sieben unter Standard-Metriken

Pandeys empirisches Resultat: Standard-Metriken erkennen vier dieser Failure-Modes komplett nicht. Drei weitere werden erkannt — aber erst nach "a lag of multiple evaluation cycles", wie Pandey schreibt. Auf Deutsch: zu spät, um in Production zu reagieren. Sieben von sieben sind also unter Standard-Metriken-Bedingungen problematisch — vier komplett blind, drei hoffnungslos verzögert.

Der Anker-Quote des Papers fasst es zusammen:

"They are gradual, systematic, and invisible to the metrics teams are most likely to be monitoring."

Was leicht zu messen ist (Accuracy, Latency, Error Rate) und was in Production zählt (sustained correctness, distribution health, causal explanation validity, true-objective alignment) sind verschiedene Dinge. Zwischen beiden klafft die Eval-Lücke.

PAEF als Vorschlag

Pandeys Antwort ist PAEF — ein Fünf-Dimensionen-Framework mit den Dimensionen Cascade Uncertainty, Tool Reliability, Distribution Health, Explanation Validity und Cross-Surface Consistency. Der Code ist quelloffen unter llm-eval-toolkit auf GitHub.

Ob PAEF die richtige Antwort ist, müssen Production-Validierungen zeigen. Was als Diagnose belastbar ist, ist die Eval-Lücke selbst — und sie wird auch im Engineering-Diskurs aufgegriffen: Konstantin Sabass — mein Mayflower-Kollege — verweist in einem internen Mayflower AI Lightning Talk vom Mai 2026 (Slides öffentlich) auf die Studie von Xia et al. (2025). Xias Untersuchung von 134 akademischen Agent-Eval-Quellen findet, dass 92,54 % ausschließlich End-to-End-Metriken nutzen und 93,28 % reine Pre-Deployment-Evaluationen sind. Production-Performance wird in der Forschungs-Community kaum systematisch gemessen — und das, was die Forschung vorgibt, übernimmt die Praxis.

Die gemeinsame Diagnose — Architectural Complexity Management

Die zwei Studien sind aus unterschiedlichen Richtungen geschrieben. Cai Zhu et al. schauen auf den Code, der herauskommt: zerfallende Architektur, die mit Code-Volumen skaliert. Pandey schaut auf das System im Betrieb: Failure-Modes, die unter Standard-Eval unsichtbar bleiben. Beide Befunde haben dieselbe strukturelle Form. Lokal sieht alles gut aus — Tests sind grün, einzelne Endpoints liefern korrekte Antworten, einzelne Code-Snippets sind plausibel. Global zerfällt es: Architektur-Smells akkumulieren, Production-Drift bleibt unsichtbar, Cascading Decisions häufen sich.

Cai Zhu et al. geben dem Phänomen einen Namen, der auch für Pandeys Befunde trägt:

"reframing the central problem of AI-based software engineering from one of code generation to one of architectural complexity management."

Das ist die Disziplin-Verschiebung, um die es geht. Code-Generation ist gelöst — Modelle generieren funktionalen Code zuverlässig. Architectural Complexity Management ist offen — Modelle managen ihn nicht, und unsere Werkzeuge messen es nicht.

Praktisch heißt das: nicht weniger AI, sondern andere Werkzeuge um AI herum. Tests sind eine Schicht, Architektur-Metriken sind eine zweite, Production-Eval ist eine dritte. „Bessere Prompts" ist keine eigenständige Schicht — die Code-Smells-Studie zeigt, dass Prompting-Engineering den Decay nicht stoppt. Strukturelle Constraints außerhalb der Prompts braucht es: Komplexitäts-Limits, Architektur-Verträge, Production-Monitoring.

Die nächsten zwei Kapitel zeigen, was das in der Code-Review-Praxis und in der Production-Eval-Praxis konkret bedeutet.

Was sich an Code-Reviews ändert

Die alte Frage ist nicht falsch — sie ist nicht hinreichend. „Tests grün, Edge-Cases bedacht, Schnittstelle sauber?" bleibt eine notwendige Bedingung. Was AI-Code aber zusätzlich braucht, ist eine zweite Frage-Schicht, und zwar die nach der Kopplungs-Signatur.

Konkret: Wie viele Klassen oder Module wurden für ein einzelnes Feature angefasst? Wie tief ist die Aufruf-Tiefe der neuen Methoden? Wie hoch ist die zyklische Kopplung zwischen dem neuen Code und existierenden Modulen? Wie groß ist die längste neue Methode? Wenn drei dieser Schwellen reißen, ist die Tests-grün-Aussage irrelevant — der Code wird in sechs Monaten unwartbar sein, egal wie korrekt er heute ist. Genau das ist die Aussage des Volume-Quality Inverse Law: Code-Volumen prognostiziert architektonischen Verfall mit ρ = 0.94, ohne Berücksichtigung der funktionalen Korrektheit.

Das Tooling dafür ist nicht neu. Statische Analyzer wie SonarQube, PyExamine oder vergleichbare existieren seit Jahren. Was neu ist, ist die Relevanz: ein statischer Analyzer als Pflicht-Layer für AI-Output, nicht als CI-Gate-Theater, sondern als Reviewer-Tool. Du schaust dir die Smell-Diagnose an, bevor du den PR-Approve-Button drückst.

Manuel Schipper, der über den Einsatz von 4 bis 8 parallelen Coding-Agents schreibt, bringt die Praktiker-Beobachtung auf den Punkt: agentische Coder seien zwar bei vielen Aufgaben "insanely smart", aber bei anderen fehle ihnen "taste and good judgement" — sie duplizieren oft Code und hinterlassen toten Code. Genau das ist die maschinelle Signatur in der Review-Praxis sichtbar — und genau das fängt ein PyExamine-Lauf in unter zehn Sekunden auf.

Was sich nicht ändert: Tests, Edge-Cases, Schnittstellen-Sauberkeit bleiben relevant. Die neue Schicht ergänzt, sie ersetzt nicht. Code-Review wird länger, nicht kürzer — und das ist der Tradeoff, mit dem du leben musst, wenn du Agent-Output in Production schickst.

Was sich an Production-Eval ändert

Public-Benchmarks wie HELM, MT-Bench, AgentBench oder BIG-bench sind Lab-Werkzeuge. Sie messen kontrollierte Tasks, Single-Session-Settings, mit verfügbarer Ground-Truth. Klassische Metriken — ROUGE, BERTScore, Accuracy/AUC — sind in derselben Tradition gewachsen. Pandeys Befund zeigt: keine davon erkennt die sieben Production-Failure-Modes zuverlässig. Wer Modell-Wahl auf Public-Benchmarks fußt und das war's, optimiert mit hoher Wahrscheinlichkeit gegen Noise.

Was Production-Eval messen muss, ist eine andere Disziplin: Continuous Evaluation auf Production-Traffic. Distribution Health (kollabieren die Outputs?), Cascade Uncertainty (propagieren frühe Fehler?), Cross-Surface Consistency (geben API/UI/Batch dieselbe Antwort?), Explanation Validity (sind die Erklärungen kausal?), Tool Reliability (verlieren Tools still die Substanz?). Das sind nicht Lab-Tests; das sind operative Monitoring-Disziplinen.

Sabass formuliert die Konsequenz im selben Talk aus dem Engineering-Blickwinkel: "In an ideal world the algorithm is swappable behind the validation harness." Modelle werden sich ändern, Prompts werden sich ändern, Pipelines werden sich ändern. Was bleiben muss, ist die Bewertungs-Maschinerie. Sie ist das eigentliche Asset — model-agnostisch, langlebig, projekt-spezifisch.

Praktisch heißt das: deine Production-Eval ist Code, den du wartest. Du definierst, was Erfolg in deinem Use-Case bedeutet, du baust Rubrics, du wartest sie über Modell-Releases hinweg. Die Bewertungs-Pipeline ist nicht „später" — sie ist die Bedingung dafür, das Defekt-Profil überhaupt zu sehen.

Take-Aways

Wir haben am Anfang gesagt, dass wir die falsche Dimension messen. Die zwei Befunde — Volume-Quality Inverse Law mit ρ = 0.94 und sieben von sieben Failure-Modes unter Standard-Metriken — sind aus zwei Richtungen derselbe Befund. Was AI-Code zu einer eigenen Defekt-Klasse macht, ist gerade nicht funktionale Korrektheit. Es ist Architektur, und es ist Eval-Disziplin.

Drei Take-Aways aus der Diagnose:

Code-Review für AI-Output bekommt eine zweite Schicht. Architektur-Metriken neben Tests. Statische Analyzer sind nicht neu; ihre Relevanz ist neu. Mach den PyExamine-Lauf zur Pflicht, bevor du Approve drückst.
Production-Eval ist nicht Public-Benchmark-Eval. Wer Modelle anhand HELM oder MT-Bench wählt und das war's, optimiert auf Lab-Performance, nicht auf das, was bei dir in Production zählt. Eigene Production-Eval-Pipeline ist Pflicht, nicht Nice-to-Have.
Prompt-Engineering allein reicht nicht. Few-Shot verschlechtert Method-Bloat statt es zu verbessern; Spezifizität ist statistisch wirkungslos (p > 0.8). Strukturelle Constraints außerhalb der Prompts braucht es.

Cai Zhu et al. schließen ihr Paper mit einer Formulierung, die fast eine Definition von Spec-Driven Development ist: "future progress depends on equipping agents with explicit architectural foresight to ensure the software they build is not just functional, but also maintainable." Wenn du SDD bislang als methodologisches Detail behandelt hast, ist das hier der empirische Anker dafür, es ernster zu nehmen — die SDD-Serie auf diesem Blog behandelt das im Detail.

Wer parallel zur Code-Lens auch eine Memory-Lens auf Agent-Engineering setzen will: Agent Memory Security zeigt eine zweite Engineering-Diagnose — diesmal nicht zum Code, sondern zum Gedächtnis. Beide Stücke haben dieselbe Form: lokal sieht es gut aus, global ist eine eigene Disziplin nötig.