In Software-Entwicklungsteams verbreitet sich eine stille Annahme: KI-Tools sind mittlerweile so leistungsfähig, dass Testen weniger wichtig wird. Copilot schreibt den Code, die KI generiert die Tests, die Pipeline läuft grün – was soll da noch schiefgehen?
Einiges, wie sich zeigt.
KI-gestützte Entwicklung ist ein echter Produktivitätssprung. Aber sie eliminiert das Qualitätsrisiko nicht. Sie verlagert es – in neue Bereiche, neue Formen, und oft genug völlig aus dem Sichtfeld. Zu verstehen, wohin das Risiko wandert, ist der Ausgangspunkt für die Erkenntnis: Unabhängiges Testen war noch nie wichtiger als heute.
Die Qualitäts-Echokammer
Wenn eine KI sowohl Produktivcode als auch die zugehörigen Tests generiert, entsteht ein strukturelles Problem: Das System validiert seine eigene Logik gegen sich selbst. Tests werden grün – aber sie testen möglicherweise nicht die richtigen Dinge.
In der traditionellen Softwareentwicklung gibt es eine natürliche Qualitätssicherung: Die Person, die Tests schreibt, ist in der Regel nicht dieselbe, die den Code geschrieben hat. Das erzeugt Reibung – und Reibung findet Fehler. In einer vollständig KI-gesteuerten Pipeline bricht diese Trennung vollständig zusammen.
Das ist kein hypothetisches Szenario. Forschungen von Qodo zeigen, dass fehlender Kontext das am häufigsten genannte Qualitätsproblem bei KI-generiertem Code ist – von 65% der Entwickler sowohl bei der Testgenerierung als auch bei Code-Reviews genannt [1]. Das Problem liegt nicht darin, dass KI-Code offensichtliche Prüfungen nicht besteht. Das Problem ist, dass die Lücken zwischen dem, was beabsichtigt war, und dem, was gebaut wurde, für das System, das es gebaut hat, unsichtbar werden.
Ein externes Testteam hat keine gemeinsame Geschichte mit der Codebasis. Keine Verankerung in den Annahmen der KI. Keinen Interessenkonflikt zwischen Liefergeschwindigkeit und Qualität. Das ist keine Einschränkung – das ist der Kern des Mehrwerts.
Der Code, der richtig aussieht – aber es nicht ist
KI-generierter Code hat ein charakteristisches Fehlerprofil, das traditionelle Review-Prozesse weniger effektiv macht. Der Code ist syntaktisch sauber, gut formatiert und besteht oft grundlegende automatisierte Prüfungen. Die Probleme entstehen auf semantischer Ebene: falsche Geschäftslogik, fehlende Sicherheitskontrollen, subtile Grenzfälle, die im Prompt nicht spezifiziert wurden und die die KI nicht antizipiert hat.
Die Cloud Security Alliance beschreibt das Problem treffend: Die gefährlichsten KI-generierten Fehler sehen gar nicht aus wie Fehler. Sie entstehen in den Lücken zwischen Logik, Geschäftskontext und Grenzfällen – und sind schwerer zu erkennen, weil der Code korrekt aussieht [2].
Der Veracode GenAI Code Security Report 2025 liefert ein konkretes Beispiel: KI generiert routinemäßig API-Endpunkte ohne Eingabevalidierung – nicht weil der Code „falsch“ ist im offensichtlichen Sinne, sondern weil der Prompt sie nicht explizit angefordert hat [3]. Das Fehlen von Sicherheitskontrollen ist kein Syntaxfehler. Es löst keinen Linter aus. Es erfordert einen Tester, der weiß, was das System tun soll – nicht nur, was es aktuell tut. Veracodes Analyse von über 100 Sprachmodellen bei 80 realen Coding-Aufgaben ergab: 45% aller generierten Code-Samples enthielten OWASP Top-10-Sicherheitslücken – und diese Rate ist trotz besserer Modelle vollständig konstant geblieben.
Die Daten zum Umfang sind eindeutig: CodeRabbits Analyse von 470 realen GitHub Pull Requests zeigt, dass KI-generierter Code rund 1,7-mal mehr Fehler enthält als von Menschen geschriebener Code [4]. Nicht nur mehr Fehler – auch schwerwiegendere. Kritische Defekte treten 1,4-mal häufiger auf. Logik- und Korrektheitsprobleme sind 75% häufiger. Performance-Defekte treten nahezu 8-mal so häufig auf.
Organisationen, die KI-generierten Code in hohem Tempo einsetzen – ohne angepasste Testprozesse – erhöhen systematisch ihre Produktionsfehlerrate. Das bemerken sie in der Regel erst dann, wenn die Kosten des Scheiterns bereits hoch sind.
Die Schulden, die sich unbemerkt ansammeln
Es gibt ein drittes Risiko, das weniger sichtbar ist als die anderen und langfristig möglicherweise das folgenreichste.
KI produziert Code schneller, als Teams das Verständnis aufbauen können, das benötigt wird, um ihn sicher zu ändern, zu testen oder zu debuggen. Forschende haben diese Dynamik benannt: Kognitive Schulden beschreiben die Erosion gemeinsamer mentaler Modelle in einem Team; Intent Debt bezeichnet das Fehlen dokumentierter Begründungen und Rahmenbedingungen. Ein im März 2026 veröffentlichter Artikel von Margaret-Anne Storey an der University of Victoria bringt es auf den Punkt: Generative KI entfernt nicht die Herausforderungen der Softwareentwicklung – sie verlagert sie [5].
Technische Schulden – die Art, die sich in Code-Qualitätsmetriken zeigt – können mit KI-Unterstützung sogar sinken. Aber die Schulden, die sich in den Köpfen der Menschen ansammeln, und in der fehlenden Dokumentation darüber, warum Entscheidungen getroffen wurden, wachsen still und kontinuierlich. Teams merken oft erst dann, wie viel Verständnis sie verloren haben, wenn etwas unerwartet bricht. Verwandte Forschungen von Shaw und Nave (2026) beschreiben dieses Phänomen als „Cognitive Surrender“ – die unkritische Übernahme von KI-Outputs, die das Vertrauen aufbläst, auch wenn die KI falsch liegt, und Fehler unsichtbar macht, bis sie in der Produktion auftauchen [6].
Für einen externen Testpartner hat diese Dynamik eine wichtige Konsequenz: Ein externes Team akkumuliert keine kognitiven Schulden über eine Codebasis. Jeder Einsatz beginnt mit einer unabhängigen, unverankerten Perspektive. In einer Welt, in der das interne Verständnis kontinuierlich erodiert, wird das zu einem strukturell dauerhaften Vorteil – nicht nur zu einer projektbezogenen Bequemlichkeit.
Die Regulierung holt auf
Für Organisationen in regulierten Branchen gibt es jetzt eine vierte, formal verbindliche Dimension.
Der EU AI Act tritt am 2. August 2026 vollständig in Kraft [7]. Für Hochrisikosysteme – zu denen kritische Infrastruktur, Finanzdienstleistungen, Gesundheitswesen, Bildung und Beschäftigung gehören – schreibt er nachweisbare, dokumentierte, unabhängige Qualitätssicherung vor. Nicht nur Qualität. Belegbare Qualität, mit einem Prüfpfad, durchgeführt von einer Partei, die glaubhaft Unabhängigkeit vom Entwicklungsprozess beanspruchen kann. Strafen von bis zu 35 Millionen Euro oder 7% des globalen Jahresumsatzes.
Interne Teams sind strukturell schlecht positioniert, um dies zu erbringen. Die Regulierung schafft nicht nur Compliance-Overhead – sie schafft eine formale Anforderung für genau die Art von externem, neutralem Testen, die schon immer den Kern unabhängiger Qualitätssicherung ausgemacht hat.
Für Organisationen im Geltungsbereich ist das kein optionales Qualitätsmerkmal mehr. Für andere ist es ein frühes Signal: Die Entwicklung der Software-Regulierung bewegt sich klar in Richtung dokumentierter, prüffähiger Qualitätsprozesse.
Was das in der Praxis bedeutet
Die Entwicklerinnen und Entwickler selbst wissen, dass etwas nicht stimmt. Der Stack Overflow Developer Survey 2025, der knapp 50.000 Entwickler in 177 Ländern befragte, ergab: 46% misstrauen der Genauigkeit von KI-Tools [8]. Nur 3% berichten von hohem Vertrauen in KI-generierte Ausgaben. Und dennoch shippen dieselben Entwickler KI-generierten Code in noch nie dagewesenen Mengen – weil die Review-Kapazität nicht mit der Generierungsgeschwindigkeit Schritt hält. Der DORA State of AI-Assisted Software Development Report (2025) ergänzt eine weitere Dimension: KI-Adoption hat mittlerweile eine messbar negative Beziehung zur Stabilität der Software-Auslieferung, und Organisationen mit fragmentierten Qualitätsprozessen erleben, wie KI ihre technischen Schulden beschleunigt statt abbaut.9
Das ist das klassische Muster, das professionelle Dienstleistungsnachfrage erzeugt: ein erkanntes Problem, das intern nicht lösbar ist. Der Engpass liegt nicht im Bewusstsein. Er liegt in der Kapazität und der Unabhängigkeit.
Das Testen von KI-generierter Software erfordert mehr als das Anwenden bestehender Test-Frameworks auf eine neue Art von Code. Es erfordert das Verständnis des spezifischen Fehlerprofils von KI-generiertem Code – wo sich die Risiken konzentrieren, wie sich semantische Defekte von traditionellen unterscheiden, und wie bewertet wird, ob ein System das tut, was Nutzer und das Unternehmen tatsächlich brauchen – nicht nur das, was die KI aus dem Prompt interpretiert hat.
Die entscheidende Positionierung
Es gibt eine einfache Art, das Geschehende zu beschreiben: Je mehr Entwicklung automatisiert wird, desto mehr wird Testen zur letzten verlässlichen Qualitätskontrollinstanz. Es ist die einzige systematische Prüfung, ob Code tatsächlich das tut, was er tun soll.
Das ist keine pessimistische Sicht auf KI, sondern eine realistische. KI-gestützte Entwicklung ist ein echter Produktivitätsdurchbruch – und wie jeder Produktivitätsdurchbruch in der Softwaregeschichte erhöht er die Bedeutung der Qualitätsprozesse, die ihn begleiten.
Unabhängige Testpartner – ohne Interessenkonflikt, ohne angesammelte blinde Flecken, mit glaubwürdiger Neutralität für Compliance-Zwecke – sind strukturell positioniert, um die Lücke zu füllen, die KI-Entwicklung schafft.
Die Frage „KI schreibt den Code – wer testet ihn?“ hat eine klare Antwort. Es sollte nicht dasselbe System sein, das ihn geschrieben hat.
Über den Autor
Florian Fieber verantwortet als Chief Process Officer bei der TestSolutions GmbH das Testprozessmanagement der gesamten Organisation sowie den Schulungsbereich mit der TestSolutions Academy. Er ist seit fast 20 Jahren im Bereich der Qualitätssicherung von Softwaresystemen tätig und hat in dieser Zeit mehrere Trainings- und Beratungsunternehmen (mit-)gegründet. Seine Schwerpunkte als Berater und Trainer liegen in den Bereichen Testmanagement, Testprozessmanagement und Testprozessverbesserung.
Nach seinem Studium der Medieninformatik und Wirtschaftsinformatik arbeitete er zunächst als Softwareentwickler für Unternehmensanwendungen und als wissenschaftlicher Mitarbeiter an der Technischen Fachhochschule Berlin. Seitdem hat sich sein Schwerpunkt von der Testanalyse und Testautomatisierung über das Testmanagement bis hin zur Prozessverbesserung entwickelt und umfasst heute alle Aspekte der Qualitätssicherung über den gesamten Software-Lebenszyklus.
Seit 2018 ist er Mitglied des German Testing Board (GTB) und engagiert sich für die Weiterentwicklung des ISTQB Certified Tester Schemas. Von 2020 bis 2022 war er stellvertretender Vorsitzender und seit 2022 ist er Vorsitzender des GTB.
Quellen
[1] Qodo, State of AI Code Quality (2025) – qodo.ai/reports/state-of-ai-code-quality ↩
[2] Cloud Security Alliance, Understanding Security Risks in AI-Generated Code (Juli 2025) – cloudsecurityalliance.org ↩
[3] Veracode, GenAI Code Security Report 2025 – veracode.com ↩
[4] CodeRabbit, State of AI vs Human Code Generation (Dezember 2025) – coderabbit.ai ↩
[5] Storey, M-A., From Technical Debt to Cognitive and Intent Debt (März 2026) – arxiv.org/abs/2603.22106 ↩
[6] Shaw & Nave, Thinking Fast, Slow, and Artificial (2026) – ssrn.com/abstract=6097646 ↩
[7] EU AI Act, Verordnung 2024/1689 – digital-strategy.ec.europa.eu ↩
[8] Stack Overflow, Developer Survey 2025 – survey.stackoverflow.co/2025 ↩
[9] DORA, State of AI-Assisted Software Development (September 2025) – cloud.google.com ↩