Qualität von LLM-generiertem Code: eine Praxisstudie über 12 Projekte

Die meisten Diskussionen über KI-generierten Code drehen sich um die Frage, ob er funktioniert. Das ist die falsche Frage. Für Produktivsysteme ist entscheidend, ob er zuverlässig funktioniert, ob ihn Ingenieure warten können, die ihn nicht geschrieben haben, und ob er Fehler in einem Maß verursacht, das eine kontinuierliche Auslieferung noch zulässt.

Wir wollten diese Fragen mit Daten beantworten, nicht mit Meinungen.

Methodik

Wir haben 12 Produktivprojekte ausgewertet, die zwischen Juni 2025 und Januar 2026 mit der KI-orchestrierten Entwicklungsmethodik von NOSOTA geliefert wurden. Jedes Projekt wurde von einem bis drei erfahrenen Ingenieuren in der Rolle von Orchestratoren gebaut; KI-Agenten erzeugten den Großteil des Produktionscodes auf Grundlage strukturierter Vorgaben und unter menschlicher Prüfung.

Die Projekte umfassen Unternehmens-Backends, plattformübergreifende mobile Apps, Webportale und Systeme mit ML-Integration. Zusammen stehen sie für über 200.000 Codezeilen, mehr als 1.400 automatisierte Tests und mehr als 350 REST-API-Endpunkte. Jede Kennzahl lässt sich auf die Git-Historie, CI/CD-Protokolle und Issue-Tracker zurückführen.

Wir haben drei Dimensionen gemessen: Testabdeckung (Zeilen- und Zweigabdeckung laut CI), Fehlerdichte (Fehler pro tausend Codezeilen in den ersten 90 Tagen nach der Inbetriebnahme) und Wartbarkeit (die Zeit, die ein mit der Codebasis nicht vertrauter Ingenieur für eine nicht triviale Änderung benötigt).

Ergebnis 1: Die Testabdeckung übertrifft die Branchenwerte

Über die 12 Projekte hinweg lag der Median der Zeilenabdeckung bei 78 %, drei Projekte übertrafen 85 %. Die Zweigabdeckung – eine strengere Kennzahl – betrug im Durchschnitt 64 %. Zum Vergleich: Branchenumfragen weisen für Codebasen von Unternehmen durchweg eine durchschnittliche Zeilenabdeckung zwischen 40 % und 60 % aus.

Die Erklärung liegt in der Struktur, nicht im Heldentum. KI-Agenten erzeugen Tests als festen Bestandteil ihrer Ergebnisse, wenn sie eine sauber abgegrenzte Vorgabe erhalten. Die Kosten eines Tests sinken nahezu auf null, wenn der Agent ihn zusammen mit der Implementierung erstellt. Was in klassischen Arbeitsabläufen teuer ist – umfassende Testsuiten –, wird in der KI-orchestrierten Entwicklung zum Normalfall.

Entscheidend ist die Qualität der Vorgabe. Projekte, in denen der Orchestrator in jeder Agentenvorgabe ausdrückliche Abnahmekriterien festlegte, erreichten eine um 15 bis 20 Prozentpunkte höhere Abdeckung als Projekte, in denen die Testanforderungen implizit blieben.

Ergebnis 2: Die Fehlerdichte ist geringer – dank disziplinierter Prüfung

Der Median der Fehlerdichte lag über alle 12 Projekte bei 0,8 Fehlern pro tausend Codezeilen in den ersten 90 Tagen. Der Branchenrichtwert für erfahrene Teams liegt typischerweise bei 1 bis 5 Fehlern pro KLOC. Zwei Projekte verzeichneten im Messzeitraum keinen einzigen Fehler im Produktivbetrieb.

Dieses Ergebnis ist nicht darauf zurückzuführen, dass KI fehlerfreien Code erzeugt. Das tut sie nicht. In unseren Daten musste rund 12 % des KI-generierten Codes bei der menschlichen Prüfung vor dem Zusammenführen geändert werden. Die niedrige Fehlerrate verdankt sich dem Prüfprozess: Jede Zeile, die die KI liefert, durchläuft die Bewertung eines erfahrenen Ingenieurs, bevor sie in die Codebasis gelangt. Die Verbindung aus der Geschwindigkeit der KI und der Gründlichkeit menschlicher Prüfung ergibt Code, der schnell geschrieben und sorgfältig geprüft ist.

Projekte, in denen der Orchestrator die Prüfung übersprang oder überhastete – erkennbar an kürzeren Prüfzeiten in den Git-Metadaten –, wiesen drei- bis viermal so hohe Fehlerraten auf. Die Methodik funktioniert, wenn der Mensch im Prozess seinen Prüfauftrag ernst nimmt.

Ergebnis 3: Dokumentation macht den Code auch für andere wartbar

Wartbarkeit ist die Dimension, nach der Kunden am seltensten fragen und für die sie am längsten bezahlen. Ein System ist wartbar, wenn ein Ingenieur, der es nicht gebaut hat, es schnell verstehen und gefahrlos ändern kann.

In der KI-orchestrierten Entwicklung ist Dokumentation kein nachträglicher Zusatz, sondern ein Nebenprodukt der Methode. Jedes Projekt der Stichprobe wurde zusammen mit den Spezifikationen übergeben, nach denen die KI-Agenten gearbeitet hatten, außerdem mit Protokollen der Architekturentscheidungen, API-Dokumentation und Code, dessen Kommentare die Absicht erklären, nicht die Syntax. Dieselbe Prüfung, die die Ergebnisse der KI auf Fehler untersucht, stellt auch sicher, dass der Code sich selbst erklärt.

Daraus ergeben sich zwei praktische Folgen. Erstens entsteht für den Kunden keine Anbieterbindung: Das Wissen über das System liegt im Repository, nicht in den Köpfen derer, die es gebaut haben. Zweitens kann die Entwicklung von einem Team an ein anderes übergehen – an eigene Ingenieure, einen anderen Dienstleister oder neue Mitarbeiter –, und die Einarbeitung bleibt minimal, weil das neue Team von denselben Spezifikationen und Entscheidungen ausgeht wie das ursprüngliche.