Zuletzt aktualisiert am: 28. August 2026
Seit Monaten reise ich als Speakerin zu nationalen und internationalen Konferenzen. Kaum eine Keynote, kaum ein Tool und kaum ein Produkt kommt noch ohne den Zusatz „AI-powered”, „Agentic” oder „Autonomous” aus. Künstliche Intelligenz scheint nicht mehr nur ein Werkzeug zu sein, sondern zum Selbstzweck geworden zu sein. Wer heute nicht über KI spricht, gilt schnell als rückständig. Mich beschäftigt dabei jedoch eine andere Frage: Reden wir eigentlich noch über Software Engineering oder nur noch über KI?
Die neue Realität: Plötzlich ist alles „agentisch”.
Ich höre immer häufiger Erfolgsgeschichten, die ungefähr so klingen: Die KI liest alle Tickets, generiert daraus automatisierte Tests, behebt fehlgeschlagene Tests selbstständig, prüft den Code, plant die nächsten Aufgaben und am Ende ist alles grün. Die Entwickler sind entlastet, die Qualitätssicherung wird nicht mehr benötigt und 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 und nachhaltig ist dieses System? Darüber spricht kaum jemand.
Geschwindigkeit ersetzt keine Qualität.
Mit Agentic Coding ist heute etwas Beeindruckendes möglich: Innerhalb weniger Stunden entsteht ein funktionierender Prototyp. Das ist faszinierend. Aber genau hier beginnt das Problem, denn ein Prototyp ist kein Produkt.
Viele Demos auf Konferenzen zeigen beeindruckende Workflows. Doch sie beantworten nicht die Fragen, die eine Software langfristig erfolgreich machen: Ist die Lösung wartbar, skalierbar, nachvollziehbar, testbar, wirtschaftlich und langfristig betreibbar? Softwarequalität entsteht nicht dadurch, dass Code schnell erzeugt wird. Sie entsteht durch tausende kleine Engineering-Entscheidungen.
False Confidence ist die neue technische Schuld.
Ich sehe die zunehmende Automatisierung von Testgenerierung und Self-Healing besonders kritisch. Auf Folien sieht das großartig aus: „Die KI erkennt den Fehler und repariert den Test automatisch.“ Meine erste Reaktion lautet jedoch: „Woher wissen wir, dass der Test jetzt noch dasselbe überprüft?” Hat der Healer lediglich den Locator angepasst oder wurde die erwartete Fachlichkeit stillschweigend 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 die Testabdeckung verschlechtert? Wer verhindert eine schleichende Erosion der Qualität? Ein grüner Build bedeutet nicht automatisch ein gutes Produkt. Zunächst einmal bedeutet er nur, dass alle vorhandenen Tests erfolgreich waren. Ob diese Tests überhaupt noch die richtigen Dinge prüfen, ist eine völlig andere Frage.
Der Code wird zur Black Box
Noch vor wenigen Jahren konnten Entwickler ihren eigenen Code erklären. Heute höre ich jedoch zunehmend Aussagen wie: „Den Code hat Copilot erzeugt.“, „Das hat Claude geschrieben.“, „Das Refactoring hat der Agent übernommen.“ oder „Den Bug soll die KI beheben.“ Die Konsequenz ist, dass der Mensch schrittweise das Verständnis für sein eigenes System verliert. Code-Reviews werden schwieriger, weil plötzlich Tausende Zeilen gleichzeitig entstehen. Refactorings werden größer und die Komplexität wächst schneller. Wenn anschließend ein Fehler auftritt, weiß häufig niemand mehr, an welcher Stelle eigentlich mit der Suche begonnen werden sollte. Wir übertragen einer KI immer mehr Verantwortung. Die Verantwortung gegenüber unseren Kunden tragen jedoch wir.
Architektur entscheidet – lange bevor der erste Test geschrieben wird.
Architekturentscheidungen sind oft unscheinbar. An einer Stelle biegt man links statt rechts ab, und die Folgen zeigen sich erst Monate später. Dann beginnen umfangreiche Refactorings, es werden neue Agenten gestartet, es entsteht noch mehr Code, es werden noch mehr Token verbraucht und es entsteht noch mehr Komplexität. Schnelligkeit ist kein Qualitätsmerkmal. Sie kann sogar der teuerste Umweg sein.
„Wo müssen wir Qualität einbauen?”
In den letzten Monaten erhalte ich eine neue Art von Anfragen. Sie lauten in etwa 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 und auch nicht durch einige zusätzliche Checks. Sie entsteht während des gesamten Software-Entwicklungszyklus: von der ersten Idee über Anforderungen, Architektur, Design, Implementierung, Reviews und Tests bis hin zu Monitoring, Betrieb und kontinuierlicher Verbesserung. Es gibt keinen einzelnen Quality-Schalter.
Noch irritierender sind Gespräche wie dieses:
“Habt ihr Anforderungen?” – “Nein.” “User Stories?” – “Nein.” “Tickets?” – “Nein.” “Warum nicht?” – “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 nicht?” – “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? Oft folgt darauf Schweigen.
Warum sind viele Tests keine Teststrategie?
Ein weiteres Muster, das mir regelmäßig begegnet, lautet: “Wir haben unglaublich viele Testfälle.” Meine Gegenfrage lautet dann: “Welche Anforderungen decken sie ab?” “Das wissen wir nicht.” Wie hoch ist die Testabdeckung? “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.
Warum lässt sich Engineering nicht in einen Prompt komprimieren?
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 und Kontext. Es gibt selten die eine richtige Entscheidung, meist gibt es viele mögliche Entscheidungen. Und genau darin liegt Engineering.
Gelten für KI-Systeme andere Qualitätskriterien als für klassische Software?
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-Komponenten zum System hinzugefügt werden, kommen zusätzliche Qualitätsaspekte wie Transparenz, Kontrollierbarkeit, Robustheit und Interventionsfähigkeit hinzu, wie sie in der ISO/IEC 25059 beschrieben werden. KI ersetzt diese Anforderungen nicht, sondern erweitert sie.
KI sollte uns unterstützen, aber nicht ersetzen.
Ich halte KI für eine der größten technologischen Entwicklungen unserer Zeit. Ich nutze sie täglich, denn sie steigert meine Produktivität und hilft mir beim Schreiben, Recherchieren, Analysieren, Strukturieren, Hinterfragen und Lernen. Genau darin liegt ihre Stärke – nicht im blinden Ersetzen von Engineering.
Ich wünsche mir eine KI, die mein Ergebnis reviewt, 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.
Fazit: Verantwortung für Softwarequalität bleibt beim Menschen
Der derzeitige Hype um KI droht den eigentlichen Kern des Software-Engineerings zu überdecken. Engineering war jedoch 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. Sie ist jedoch kein Ersatz für kritisches Denken, Architekturkompetenz, Requirements Engineering, Quality Engineering und 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 der Mensch, der sie entwickelt, freigegeben und ausgeliefert hat.
Beschäftigen Sie sich auch mit Quality Engineering im Zeitalter agentischer Systeme? Lilia Gargouri freut sich auf den Austausch mit Ihnen.
