Zwischen KI-Euphorie und Quality Engineering: Warum wir gerade Gefahr laufen, Softwarequalität zu verlernen

Ich höre immer häufiger Erfolgsgeschichten, die ungefähr so klingen:
Die KI liest alle Tickets, generiert daraus automatisierte Tests, heilt fehlgeschlagene Tests selbstständig, reviewed den Code, plant die nächsten Aufgaben und am Ende ist alles grün. Entwickler sind entlastet. QA wird nicht mehr benötigt. Alles funktioniert.

Das Publikum applaudiert.
Ich sitze da und frage mich:

• Was kostet dieses System eigentlich?
• Wie viele Millionen Token verbraucht es täglich?
• Wie entwickelt sich das Geschäftsmodell, wenn die Preise für LLMs steigen?
• Welche Strategien existieren zur Token-Optimierung?
• Welche Architekturentscheidungen wurden getroffen?
• Wie resilient ist dieses System?
• Wie nachhaltig ist es?

Darüber spricht kaum jemand.

Agentic Coding ermöglicht heute etwas Beeindruckendes:
Innerhalb weniger Stunden entsteht ein funktionierender Prototyp.

Das ist faszinierend.
Aber genau hier beginnt das Problem.
Ein Prototyp ist kein Produkt.

Viele Demos auf Konferenzen zeigen beeindruckende Workflows. Doch sie beantworten nicht die Fragen, die Software langfristig erfolgreich machen:

• Ist die Lösung wartbar?
• Ist sie skalierbar?
• Ist sie nachvollziehbar?
• Ist sie testbar?
• Ist sie wirtschaftlich?
• Ist sie langfristig betreibbar?

Softwarequalität entsteht nicht dadurch, dass Code schnell erzeugt wird.
Sie entsteht durch tausende kleine Engineering-Entscheidungen.

Besonders kritisch sehe ich die zunehmende Automatisierung von Testgenerierung und Self-Healing.

Auf Folien sieht das großartig aus:
„Die KI erkennt den Fehler und repariert den Test automatisch.“

Meine erste Reaktion lautet:
Woher wissen wir, dass der Test jetzt noch dasselbe überprüft?
Hat der Healer lediglich den Locator angepasst?
Oder wurde stillschweigend die erwartete Fachlichkeit verändert?
Hat sich vielleicht die Assertion geändert?
Wurde aus einem kritischen Test plötzlich ein Test, der immer grün wird?
Wer überprüft das?
Wer visualisiert, welche Anforderungen tatsächlich noch durch Tests abgedeckt werden?
Wer erkennt, wenn sich Test Coverage verschlechtert?
Wer verhindert eine schleichende Erosion der Qualität?

Ein grüner Build bedeutet nicht automatisch ein gutes Produkt.
Er bedeutet zunächst einmal nur:
Alle vorhandenen Tests waren erfolgreich.

Ob diese Tests überhaupt noch die richtigen Dinge prüfen, ist eine völlig andere Frage.

Noch vor wenigen Jahren konnten Entwickler ihren eigenen Code erklären.

Heute höre ich zunehmend Aussagen wie:
„Den Code hat Copilot erzeugt.“
„Das hat Claude geschrieben.“
„Das Refactoring hat der Agent übernommen.“
„Den Bug soll die KI beheben.“
Die Konsequenz?

Der Mensch verliert schrittweise das Verständnis seines eigenen Systems.
Code Reviews werden schwieriger, weil plötzlich tausende Zeilen gleichzeitig entstehen.
Refactorings werden größer.
Komplexität wächst schneller.

Wenn anschließend ein Fehler auftritt, weiß häufig niemand mehr, an welcher Stelle eigentlich begonnen werden sollte zu suchen.

Wir übertragen einer KI immer mehr Verantwortung.
Die Verantwortung gegenüber unseren Kunden behalten jedoch wir.

Eine Architekturentscheidung ist oft unscheinbar.
An einer Stelle biegt man links statt rechts ab.
Die Folgen zeigen sich Monate später.
Dann beginnen umfangreiche Refactorings.

Neue Agenten werden gestartet.
Noch mehr Code entsteht.
Noch mehr Token werden verbraucht.
Noch mehr Komplexität entsteht.
Schnelligkeit ist kein Qualitätsmerkmal.

Sie kann sogar der teuerste Umweg sein.

In den letzten Monaten bekomme ich eine neue Art von Anfragen.

Sie lauten ungefähr so:
„Wir haben ein agentisches Softwaresystem entwickelt. Kannst du uns sagen, an welchen Stellen wir Quality Checks in den Code integrieren müssen?“

Diese Frage zeigt ein grundlegendes Missverständnis.
Qualität entsteht nicht an bestimmten Stellen im Code.
Qualität entsteht nicht durch einige zusätzliche Checks.
Qualität entsteht während des gesamten Software Development Lifecycle.
Von der ersten Idee.
Über Anforderungen.
Architektur.
Design.
Implementierung.
Reviews.
Tests.
Monitoring.
Betrieb.
Kontinuierliche Verbesserung.

