KI schreibt den Code – doch wer prüft die Fehler?

Im Juni 2026 startete ein Team ein ehrgeiziges Optimierungsprojekt: Ein KI-System sollte für ein Geldtransportunternehmen Routenpläne erstellen, die den Cashflow von 20 Geldautomaten optimieren. Innerhalb weniger Stunden lieferte die KI 17 Dateien – perfekt formatiert, mit Tabellen, Diagrammen und scheinbar korrekten Algorithmen. Doch dann entdeckte das Team drei schwerwiegende Fehler, die weder Code-Reviews noch statische Analysetools aufdecken konnten. Die Geschichte zeigt, warum moderne Softwareentwicklung an einer entscheidenden Schwachstelle krankt.

Ein Algorithmus mit beeindruckenden Zahlen – und versteckten Risiken

Das Projekt zielte darauf ab, die klassische Methode zur Lösung des Vehicle Routing Problems (VRP) zu übertreffen. Bei der herkömmlichen Herangehensweise – dem Capacitated Vehicle Routing Problem (CVRP) – kommt es regelmäßig zu Engpässen: Im Schnitt fallen 42 % der Geldautomaten wegen zu hoher Nachfrage aus. Die KI sollte diese Quote mit einem maschinellen Lernmodell namens Stochastic Programming Optimization (SPO+) auf 25 % reduzieren und damit fast an die theoretische Idealösung heranreichen. Die Einsparungen beliefen sich auf 51 % der Kosten, die durch Leerfahrten und Nachfüllungen entstehen.

Doch die wahre Herausforderung lag nicht in der Optimierung selbst, sondern in der Überprüfung des generierten Codes. Denn die KI lieferte nicht nur eine Lösung – sie präsentierte auch eine vollständige Implementierung in Q#, einer Programmiersprache für Quantenalgorithmen. Das Team wollte wissen, ob diese Methode mit etablierten Verfahren mithalten konnte. Die Ergebnisse waren zunächst verblüffend: Der Quantenalgorithmus QAOA (Quantum Approximate Optimization Algorithm) erzielte dieselbe Energie wie ein klassisches gemischt-ganzzahliges lineares Programm (MILP). Doch etwas stimmte nicht.

Der erste Widerspruch: Gleiche Energie, unterschiedliche Ergebnisse

Die Tabelle der ersten Testläufe zeigte ein paradoxes Bild:

Methode          Energie   Nebenbedingungen erfüllt?
PuLP/MILP        -2,5599   ✅
QAOA (p=1)      -2,5599   ⚠️ Nein (Verletzung)
QAOA (p=3)      -2,5599   ⚠️ Nein (Verletzung)

Wie konnte ein Algorithmus, der Nebenbedingungen verletzte, dieselbe Energie wie eine optimale Lösung erreichen? Und warum lieferten zwei verschiedene Quanten-Schaltungen (p=1 und p=3) exakt dasselbe Ergebnis – trotz unterschiedlicher Tiefe? Die Antwort lag nicht in der Mathematik, sondern im Code selbst.

Drei Bugs, die selbst moderne Tools übersehen

Bug 1: Die Strafgewichtung war zu niedrig

In der Datei phase2c_qaoa_simulator.py war der Parameter für die Strafgewichtung der Kapazitätsverletzung auf 0,5 gesetzt. Bei einer Gesamtlast von 330.000 Türkischen Lira (TL) und einer Fahrzeugkapazität von 250.000 TL führte dies zu einer minimalen Strafe:

LAMBDA_C = 0.5  # Ursprünglicher Wert
Strafe = 0.5 × (1,32 - 1,0)² = 0,051 Einheiten

Zum Vergleich: Die Routenkosten lagen zwischen 1,2 und 3,5 Einheiten. Die Strafe betrug somit weniger als 1,5 % der Gesamtkosten – der Algorithmus konnte die Verletzung schlicht nicht erkennen. Erst durch die Anpassung auf 40,0 wurde die Strafe spürbar:

LAMBDA_C = 40.0  # Korrigierter Wert

Bug 2: Widersprüchliche Nebenbedingungen wurden ignoriert

Das klassische MILP-Modell enthielt zwei Regeln:

• Alle Geldautomaten müssen besucht werden.
• Die Fahrzeugkapazität darf nicht überschritten werden.

