AI Code-Tsunami trifft auf QA-Staumauer: Das Ende der eingependelten Geschwindigkeit

Vorab: Dieser Artikel richtet sich gezielt an Teams, die an der Modernisierung und Weiterentwicklung von bestehenden Systemen arbeiten und nicht an Projekte auf der sprichwörtlichen grünen Wiese, wo völlig andere Gesetze gelten.

Jeder spricht über den massiven Produktivitäts-Boost durch Künstliche Intelligenz in der Softwareentwicklung. Tools wie GitHub Copilot und andere AI-Assistenten versprechen, dass wir Features in einem Bruchteil der bisherigen Zeit implementieren können. Und tatsächlich ist die Generierung von Code rasant geworden.

Doch werfen wir einen Blick in die Realität bestehender Softwareprojekte und eingespielter Teams, zeigt sich oft ein anderes Bild. Die Entwickler sind zwar schneller, aber der Business Value kommt beim Endkunden nicht zügiger an. Woran liegt das? Wir erliegen einer AI-Speed-Illusion. Wir haben vergessen, dass Code schreiben nur ein Teil der Gleichung ist.

Natürlich hat die Softwareentwicklung unzählige Variablen. Für die Liefergeschwindigkeit sind jedoch im Kern vier Sektoren entscheidend: Anforderungen, Development, Qualitätssicherung (QA) und Auslieferung. Ein isolierter Speed-Boost in nur einem dieser Bereiche macht das Gesamtsystem nicht schneller.

Oft staut es sich bereits ganz vorne, wenn geklärte Vorgaben nur als kleines Rinnsal in die Entwicklung tröpfeln. Doch selbst wenn die Anforderungen fließen und die AI daraus in Rekordzeit einen Code-Tsunami erzeugt, wartet vor der Auslieferung das nächste Nadelöhr. Auf genau diesen Teil der Gleichung wollen wir uns hier fokussieren: die QA.

Das Jahrzehnt des Gleichgewichts

Um das Problem zu verstehen, müssen wir uns ansehen, wie bestehende Teams abseits der grünen Wiese arbeiten. Viele dieser Projekte funktionieren seit Jahren oder gar Jahrzehnten gut. Über die Zeit hat sich in diesen Teams ein natürliches Gleichgewicht etabliert: eine eingependelte Geschwindigkeit über alle vier Sektoren hinweg – von der Anforderung bis zur Auslieferung.

Entwickler schrieben Code in einem bestimmten Tempo. Die Test-Infrastruktur sowie die oft manuellen Instanzen der QA waren exakt darauf ausgerichtet, diesen Output zeitnah zu validieren. Es war ein Rhythmus, der funktionierte. Development-Speed und die Abnahme durch die QA befanden sich in einer perfekten Balance.

Der Tsunami und die Staumauer

Und dann kam die AI.

Innerhalb kürzester Zeit hat sich die Geschwindigkeit, mit der Code produziert wird, vervielfacht. (Wie extrem diese Geschwindigkeit auf der grünen Wiese aussehen kann, zeigt unser Experiment: Ein kompletter PoC in 5 Minuten mit AI-Assisted Coding). Das historische Gleichgewicht wurde förmlich weggespült. Die Entwicklung erzeugt nun einen regelrechten Code-Tsunami.

Das Problem bei bestehenden Teams ist, dass die Prozesse, die Test-Infrastruktur und die Menschen in der Abnahme geblieben sind, wie sie waren. Der Tsunami trifft ungebremst auf die bestehende QA-Staumauer. Wenn Test-Runs für ein Feature Stunden dauern oder es weiterhin manuelle Instanzen in Form von QA-Testern gibt, staut sich der Code. Die Features sind zwar Code Complete, aber nicht in Produktion. Der tatsächliche Mehrwert für das Business steigt nicht. Er verharrt im Flaschenhals der Abnahme.

Wichtig zu verstehen: Das ist kein Versagen der QA! Es ist schlichtweg ein System, das für eine völlig andere Geschwindigkeit und für Projektsituationen der Vergangenheit optimiert wurde.

Der Bumerang-Effekt: Warum AI-Code ohne schnelles Feedback zu Instant Legacy Code wird

