Agentische KI braucht mehr Tester, nicht weniger

Agentische KI verändert grundlegend, wie Software ausgeliefert wird. Assistenten entwerfen Pull Requests, Agenten stoßen Migrationen an, und Review-Bots erklären eine Änderung für sicher, noch bevor ein Mensch seinen Kaffee ausgetrunken hat. Die Branche stellt dies oft als Weg zu weniger Fachkräften im Qualitätsbereich dar. Das ist ein Denkfehler. Wenn Maschinen einen größeren Teil der Codebasis verfassen, ist nicht das Generieren die knappe Ressource. Es ist die unabhängige Überprüfung.

Die Entwicklerumfrage 2025 von Stack Overflow ergab, dass 84 % der Befragten KI-Tools in der Entwicklung einsetzen oder deren Einsatz planen und 51 % der professionellen Entwickler sie täglich nutzen. Die positive Einstellung sank auf 60 %, und mehr Entwickler misstrauen der Genauigkeit von KI ausdrücklich (46 %), als ihr vertrauen (33 %). Die am häufigsten genannte Frustration, auf die 66 % hinwiesen, waren Lösungen, die fast, aber eben nicht ganz richtig sind. Die DORA-Studie 2025 von Google Cloud berichtete, dass 90 % der Fachleute in der Softwareentwicklung KI nutzen und mehr als 80 % angaben, KI habe ihre Produktivität verbessert. Nur 24 % berichteten jedoch von großem oder sehr großem Vertrauen. Wenn KI nützlich ist, ohne dass man ihr vertraut, erweitert das genau die Arbeit von Testern – es verringert sie nicht.

Geschwindigkeit ist kein Beweis

Ich arbeite als Software-Qualitätsingenieur mit Schwerpunkt auf agentischen Tests und CI-Gates für von KI verfassten Code. Intern haben wir einen PR-Prüfer und einen Generator für Testfälle eingeführt. Beide erstellen lediglich Entwürfe. Keines der beiden Tools bewertet seine eigene Arbeit. Diese Regel ist wichtig, weil Agenten mit großer Gewissheit sprechen. Gewissheit ist nicht gleich Korrektheit.

Das haben wir auf die harte Tour gelernt. In einem Pilotprojekt mit einem KI-gestützten PR-Prüfer durchlief eine Änderung CI in weniger als 4 Minuten. Zwei Tage später zeigte ein nachgelagertes Dashboard unmögliche Temperaturen an. Auf einem Codepfad, den die Testsuite nie ausführte, war die Umrechnung zwischen Celsius und Fahrenheit vertauscht. Die Pipeline war grün. Das Produkt war falsch. Eine grüne CI-Pipeline, die nie die schwierige Frage gestellt hat, ist bloß Theater.

Dieser Vorfall ist Teil eines größeren Musters. Der Bericht zum Stand der KI- gegenüber der menschlichen Codegenerierung von CodeRabbit analysierte 470 Open-Source-Pull-Requests auf GitHub (320 mit gemeinsam von KI und Menschen verfasstem Code, 150 ausschließlich von Menschen verfasst). Bei Änderungen, die von KI verfasst wurden, traten insgesamt etwa 1,7-mal so viele Probleme auf; Logik- und Korrektheitsprobleme waren 75 % häufiger, und Sicherheitslücken wurden bis zu 2,74-mal häufiger festgestellt. Der Bericht 2026 zur Codesicherheit generativer KI von Veracode prüfte Modelle anhand von Sicherheitsaufgaben und ermittelte eine durchschnittliche Erfolgsquote bei Sicherheitsprüfungen von 56 %. Gegenüber den 55 % im vorherigen Bericht war das kaum eine Veränderung. Zugleich führte ungefähr jede KI-Codegenerierungsaufgabe zu 44 % eine bekannte Sicherheitslücke ein. Die Syntax ist nahezu gelöst. Sicheres, korrektes Verhalten ist es nicht. Tester sind diejenigen, die sich weigern, beides zu verwechseln.

Halluzinierte Abhängigkeiten sind ein Testproblem

Bei der Codegenerierung werden auch Abhängigkeiten erfunden. Die Studie Wir haben ein Paket für Sie! aus dem Bereich USENIX Security 2025 untersuchte halluzinierte Pakete in 16 codegenerierenden großen Sprachmodellen anhand von 576.000 Beispielen. Kommerzielle Modelle halluzinierten durchschnittlich in mindestens 5,2 % der Fälle Pakete; bei Open-Source-Modellen lag der Durchschnitt bei 21,7 %, wobei 205.474 unterschiedliche halluzinierte Namen entstanden. Dauerhaft verfügbare Phantom-Pakete bieten ein leichtes Ziel für Slop-Squatting: Angreifer registrieren den erfundenen Namen und warten darauf, dass ein Entwickler oder Agent das Paket installiert.