Doch die Summe aller Geldbestände (330.000 TL) überstieg die Kapazität (250.000 TL) – eine unlösbare Situation. Trotzdem gab der Solver PuLP/CBC die Lösung als „optimal“ aus, ohne Warnung. Erst eine manuelle Überprüfung deckte den Fehler auf.

Bug 3: Falsche Messmethode führte zu Scheinresultaten

Die Quantenalgorithmen p=1 und p=3 lieferten identische Ergebnisse, weil das Team die argmax-Lösung statt der tatsächlichen Erwartungsenergie verglich. Für jede Schaltungstiefe wurde dieselbe Bitfolge [1,1,1,1,1] ausgewählt, was zu denselben Werten führte – obwohl die Algorithmen intern unterschiedliche Lösungen fanden.

Die korrigierten Zahlen – und was sie verraten

Nach der Fehlerbehebung präsentierte sich ein realistischeres Bild:

Methode              Energie   Energieabweichung   Nebenbedingungen
Brute Force         −34,856    0 %               ✅
MILP (korrigiert)   −34,856    0 %               ✅
QAOA p=1            −32,686    2,3 %             ✅
QAOA p=2            −31,689    3,5 %             ✅
QAOA p=3            −32,815    2,3 %             ✅

Die Ergebnisse bestätigten, dass QAOA zwar funktioniert, aber mit einer Abweichung von 2–4 % hinter der optimalen Lösung zurückbleibt – ein Wert, der mit der Fachliteratur und physikalischen Erwartungen übereinstimmt. Doch die eigentliche Lehre aus diesem Projekt ist grundlegender.

Warum statische Tools scheitern – und wie eine Lösung aussehen könnte

Alle drei Bugs hatten eines gemeinsam: Der Code sah korrekt aus. Kein Linter hätte Syntaxfehler gefunden, keine Architekturregel wäre ausgelöst worden. Selbst erfahrene Entwickler hätten die Fehler in einem Review übersehen, weil sie sich auf die Struktur statt auf das Verhalten konzentrierten.

Die Kernbotschaft des Teams lautet daher: „Code muss nicht nur syntaktisch, sondern auch verhaltensbasiert geprüft werden.“ Doch genau hier klafft eine Lücke im modernen Software-Engineering. Während Tools wie Architecture Guard oder Security Review statische Analysen durchführen, fehlt es an Mechanismen, die das tatsächliche Verhalten eines Programms gegen die intendierte Spezifikation vergleichen.

Der „Golden Demo“-Ansatz

Die Lösung könnte in einem verhaltensgetriebenen Prüfprozess liegen, der bereits in der Planungsphase beginnt:

• Golden Example als Referenz: Aus den Akzeptanzkriterien und Testfällen der Spezifikation wird eine kleine, ausführbare Referenzimplementierung (Golden Example) generiert. Diese dient als deterministischer Benchmark für das erwartete Verhalten.

• Vergleich nach der Implementierung: Sowohl das Golden Example als auch der finale Code werden mit denselben Testvektoren ausgeführt. Weicht das Ergebnis ab, wird ein Drift Report erstellt.

• Automatisierte Merge-Prüfung: Vor dem Zusammenführen des Codes wird sichergestellt, dass das Programm läuft und das tut, was intendiert war. Diese beiden Fragen werden aktuell am häufigsten übergangen.

Hätte die Golden Demo-Methode die drei Bugs verhindert?

• Bug 1: Eine Spezifikation mit dem Testvektor „Strafgewicht muss größer sein als maximale Routenkosten“ hätte den Fehler bei der Merge-Prüfung sofort aufgedeckt.
• Bug 2: Ein Golden Example mit der Regel „Lösung ist nur gültig, wenn alle Nebenbedingungen erfüllt sind“ hätte den Widerspruch im MILP-Modell sichtbar gemacht.
• Bug 3: Ein Vergleich der tatsächlichen Erwartungsenergie statt der argmax-Lösung hätte die Diskrepanz zwischen p=1 und p=3 erkennbar gemacht.

Die Technologiebranche steht vor einem Paradox: KI generiert Code in Rekordzeit – doch die Überprüfung seiner tatsächlichen Funktionsweise hinkt hinterher. Tools wie Golden Demo könnten diese Lücke schließen und sicherstellen, dass nicht nur der Code, sondern auch seine Logik den Anforderungen entspricht. Die Zukunft des Software-Engineerings wird nicht nur von schnelleren Algorithmen geprägt sein, sondern von robusterer Validierung.

Es ist an der Zeit, die nächste Evolutionsstufe einzuleiten.