Es gibt keinen einzelnen Quality-Schalter.

Noch irritierender werden Gespräche wie diese:
„Habt ihr Anforderungen?“
„Nein.“
„User Stories?“
„Nein.“
„Tickets?“
„Nein.“
„Warum?“
„Das wäre ein Bottleneck.“
„Was verwendet ihr stattdessen?“
„Die KI erzeugt Spezifikationen.“
„Wie validiert ihr diese?“
„…“

Oder:
„QA brauchen wir eigentlich auch nicht mehr.“
„Warum?“
„Die KI generiert schließlich auch die Tests.“

Dann frage ich:
Wogegen testet ihr eigentlich?
Was ist der Sollzustand?
Welche Nutzerprobleme sollen gelöst werden?
Welche kritischen User Journeys existieren?
Welche Risiken müssen minimiert werden?
Welche Qualitätsziele verfolgt ihr?

Darauf folgt häufig Schweigen.

Ein weiteres Muster begegnet mir regelmäßig.
„Wir haben unglaublich viele Testfälle.“
Meine Gegenfrage lautet:
Welche Anforderungen decken sie ab?
„Das wissen wir nicht.“
Wie hoch ist die Test Coverage?
„Keine Ahnung.“
Welche Risiken sind abgesichert?
„Nicht definiert.“
Welche Fehlerklassen werden adressiert?
„Unbekannt.“

Die Anzahl von Testfällen ist keine Qualitätsmetrik.
Genauso wenig wie tausende Zeilen generierter Code ein Qualitätsnachweis sind.

Besonders nachdenklich machen mich Anfragen wie:
„Könnt ihr uns das Wissen aus ISTQB®, IREB® und iSAQB® als Skills generieren, damit unser agentisches System automatisch Qualität erzeugt?“

Ich muss dann häufig schmunzeln.
Nicht weil die Idee schlecht wäre.
Sondern weil sie zeigt, wie Engineering manchmal wahrgenommen wird.
Requirements Engineering.
Software Architecture.
Quality Engineering.
Testing.

Das sind keine Checklisten.
Keine Prompts.
Keine einzelnen Skills.
Es sind Disziplinen, die über Jahrzehnte entstanden sind.
Sie bestehen aus Erfahrung.
Abwägungen.
Konflikten.
Trade-offs.
Kommunikation.
Domänenwissen.
Risikoanalyse.
Kontext.

Es gibt selten die eine richtige Entscheidung.
Es gibt meist viele mögliche Entscheidungen.
Und genau darin liegt Engineering.

Ob klassische Software oder KI-basierte Systeme:
Die grundlegenden Qualitätsprinzipien ändern sich nicht.

Die Qualitätsmerkmale der ISO/IEC 25010 gelten weiterhin.
Wenn KI Bestandteil des Systems ist, kommen zusätzliche Qualitätsaspekte hinzu, beispielsweise hinsichtlich Transparenz, Kontrollierbarkeit, Robustheit oder Interventionsfähigkeit, wie sie in der ISO/IEC 25059 beschrieben werden.

KI ersetzt diese Anforderungen nicht.
Sie erweitert sie.

Ich halte künstliche Intelligenz für eine der größten technologischen Entwicklungen unserer Zeit.

Ich nutze sie täglich.
Sie steigert meine Produktivität.
Sie hilft beim Schreiben.
Beim Recherchieren.
Beim Analysieren.
Beim Strukturieren.
Beim Hinterfragen.
Beim Lernen.

Genau dort liegt ihre Stärke.
Nicht im blinden Ersetzen von Engineering.

Ich wünsche mir eine KI,

• die mein Ergebnis reviewed,
• Verbesserungsvorschläge macht,
• Risiken erkennt,
• Alternativen aufzeigt,
• Inkonsistenzen findet,
• mich auf fehlende Anforderungen aufmerksam macht,
• meine Tests kritisch hinterfragt,
• Coverage visualisiert,
• Architekturentscheidungen transparent macht,
• und mich dabei unterstützt, bessere Entscheidungen zu treffen.

Nicht eine KI, die Entscheidungen für mich trifft, ohne dass ich ihre Auswirkungen verstehe.

Der derzeitige KI-Hype droht, den eigentlichen Kern des Software Engineerings zu überdecken.

Engineering war nie das Schreiben von Code.
Engineering bedeutet, komplexe Probleme unter Unsicherheit verantwortungsvoll zu lösen.

Diese Verantwortung bleibt beim Menschen.
KI ist dabei ein außerordentlich leistungsfähiger Assistent.
Aber sie ist kein Ersatz für kritisches Denken, für Architekturkompetenz, für Requirements Engineering, für Quality Engineering und für professionelles Testen.

Vielleicht sollten wir auf Konferenzen wieder häufiger eine einfache Frage stellen:
Nicht: „Was kann eure KI?“
Sondern:
„Wie entsteht in eurem System nachweisbar Qualität?“

Denn am Ende wird nicht die KI für das Produkt verantwortlich gemacht.
Sondern immer der Mensch, der es entwickelt, freigegeben und ausgeliefert hat.