Prüfungen zur Herkunft von Abhängigkeiten gehören in dieselbe Kategorie wie Funktionstests. Wenn ein Agent ein NuGet- oder npm-Paket erfindet, muss der Merge scheitern, bevor überhaupt jemand darüber diskutiert, ob die Unit-Tests gründlich genug waren. Die Herkunft zu prüfen, ist keine optionale Hygienemaßnahme. Es ist ein Qualitätsgate für Änderungen, die von KI verfasst wurden.

Gates, die mit der Zahl der Agenten skalieren

Als wir mit KI-gestützter Automatisierung in etwa zwei Wochen unternehmensweit von .NET 8 auf .NET 10 aktualisierten, war ich für die Qualitäts-Gates verantwortlich. Die Geschwindigkeit war real. Genauso real war der Bedarf an Prüfungen, die der Zusammenfassung des Agenten nicht einfach Glauben schenken. Bei geändertem Code setze ich folgende Gates ein:

• Mutationsscore-Ziele im Bereich von 60 % bis 70 % für geänderte Logik, damit die Testsuite echte Mutanten erkennen muss, statt lediglich Codezeilen abzudecken
• Eigenschaftsbasierte Tests für Logik mit hohem Risiko, bei der Beispiele allein das Verhalten nicht ausreichend spezifizieren
• Prüfungen der Abhängigkeitsherkunft, um Slop-Squatting und halluzinierte Pakete abzuwehren
• Signale für Duplikate und häufige Änderungen, die das Hin und Her durch Copy-and-paste von Agenten aufdecken
• Unabhängige Überprüfung von Behauptungen des Agenten wie „Migration abgeschlossen“, denn eine Behauptung bleibt eine Hypothese, bis Belege vorliegen

Der Mutationsscore ist keine Eitelkeitskennzahl. Er zeigt, ob Ihre Tests einen absichtlich eingebauten Fehler bemerken. Die Testabdeckung kann steigen, während die Testsuite den Celsius-Codepfad weiterhin übersieht. Eigenschaftsbasierte Prüfungen zwingen das Systemmodell dazu, über ganze Wertebereiche hinweg zu bestehen und nicht nur auf einem einzigen idealen Pfad. Die Herkunftsprüfung schließt die Paketspeisekammer. Häufige Änderungen und Duplikate decken die Angewohnheit von Agenten auf, dieselbe Idee auf drei verschiedene Arten neu zu schreiben. Zusammen ergeben sie eine Haltung: Gehen Sie davon aus, dass der Agent falsch liegt, bis die Testsuite das Gegenteil beweist. Bei Code-Reviews halte ich an dieser Kalibrierung fest.

Nichts davon ersetzt API-Tests, Authentifizierungstests, Smoke-Tests oder UI-Automatisierung. FlaUI und PowerShell finden weiterhin Fehler, die APIs übersehen. Auch die Paketierung mit NuGet, MSI und MSM muss durch Installationsprüfungen und Tests des unbeaufsichtigten Installationspfads validiert werden. Agentische Arbeitsabläufe erhöhen das Volumen. Sie machen diese Disziplinen nicht überflüssig.

Mehr Tester, andere Aufgaben

Die Sorge ist, dass Agenten Tests schreiben und Menschen dadurch überflüssig werden. Agenten können Testfälle entwerfen. Sie sollten ihre eigenen Entwürfe jedoch nicht zertifizieren. Befragte auf Stack Overflow, die künftig KI für Tests einsetzen wollen, sehen das Misstrauen der Menschen weiterhin als zentral an: Wenn sie eine andere Person um Hilfe bitten würden, war der häufigste Grund, dass sie den Antworten der KI nicht vertrauten. Dieser Instinkt ist eine Stärke des Berufsstands.

Es ist wichtig, Menschen einzustellen und zu fördern, die auf nichttraditionellen Wegen hierhergekommen sind. Nach einer Laufbahn im HR-Operations- und Datenbereich wechselte ich in die Qualitätssicherung, schloss im Mai 2024 an der UMBC einen Master of Science in Informationssystemen ab und arbeite heute daran, Prüfschranken für agentische KI praxistauglich zu machen. Agentische KI wird nicht auf Menschen mit einem einzigen bestimmten Bildungs- und Berufsweg warten. Sie braucht mehr Menschen, die Nachweise konzipieren können, nicht weniger Menschen, die grüne Builds einfach durchwinken.

Die Produktfrage ist einfach. Wenn Agenten schneller ausgeliefert werden, als Ihre Verifikation mitdenken kann, ist das kein Produktivitätsgewinn. Es ist ein aufgeschobener Vorfall. Investieren Sie in Tester, die jede Behauptung eines Agenten mit Skepsis betrachten, Mutation und Provenienz in die CI integrieren und dort unabhängiges Urteilsvermögen bewahren, wo das Modell am souveränsten formuliert und am wenigsten zuverlässig ist. Agentische KI braucht mehr Tester, nicht weniger.