KI schreibt jetzt Ihren Code. Die Incidents pro Pull Request sind um 242 % gestiegen.
KI-generierter Code überholt das Code-Review: Incidents pro PR +242 %, Bugs pro Entwickler +54 %.Warum End-to-End-Tests jetzt das Qualitätstor sind, das mitwächst.
10 Min. LesezeitVom Team von GUI Test Studio
Was Faros AI gemessen hat
Im April 2026 veröffentlichte Faros AI The AI Engineering Report 2026: The Acceleration Whiplash.Er ist keine Umfrage darüber, wie sich Entwickler fühlen.Er beruht auf rund zwei Jahren Telemetrie von 22.000 Entwicklern in mehr als 4.000 Teams und vergleicht die Zeiträume mit der geringsten und der höchsten KI-Nutzung innerhalb jeder Organisation.
Der erste Befund gibt den Rahmen vor.In 80 % der Teams nutzt mehr als die Hälfte der Entwickler jede Woche KI-Werkzeuge, und der Anteil des KI-generierten Codes, den Entwickler übernehmen, stieg von 20 % auf 60 %.
„KI unterstützt die Entwickler nicht. In den meisten Organisationen führt sie sie.“
Die gute Nachricht ist echt, und der Bericht sagt es auch.Bei hoher KI-Nutzung erledigen Teams mehr Arbeit.
+66%
Abgeschlossene Epics pro Entwickler
+33.7%
Erledigte Aufgaben pro Entwickler
+16.2%
Gemergte Pull-Requests pro Entwickler
Dann kommt der Rückschlag.Dieselben Teams liefern mehr Vorfälle und mehr Bugs aus, und die Kurve wird steiler, nicht flacher.
Produktionsqualität bei hoher KI-Nutzung
Vorfälle pro Pull-Request
Vorfälle pro gemergter Änderung treten mehr als dreimal so häufig auf.
Monatliche Vorfälle
Ausfälle, Sicherheitsereignisse und Störungen, die bei den Nutzern ankommen.
Bugs pro Entwickler, Bericht 2026
Bugs pro Entwickler, Bericht 2025
Die Fehlerrate steigt immer steiler, statt abzuflachen.
Bugs pro Pull-Request
Warum nehmen Bugs und Vorfälle mit KI-generiertem Code zu?
Ein Vorfall ist das, was ein Nutzer spürt: ein Ausfall, ein Sicherheitsereignis, ein Systemversagen.Zwischen geringer und hoher KI-Nutzung stieg das Verhältnis von Vorfällen zu gemergten Pull-Requests um 242.7 %, und die monatlichen Vorfälle stiegen um 57.9 %.
„Für jeden gemergten PR treten Vorfälle mit mehr als der dreifachen Rate auf.“
Die Bugs folgen derselben Linie.Der Bericht von Faros aus dem Jahr 2025, The AI Productivity Paradox, maß bei den Bugs pro Entwickler ein Plus von 9 %.In diesem Datensatz liegt der Wert bei plus 54 %, und die eigene Seite des Berichts beziffert die Bugs pro Pull-Request mit plus 28.7 %.Je mehr sich ein Team auf KI verlässt, desto schneller wachsen die Fehler.
Diese Zahlen beschreiben, was geschehen ist, nicht eine einzelne Ursache, und Faros sagt das ausdrücklich.Aber sie zeigen alle in dieselbe Richtung.Mehr Code erreicht die Produktion, schneller, und jede Änderung trägt mehr Risiko als zuvor.
Warum kann das Code-Review mit KI-Programmieragenten nicht Schritt halten?
Das Code-Review wurde für Code entworfen, der in menschlichem Tempo geschrieben wird.Ein KI-Programmieragent schreibt einen Pull-Request in Minuten, und ein Team mit fünf Agenten öffnet an einem Tag mehr Pull-Requests, als seine erfahrenen Entwickler in einer Woche lesen können.
Code-Review unter der Menge KI-generierten Codes
Mediane Zeit im Review
Mediane Zeit bis zum ersten Review
Ganz ohne Review gemergte Pull-Requests
Weder ein Mensch noch ein KI-Agent hat sie sich angesehen.
Faros hat die Warteschlange gemessen: Die mediane Zeit bis zum ersten Review ist um 156.6 % gestiegen, die mediane Zeit im Review um 441.5 %.Und der Druck findet ein Ventil.Pull-Requests, die ganz ohne Review gemergt werden, weder von einem Menschen noch von einem Agenten geprüft, haben um 31.3 % zugenommen.
„Code gelangt mit spürbar höherer Rate ohne jede Aufsicht in Produktionssysteme.“
Selbst ein sorgfältiges Review hat einen blinden Fleck.
- Ein Reviewer liest einen Diff, und ein Diff zeigt nie die laufende Anwendung.
- Eine Schaltfläche, die ein neuer Stil verdeckt, eine auf der Kassenseite falsch berechnete Gesamtsumme, ein Dialog, der sich hinter dem Fenster öffnet: Nichts davon ist in dem Code sichtbar, der es verursacht hat.
Was fängt die Bugs ab, die das Review übersieht?
Der erste Gedanke ist, den Agenten um mehr Unit-Tests zu bitten.Tun Sie das, aber hören Sie dort nicht auf.Tests vom selben Agenten, der den Code geschrieben hat, teilen dessen Verständnis der Aufgabe: Hat er die Anforderung falsch verstanden, stimmen Code und Tests miteinander überein, und beide sind falsch.
Das Sicherheitsnetz, das mit dem Tempo der KI mithält, hat drei Eigenschaften.
| Eigenschaft | Warum es bei KI-generiertem Code wichtig ist |
|---|---|
| Automatisiert | Es läuft bei jedem Pull-Request und jedem Build, im Tempo der Agenten, ohne auf einen Reviewer zu warten. |
| Unabhängig | Ein Mensch verantwortet es, und es hängt weder vom Code noch von der KI ab, die den Code geschrieben hat, also kann es deren Fehler nicht teilen. |
| Prüft, was Nutzer sehen | Es bedient die echte Anwendung über ihre Oberfläche und prüft den Bildschirm, wo Vorfälle spürbar werden. |
Das ist ein End-to-End-Test: ein Test der ganzen Anwendung über ihre Oberfläche, so wie ein Nutzer sie durchläuft, von der Anmeldung bis zur Bezahlung.Darauf läuft das Testen von KI-generiertem Code hinaus, und genau das verlangen die Zahlen von Faros: eine Prüfung, die mit der Menge der Änderungen wächst, nicht mit der Zahl der Reviewer.
Ein Agent öffnet einen PR
Minuten Arbeit, viele Dateien
Unit-Tests bestehen
Das eigene Verständnis des Agenten
End-to-End-Tests laufen
Was der Nutzer sieht, verantwortet von einem Menschen
Merge oder blockiert
Ein Fehlschlag wartet auf eine Korrektur
Wie machen Sie End-to-End-Tests zu einem Quality Gate in CI/CD?
Definition
Ein Quality Gate ist eine Prüfung, die eine Änderung bestehen muss, bevor sie gemergt oder bereitgestellt wird.
- Fünf Gewohnheiten machen End-to-End-Tests zu einem Gate, um das sich ein Agent nicht herumreden kann.
- 1
Die Abläufe auflisten, die nie kaputtgehen dürfen
Registrierung, Anmeldung, Suche, Kasse, der Bericht, den Ihre Kunden jeden Montag exportieren.Fünf bis zehn Abläufe, jeder mit dem Ergebnis, das ein Nutzer erwartet.Diese Liste ist die Spezifikation, und sie gehört einem Menschen, nicht dem Agenten.
- 2
Den Bildschirm testen, nicht den Code
Prüfen Sie, was ein Nutzer liest und sieht: die Gesamtsumme, die Meldung, die Schaltfläche, die Anordnung.Ein Agent benennt Klassen um und schreibt Komponenten nach Belieben neu.Ein Test, der am Bildschirm verankert ist, übersteht das und schlägt trotzdem fehl, wenn der Bildschirm falsch ist.
- 3
Bei jedem Pull-Request ausführen und bei einem Fehlschlag blockieren
Ein Ergebnis, das nur warnt, wird bald ignoriert.Lassen Sie einen fehlgeschlagenen End-to-End-Test den Build fehlschlagen, damit die Änderung auf eine Korrektur wartet, statt bei den Nutzern anzukommen.
- 4
Die Tests außer Reichweite des Agenten halten
Der Agent darf die Tests ausführen und die Ergebnisse lesen.Eine Änderung dessen, was ein Test erwartet, braucht die Freigabe eines Menschen, sonst driften die Tests zu dem hin, was der Code zufällig tut.
- 5
Fehlschläge lesbar machen und melden
Ein Fehlschlag sollte sagen, welcher Schritt fehlgeschlagen ist und wie der Bildschirm abweicht, mit Bildern, damit der Agent eine Korrektur vorschlagen und ein Mensch entscheiden kann.Und er sollte zu einem Bug in Ihrem Tracker werden, ohne dass jemand Screenshots kopiert: siehe fehlgeschlagene Tests in Jira-Bugs verwandeln.
Eine Warnung: Ein Gate, das grundlos fehlschlägt, ist schlimmer als gar kein Gate, weil die Leute lernen, es zu ignorieren.Ein Gate braucht Tests, die eine echte Regression von harmlosem Rauschen unterscheiden.Darum geht es in Flaky Tests und False Positives.
Empfohlen
- End-to-End-Tests der Abläufe, auf die sich Nutzer verlassen
- Ein fehlgeschlagener Lauf, der den Merge blockiert
- Ein Mensch, der jede Änderung dessen freigibt, was ein Test erwartet
- Fehlschläge mit Bildern und Schritten, als Bugs gemeldet
Vermeiden
- Die eigenen Tests des Agenten als einziges Sicherheitsnetz
- Mergen, wenn die Reviewer zu beschäftigt sind, um hinzusehen
- Ein roter End-to-End-Lauf, der nur warnt
- Gates, die so instabil sind, dass niemand ihnen traut
KI-generierten Code bei jedem Build mit GUI Test Studio testen
GUI Test Studio ist genau für dieses Gate gebaut.Es testet Web-Apps, Windows-Desktop-Apps, Smartphones und Spiele durchgängig, über ihre Oberfläche, ohne Testcode, der geschrieben oder gepflegt werden muss.
Ein Test in Minuten: aufzeichnen oder beschreiben
Zeichnen Sie einen Ablauf einmal im GUI Test Runner-Recorder auf, indem Sie sich durch die echte Anwendung klicken und tippen.Oder beschreiben Sie ihn in einem Prompt für Claude, ChatGPT mit Codex oder ein lokales KI-Modell, eines von uns oder Ihr eigenes, und der Test wird für Sie erstellt.Jede Prüfung, die ein Assistent hinzufügt, wird an Ort und Stelle ausprobiert und abgelehnt, wenn sie auf dem Bildschirm jetzt gerade nicht bestehen könnte.
So oder so prüft der Test, was der Bildschirm zeigt.
- Eine Bild-Assertion vergleicht das Bild eines Elements, eine Text-Assertion liest seine Wörter.
- Die GTS Engine + AI findet jedes Element, indem sie zuerst die Anwendung fragt, über ihre Barrierefreiheitsinformationen oder die eigenen Elemente der Webseite, und am Aussehen, wenn die Anwendung nichts sagt.
- Eine umbenannte Klasse oder eine neu geschriebene Komponente macht den Test nicht kaputt.
Ein Gate in Ihrer Pipeline, mit gtr-cli
gtr-cli führt dieselben Tests auf einem Windows-Build-Rechner aus und antwortet so, wie eine Pipeline es erwartet: Sein Exitcode lässt den Build fehlschlagen, eine JUnit-Datei füllt die Registerkarte der Tests, und eine Markdown-Zusammenfassung liegt für den Pull-Request bereit.Mit einer einzigen Option wird ein fehlgeschlagener Test zu einem Jira-Vorgang mit den Schritten zur Reproduktion und dem erwarteten und dem gefundenen Bild.
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--summary results\summary.md --artifacts results\artifacts --jira on-failureDas funktioniert in TeamCity, Jenkins, GitHub Actions, GitLab und Azure DevOps: siehe Tests in Ihrer Pipeline ausführen, und End-to-End-Tests bei jedem Build ausführen für eine Schritt-für-Schritt-Einrichtung mit TeamCity.
Eine echte Regression oder harmloses Rauschen?
Jeder Lauf endet in einem Konfidenzbericht: für jede Prüfung, ob das Element in der Suchphase gefunden wurde und ob es in der Verifikationsphase dem Aufgezeichneten entspricht.
- Wenn sich ein Bild unterscheidet, wirft die Intelligente KI-Analyse einen zweiten Blick darauf.
- Sie ignoriert Rendering-Rauschen und erkennt trotzdem ein geändertes Wort, ein fehlendes Badge oder eine grau gewordene Schaltfläche, und sagt dann in einfachen Worten, was sich geändert hat.
Auch der Agent kann das Gate ausführen
Über den Connector kann der Assistent, der Ihren Code schreibt, Ihre Tests ausführen, das Ergebnis lesen und eine Änderung an einem Test vorschlagen, die auf Ihre Bestätigung wartet.Ein Mensch behält die Entscheidung darüber, was die Tests erwarten.Der ganze Zyklus steht in Entwicklung mit KI-Agenten (ADLC).
Das Wichtigste in Kürze
- 1KI ist jetzt der Hauptautor des Codes. Der Durchsatz steigt, die Vorfälle auch: +242.7 % pro gemergtem Pull-Request, +57.9 % pro Monat.
- 2Bugs nehmen immer schneller zu, statt sich zu stabilisieren. Die Bugs pro Entwickler stiegen um 54 %, gegenüber 9 % im Bericht 2025.
- 3Das Review ist an seine Grenze gestoßen. 31.3 % mehr Pull-Requests werden ganz ohne Review gemergt.
- 4Das Sicherheitsnetz muss automatisiert und unabhängig sein: End-to-End-Tests dessen, was Nutzer sehen, verantwortet von einem Menschen, bei jedem Build ausgeführt.
- 5Machen Sie daraus ein Gate. Ein Fehlschlag blockiert den Merge, meldet einen Bug und sagt, was sich geändert hat.
Fragen
Verursacht KI-generierter Code mehr Bugs?
Der AI Engineering Report 2026 von Faros AI hat die Zeiträume mit der geringsten und der höchsten KI-Nutzung innerhalb jeder Organisation verglichen, über 22.000 Entwickler hinweg.Bei hoher Nutzung stiegen die Bugs pro Entwickler um 54 % und die Vorfälle pro gemergtem Pull-Request um 242.7 %.Der Bericht misst, was geschehen ist, nicht eine einzelne Ursache, aber die Fehlerrate steigt, je stärker die Nutzung wird.
Warum genügt das Code-Review für KI-generierten Code nicht?
Die Zeit für das Review wächst mit der Menge des Codes, und die KI vervielfacht die Menge.Faros hat gemessen, dass die mediane Zeit bis zum ersten Review um 156.6 % gestiegen ist und die ganz ohne Review gemergten Pull-Requests um 31.3 % zugenommen haben.Ein Reviewer liest außerdem einen Diff, nie die laufende Anwendung, sodass ein kaputter Bildschirm ein sorgfältiges Review bestehen kann.
Wie testen Sie KI-generierten Code, bevor er in die Produktion gelangt?
Pflegen Sie End-to-End-Tests Ihrer kritischen Abläufe, die ein Mensch verantwortet, unabhängig vom Code und vom Agenten, der ihn geschrieben hat.Führen Sie sie bei jedem Pull-Request oder Build aus, und lassen Sie einen Fehlschlag den Merge blockieren.Sie prüfen, was Nutzer sehen, ganz gleich, wer den Code geschrieben hat.
Was ist ein Quality Gate in CI/CD?
Ein Quality Gate ist eine Prüfung in Ihrer Pipeline, die eine Änderung bestehen muss, bevor sie gemergt oder bereitgestellt wird.Ein fehlgeschlagener End-to-End-Test lässt den Build fehlschlagen, sodass die Änderung auf eine Korrektur wartet, statt bei den Nutzern anzukommen.
Kann ein KI-Programmieragent Tests von GUI Test Studio erstellen und ausführen?
Ja.Claude, ChatGPT mit Codex, Copilot Chat in VS Code oder ein lokales KI-Modell, eines von uns oder Ihr eigenes, kann einen Test aus einem Prompt erstellen und ihn über den Connector von GUI Test Studio ausführen.In einer Pipeline führt gtr-cli dieselben Tests ganz ohne Assistenten aus.
Zahlen: Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash (April 2026), und seine Berichtsseite für die Bugs pro Pull-Request.Faros AI, Claude, ChatGPT, Codex, Copilot, OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps und YouTube sind Marken ihrer jeweiligen Inhaber.
Bereit, Ihren ersten Test aufzuzeichnen?
Jede Funktion, 15 Tage lang.
Lieber an der Art von App sehen, die Sie testen?Buchen Sie ein kostenloses 30-minütiges Gespräch mit unserem Team.