Zwanzig Jahre lang haben wir Qualitätsstandards für Softwareentwicklung aufgebaut. Clean Code. Modulare Architekturen. Test First. 100 % Testabdeckung. Mutation Testing. SOLID-Prinzipien. Domain-Driven Design. Klar geschnittene Komponenten. Methoden, die auf eine Bildschirmseite passen. Dokumentation, die nicht lügt.

Die Liste ist lang. Jeder Senior-Entwickler kennt sie. Jeder hat irgendwann eine Version dieser Liste vor einem Team aufgehängt und erklärt, warum jeder Punkt dort drauf steht.

Und dann hat die Realität zugeschlagen.

Was tatsächlich umgesetzt wurde

Ich behaupte: niemand hat das jemals vollständig umgesetzt. Nicht ich. Nicht meine Kollegen. Nicht die Teams, die ich kenne. Nicht die Unternehmen, die die entsprechenden Bücher in ihren Schulungsregalen hatten.

Nicht, weil die Leute schlecht waren. Sondern weil die Summe dieser Anforderungen schlicht nicht in die Zeit gepasst hat, die zur Verfügung stand. Wer 100 % Testabdeckung will, braucht Zeit für Tests. Wer Mutation Testing ernst nimmt, braucht noch mehr Zeit. Wer saubere Architektur will, muss Entscheidungen vorab treffen, dokumentieren, verteidigen. All das kostet. Und das Budget hat nie gestimmt.

Ich wurde dafür öfter beschimpft, dass ich zu viel verlange. Zu streng sei. Zu viele Richtlinien gebe. Das kenne ich. Wer Qualitätsstandards konsequent einfordert, bekommt irgendwann diesen Vorwurf. Er ist so alt wie die Standards selbst.

Das ändert nichts daran, dass die Standards richtig waren.

Ein kurzer Einschub zu Testabdeckung

Die Kritik an 100 % Testabdeckung ist alt und immer gleich: das sei übertrieben, man solle pragmatisch sein, 80 % reichten doch auch. Ich halte das für eine gefährliche Verwechslung.

Das Ziel ist nicht die Zahl. Das Ziel ist die Aussage dahinter: alles, was nicht getestet ist, kann in Produktion auf die Füße fallen. Jede nicht abgedeckte Zeile ist eine blinde Stelle. Man weiß nicht, ob sie funktioniert. Man weiß nur, dass man es nicht geprüft hat.

80 % Testabdeckung klingt gut. Sie bedeutet konkret: 20 % des Codes laufen in Produktion ohne irgendeinen Nachweis, dass sie das Richtige tun. In einem mittelgroßen System sind das schnell Tausende von Zeilen. Der nächste kritische Bug wohnt genau dort.

Und selbst wer 100 % Abdeckung erreicht, hat noch nichts bewiesen. Hohe Abdeckung kann durch schlechte Tests erkauft sein, die Zeilen durchlaufen, ohne etwas zu prüfen. Genau deshalb ist Mutation Testing keine nette Ergänzung, sondern die eigentliche Qualitätsprüfung der Tests selbst. Ein Mutationstest verändert den Produktionscode minimal, zum Beispiel ein > zu >=, und prüft dann: stirbt mindestens ein Test daran? Wenn nicht, ist der Test wertlos. Er läuft, er besteht, er gibt Sicherheit, die er nicht hat.

Testabdeckung sagt: ich habe den Code berührt. Mutation Testing sagt: meine Tests würden einen Fehler bemerken. Das ist der Unterschied zwischen dem Schein von Qualität und der Substanz dahinter.

Was sich jetzt verschoben hat

Wir sind im KI-Zeitalter. Und damit verändert sich die Rechnung grundlegend.

Eine KI, die Code schreibt, hat keine Deadlines. Sie wird nicht müde. Sie schreibt nicht schnell schlechten Code, weil das Sprint-Ende naht. Sie hat kein „das machen wir später sauber“ in ihrem Vokabular, wenn man sie richtig einsetzt. Sie kann bei jedem Commit dieselben Standards anlegen wie beim ersten.

Das bedeutet: alles, was wir als zu aufwändig abgetan haben, ist jetzt auf dem Tisch.

Gute Architektur? Die KI kann architektonische Muster konsistent durchhalten, wenn man ihr klare Vorgaben gibt. Modulare Komponenten? Sie schneidet keine Methoden auf 300 Zeilen, wenn man das nicht will. 100 % Testabdeckung mit echten Mutation-Tests? Sie schreibt Tests mit, die tatsächlich etwas prüfen, wenn das zur Aufgabe gehört. Kommentare, die stimmen? Sie hat keine Ausrede, es nicht zu tun.

Die Qualitätsstandards der letzten zwanzig Jahre waren keine unrealistischen Träume. Sie waren realistisch für eine Maschine. Nur nicht für einen Menschen unter dem üblichen Projektdruck.

Die Umkehrung der Frage

Bisher war die Frage: wie viel Qualität können wir uns leisten?

Die neue Frage ist: warum liefern wir sie nicht?

Wenn die KI in der Lage ist, sauber geschnittene Komponenten zu bauen, Tests mitzuschreiben, die Fehler tatsächlich finden würden, Architekturen konsistent durchzuhalten und Methoden auf sinnvolle Größen zu beschränken, dann ist das keine Frage der Kapazität mehr. Dann ist es eine Frage der Instruktion. Wer der KI erlaubt, schlechten Code zu schreiben, trifft eine Entscheidung. Wer ihr nicht vorgibt, nach welchen Standards sie arbeiten soll, bekommt Mittelmaß. Das ist keine Überraschung.

Die KI rechtfertigt keine niedrigeren Standards. Sie macht höhere Standards endlich bezahlbar.

Was das praktisch bedeutet

Wer heute mit KI entwickelt und keine Qualitätsvorgaben macht, verschenkt den wichtigsten Teil des Versprechens. Die Geschwindigkeit ist real. Aber Geschwindigkeit bei schlechter Qualität erzeugt technische Schulden schneller als je zuvor.

Der richtige Einsatz sieht anders aus. Klare Architekturvorgaben, die die KI konsistent umsetzt. Testabdeckung als Pflicht, nicht als Option, mit Mutation Testing als Nachweis, dass die Tests auch wirklich etwas taugen. Modulare Struktur als Standard, nicht als Ausnahme. Kurze Methoden, die genau eine Sache tun. Kommentare, die den Grund erklären, nicht den Mechanismus.

Das alles war schon immer der Anspruch. Jetzt gibt es kein gutes Argument mehr dagegen.

Wer zwanzig Jahre lang erklärt hat, warum Qualitätsstandards wichtig sind, und jetzt KI einsetzt ohne diese Standards einzufordern, widerspricht sich selbst. Und wer früher gesagt hat, das sei alles zu viel, hat jetzt eine neue Antwort bekommen.

Die Rechnung war immer da. Jetzt kann sie jemand bezahlen.