Dieser Stau vor der QA hat nicht nur Folgen für die Time-to-Market, er schlägt auch unweigerlich auf das Entwicklerteam zurück. Denn irgendwann wird der Code getestet. Wenn dann Fehler gefunden werden, wandert das Ticket zurück zum Entwickler. Das Problem dabei ist, dass dieses Feedback durch den Flaschenhals oft erst Stunden oder Tage später kommt.

Nun könnte man sagen: „Kontextwechsel und Warten auf die QA waren schon immer anstrengend und teuer.“ Das stimmt. Aber wenn ein Bug in von AI generiertem Code gefixed werden muss, kommt eine neue, gefährliche Dimension hinzu: die fehlende mentale Verankerung.

Wenn ein Entwickler ein komplexes Feature komplett selbst tippt, baut er Zeile für Zeile ein tiefes mentales Modell der Logik auf. Fällt dieser Code drei Tage später in der manuellen QA auf, erinnert er sich an seine Gedankengänge. Wenn wir Code jedoch mit Hilfe der AI bauen, wechseln wir oft in die Rolle des Reviewers. Wir akzeptieren Blöcke von Code. Das mentale Modell, das wir dabei aufbauen, ist wesentlich flacher.

Dauert ein Testlauf nun Stunden oder das Feedback der QA Tage und wir müssen einen subtilen Bug fixen, beginnt ein mühsames Reverse-Engineering von Code, den wir streng genommen nie wirklich selbst geschrieben haben. Die kognitive Last ist enorm. Ohne sofortiges Feedback erschaffen wir gewissermaßen Instant Legacy Code – Code, der gerade erst generiert wurde, den aber schon jetzt niemand im Team mehr im Detail versteht. Wir erleben hier Software-Entropie auf Steroiden: Das schleichende Verrotten der Code-Basis und der Aufbau von Komplexität, was früher Monate dauerte, passiert durch AI-generierten Code plötzlich in wenigen Wochen. Schnelles und automatisiertes Feedback in Minuten ist daher der einzige Weg, Fehler zu fangen, solange dieser flache AI-Kontext im Kopf des Entwicklers noch frisch ist.

Die Testpyramide ist wichtiger denn je: Wann ist eine Test-Suite bereit für AI?

Um wirklich AI Powered Development in Bestandsprojekten betreiben zu können, gibt es nur einen Ausweg. Wir müssen die Testpyramide nicht neu erfinden, aber wir müssen sie ernster nehmen als je zuvor. Die klassische Testpyramide war nie weg, aber im Zeitalter der AI rückt sie vom wichtigen Architekturkonzept zur absoluten Überlebensstrategie auf.

Nur wer ohne Bottleneck arbeiten kann, wird die PS der AI auch auf die Straße bringen. Aber was bedeutet das konkret? Eine Test-Suite ist erst dann wirklich tauglich für AI, wenn sie folgende Kriterien erfüllt:

• Rasante Basis: Unit- und Komponententests laufen in unter 5 Minuten durch. Sie sind der erste und wichtigste Filter für von AI generierten Code.
• Schneller Feature-Zyklus: Das Feedback auf Ebene der Features kommt spätestens innerhalb eines Entwicklerfensters von unter 30 Minuten.
• Trustful Test-Suite: Es reicht nicht, dass der Code kompiliert. Entwickler müssen blind vertrauen können. Ein grüner Testlauf bedeutet, das gesamte Feature und die Applikation funktionieren fehlerfrei. Ohne dieses Vertrauen fordert man als Sicherheitsnetz bei jedem Schritt wieder manuelle Re-tests an.
• Lesbare Fehlermeldungen: Fehlermeldungen und Log Messages müssen so eindeutig wie möglich sein und konkrete Hinweise auf den Fehler geben. Ein generisches „End-to-End-Test rot, viel Glück“ hilft weder dem Entwickler noch der AI. Nur wenn die Logs präzise sind, kann die AI beim automatisierten Debuggen echten Mehrwert liefern.

AI schreibt unsere Tests? Ein Realitätscheck und das TDD-Comeback

Nun könnte man argumentieren: "Dann lassen wir die AI eben auch die Tests schreiben!"

