Letzte Woche habe ich auf LinkedIn über KI-Leitplanken geschrieben. Der Kern: Wer KI ohne Prozess, ohne Architekturvorgaben und ohne TDD loslässt und dann über schlechte Ergebnisse klagt, hat nicht KI getestet. Er hat Chaos getestet.

Martin Kreutz hat kommentiert: Die Erwartungshaltung sei viel höher an die Präzision des Ergebnisses als an die Genauigkeit der eingangs gestellten Aufgabe. Und das gebe es auch ohne KI, auch ohne Leitplanken.

Er hat recht. Das ist genau meine These.

Der Entwickler als Puffer

Vor der KI gab es eine praktische Möglichkeit, schlechte Anforderungen zu überleben: den Entwickler. Nicht weil er Gedanken lesen kann. Sondern weil er nachfragen, interpretieren und stillschweigend ergänzen konnte. Wenn das Ticket lückenhaft war, hat er geraten. Manchmal richtig, manchmal falsch. Wenn er falsch lag, hieß es: „Der Entwickler hat das nicht richtig verstanden.“

Das war die Freizeichnung. Das Ticket war schlecht, aber die Schuld landete anderswo.

Die KI macht das nicht. Sie nimmt die Anforderung und setzt sie um. Exakt das, was drinsteht. Nicht mehr, nicht weniger. Wenn etwas fehlt, fehlt es im Output. Wenn etwas unklar ist, trifft sie eine Annahme, ohne das zu markieren.

Das klingt nach einem Defizit. Es ist ein Spiegel.

Wer jetzt sagt, die KI liefere schlechten Code, sollte einmal das Ticket lesen, das sie bekommen hat.

Das zweite Problem ist das ältere

Anforderungen sind die eine Seite. Qualitätsrichtlinien die andere.

Ich arbeite seit über 35 Jahren in der Softwareentwicklung. In dieser Zeit ist ein erheblicher Kanon entstanden, der beschreibt, wie guter Code aussieht. TDD. SOLID-Prinzipien. Clean Code. 100 % Testabdeckung. Mutation Testing. Hexagonale Architektur. Kurze Methoden. Saubere Schnitte zwischen Schichten.

Ich habe diese Listen vor Teams gehängt. Erklärt, verteidigt, eingefordert. Und ich sage offen: vollständig umgesetzt hat das fast niemand. Nicht aus Böswilligkeit. Sondern weil der Projektdruck dagegen stand, die Schulung lückenhaft war, das Budget nicht gestimmt hat.

Das war jahrzehntelang der Normalzustand. Und er hatte ein Sicherheitsventil: Erfahrung. Ein guter Senior-Entwickler wusste, wo er abkürzen darf und wo nicht. Wo die fehlende Testabdeckung harmlos ist und wo sie in drei Monaten als Bug zurückkommt.

Dieses implizite Wissen hat die Lücken gefüllt. Nicht vollständig. Aber genug, um weiterzumachen.

Was sich jetzt verändert hat

Die KI hat dieses implizite Wissen nicht. Sie füllt keine Lücken auf Basis von Erfahrung. Sie macht, was aufgeschrieben ist.

Das ist dieselbe Parallele wie bei den Anforderungen. Wer der KI keine Qualitätsvorgaben gibt, bekommt Code ohne Qualitätsvorgaben. Nicht weil das Modell schlecht ist. Sondern weil die Vorgaben fehlen.

Ich habe das in „Die Rechnung, die niemand bezahlt hat“ beschrieben: die Qualitätsstandards der letzten Jahrzehnte waren realistisch für eine Maschine. Nur nicht für einen Menschen unter Projektdruck. Jetzt ist die Maschine da. Und jetzt zeigt sich, was nie aufgeschrieben wurde.

In „KI produziert nur Scheiße. Stimmt. Ohne Leitplanken.“ habe ich beschrieben, wie TDD und ArchUnit das ändern. Wer Architekturregeln als automatische Tests formuliert, bekommt von der KI keinen Code mehr, der Schichtengrenzen verletzt. Das klingt nach Mehraufwand. Es ist Dokumentation, die sowieso hätte existieren sollen.

Die Schulung ist jetzt ein Dokument

Früher wurden Qualitätsstandards in Workshops erklärt. Im Code Review. Im Gespräch zwischen Senior und Junior. Viel davon war mündlich, kontextabhängig, implizit.

Für die KI gibt es das nicht. Sie hat kein Gespräch, keine Erinnerung an den letzten Code Review, keine Intuition aus zehn Jahren Projekterfahrung. Was sie hat, ist das, was man ihr gibt. Eine CLAUDE.md. Ein Architekturkonzept. Testanforderungen, die explizit formuliert sind.

Die Schulung der KI ist Dokumentation. Wer das nicht macht, sollte sich nicht wundern, wenn die Qualität hinten nicht ankommt. Das ist keine neue Erkenntnis. Gute Teams haben das schon immer gewusst. Die KI macht es nur unausweichlich.

Was das bedeutet

KI erzeugt keinen schlechten Code, weil sie es nicht besser kann. Sie erzeugt schlechten Code, weil die Anforderungen unklar sind oder weil die Qualitätsstandards nicht aufgeschrieben wurden.

Beides ist kein KI-Problem. Es ist ein Organisationsproblem, das jahrelang durch menschliche Kompensation überdeckt wurde.

Diese Kompensation fällt jetzt weg. Was bleibt, ist das, was tatsächlich vorhanden ist: Anforderungen, Richtlinien, Dokumentation. Gut oder schlecht.

Die KI hat das Problem nicht erfunden. Sie hat nur die Möglichkeit genommen, es zu verstecken.