Die Testgenerierung ist zweifellos viel besser geworden. Doch die Praxis in gewachsenen Systemen zeigt, dass die AI umso mehr an ihre Grenzen stößt, je integrativer und komplexer die Abhängigkeiten werden. (Wer genauer wissen will, wo die aktuellen Grenzen der AI-Assistenten im echten Entwickleralltag liegen, dem empfehle ich unseren Artikel Bugs, Refactoring, Tests: Wo Chatbots beim Coden glänzen und wo sie scheitern).

Hier offenbart sich ein überraschendes Phänomen: Die Rückkehr zu Test-Driven Development (TDD), allerdings im neuen Gewand der AI. Es ist wesentlich effektiver, vorab gut durchdachte und scharfe Tests zu definieren. Diese Tests geben der AI exakt die Leitplanken, den Business-Kontext und die Edge-Cases vor. Die AI erzeugt aus vorab geschriebenen, starken Tests einen wesentlich besseren Produktivcode, als wenn man sie bittet, für ihren eigenen Produktivcode nachträglich Tests zu erfinden. Die Tests werden zum mächtigsten Prompt, den ein Entwickler haben kann.

Wie gut dieses Prinzip in der Praxis funktioniert und wie man die AI dazu zwingt, sauberen Code gegen harte Testvorgaben zu schreiben, zeigt der hervorragende codecentric Blogbeitrag Kein Schummeln erlaubt: Isolierte Specification Tests mit Claude Code.

Tests als lebendiges Gedächtnis und unverzichtbares Fangnetz

Ein weiterer entscheidender und oft übersehener Punkt ist, dass Tests nicht nur reine Qualitätssicherung sind. Sie fungieren als externer Speicher für Kontext, den die AI sonst verschluckt oder schlicht nicht kennt.

Hier zeigt sich auch, warum Regressionstests in der AI-Ära so extrem wichtig sind. Wenn die AI in Zukunft bestehenden Code refactort oder neue Features in ein gewachsenes System integriert, sind umfassende Regressionstests das einzige Fangnetz, das sicherstellt, dass historische, mühsam erarbeitete Funktionen nicht unbemerkt kaputtgehen. Wenn Absprachen oder komplexe Edge-Cases in Acceptance- oder Unit-Tests manifestiert sind, hat die AI auch in Zukunft viel einfacheren Zugriff darauf als auf textuelle Beschreibungen von Edge-Cases, die in irgendeinem Confluence-Wiki verstauben.

Eine große Basis an Test-Code ist also absolut kein Ballast. Sie ist das Langzeitgedächtnis des Systems, eine lebendige und maschinenlesbare Dokumentation sowie ein massiver Kickdown für zukünftiges AI-Development.

Fazit: Kein Erfolg mit AI ohne Test-Exzellenz

"KI in alte Prozesse zu stecken erzeugt nur schneller Stau — das erleben wir bei Kunden jeden Tag. Der eigentliche Hebel liegt nicht in der Code-Generierung, sondern in der Frage, ob die gesamte Delivery-Pipeline mithalten kann. Wer seine Testpyramide und CI/CD nicht auf AI-Geschwindigkeit bringt, verlagert das Problem nur vom Entwickler in die QA. Die Investition in Test-Exzellenz ist keine Kür mehr, sie ist die Eintrittskarte für AI-native Entwicklung." – Kai Lichtenberg, Geschäftsbereichsleiter bei codecentric

Wir befinden uns in einer Zeit des Umbruchs. Wer in der Software-Modernisierung von AI profitieren will, darf nicht nur auf die Generierung von Code schauen.

Die Investition in Tools für AI-Development zahlt sich am Ende des Tages nur dann wirklich aus, wenn parallel dazu auch in die Test-Infrastruktur, die CI/CD-Pipelines und die Laufzeiten der Test-Suites investiert wird. Wer seine Testpyramide vernachlässigt, wird nicht schneller. Man verlagert das Problem lediglich und produziert einen Stau vor der Öffnung der QA Staumauer.

Es war noch nie so wichtig wie heute, eine exzellente und schnelle Test-Suite zu haben. Sie ist das Fundament, auf dem die Geschwindigkeit der AI überhaupt erst stattfinden kann.

---

Leseempfehlung zum Weiterdenken: Wenn die AI uns das Schreiben des Codes abnimmt und wir uns stärker auf Architektur, Tests und Qualitätssicherung fokussieren müssen – was bedeutet das für unsere Jobs? Mehr dazu in unserem Beitrag: Ersetzt KI die Softwareentwickler?