KI macht aus Entwicklern still und heimlich Tester

Niemand hat eine E-Mail dazu verschickt. Kein Organigramm hat sich geändert. Aber etwas hat sich in der Arbeitsweise von Software-Teams verschoben. Am einfachsten erkennst Du es daran, wie Entwicklern ihre Woche beschreiben: Sie schreiben weniger Code als früher. Sie lesen viel mehr davon.

Copilot, Cursor, Claude Code und die wachsende Schar von Programmier-Agenten produzieren mittlerweile einen erheblichen Anteil dessen, was letztendlich in die Produktion geht. Pull-Requests sind umfangreicher. Funktionen, die früher Tage dauerten, erscheinen an einem Nachmittag. Die Velocity-Dashboards sehen wunderbar aus, und die Führungsebene ist zufrieden.

Dann kommt die Rechnung, und zwar erst später.

Die Zahlen sind eindeutig

Ein paar Jahre lang war das nur eine Diskussion auf dem Flur. Jetzt gibt es Daten.

Faros AI hat 22.000 Entwickler in mehr als 4.000 Teams erfasst und die Quartale mit dem geringsten KI-Einsatz jedes Teams mit denen mit dem höchsten verglichen. Der Vorteil ist echt: Die Anzahl der pro Entwickler abgeschlossenen Epics stieg um 66 Prozent, der Aufgabendurchsatz um 33,7 Prozent, die PR-Merge-Rate um 16,2 Prozent. Dann die andere Hälfte des Berichts. Die Anzahl der Bugs pro Entwickler stieg um 54 Prozent. Die Produktionsvorfälle pro Pull Request haben sich in etwa verdreifacht. Die Code-Fluktuation hat sich fast verzehnfacht. Die PR-Größe stieg um 51 Prozent. Die mittlere Review-Zeit ist fünfmal so lang geworden. Sie nannten dieses Muster „Acceleration Whiplash“, und der Name passt.

Was mir besonders im Gedächtnis bleibt, ist etwas Unauffälligeres: Pull-Requests, die ohne jegliche Überprüfung – sei es durch Menschen oder durch Bots – zusammengeführt wurden, stiegen um 31,3 Prozent, und Faros interpretiert dies nicht als bewusste Entscheidung, die Überprüfung zu überspringen. Die Prüfer konnten mit dem Volumen, das auf ihren Schreibtisch kam, einfach nicht Schritt halten. Niemand hat sich dafür entschieden. Es ist einfach passiert, ein hektischer Sprint nach dem anderen.

Die geschäftliche Seite davon zeigt sich in einer separaten Studie. Wakefield Research befragte im Auftrag von Sauce Labs 400 Führungskräfte und technische Leiter und stellte fest, dass 80 Prozent in den vergangenen zwölf Monaten einen Produktionsvorfall, einen Ausfall oder einen kundenwirksamen Fehler auf KI-generierten Code zurückführen konnten. Fünfundsechzig Prozent gaben an, dass ihr schlimmster Qualitätsvorfall in diesem Jahr eine halbe Million Dollar oder mehr gekostet habe. Und hier kommt der Teil, der uns allen zu denken geben sollte: Nur 6 Prozent sagten, sie würden KI-Tools nutzen, um diesen Code ständig oder oft zu testen.

Wir generieren mit Maschinen-Geschwindigkeit und prüfen mit menschlicher Geschwindigkeit. Die Lücke zwischen diesen beiden Zahlen ist genau der Bereich, in dem jetzt die Arbeit liegt.

Warum die Last der Qualitätssicherung auf den Entwicklern lastet

Drei Dinge führen dazu.

Erstens: KI-Code wirkt plausibel. Er lässt sich kompilieren. Er besteht die offensichtlichen Unit-Tests. Die Benennung ist sinnvoll und die Struktur ist ordentlich. Beim flüchtigen Überfliegen sieht er aus wie etwas, das ein kompetenter Kollege an einem guten Tag geschrieben hat. Die Fehler treten erst später zutage – an Integrationsgrenzen, unter realer Last, mit Daten, die niemand vorhergesehen hat, oder wenn sich eine Annahme über das übergeordnete System als falsch herausstellt. Das sind Probleme der Beurteilung, keine Probleme des Musterabgleichs.

Zweitens hat das Hinzuholen von Personal das Problem nicht gelöst. An dieser Stelle möchte ich der weit verbreiteten Behauptung widersprechen, dass Teams einfach bei der Qualitätssicherung gespart haben und nun die Quittung dafür bekommen. Den Daten von Sauce Labs zufolge haben 64 Prozent der Unternehmen im vergangenen Jahr ihre Mitarbeiterzahl in der Qualitätssicherung sogar erhöht, und trotzdem sind die Vorfälle gestiegen. Mehr Prüfer am Ende der Pipeline sind keine Lösung, wenn sich das Volumen, das dort ankommt, vervielfacht hat. Der Engpass hat sich verlagert, und einfach mehr Leute auf den alten Engpass anzusetzen, bringt kaum etwas.

Drittens können von KI geschriebene Tests die Situation eher verschlimmern als verbessern. Modelle neigen dazu, Tests für den vorhandenen Code zu schreiben, statt für das beabsichtigte Verhalten. Die Testabdeckung sieht gut aus, während die beabsichtigte Funktionalität ungeprüft bleibt. Wenn dieselbe Modellfamilie sowohl die Implementierung als auch die Tests erstellt, die diese absegnen, hast du eine Echokammer geschaffen und sie als Sicherheitsnetz bezeichnet.

Der Entwickler, der früher für eine Funktion verantwortlich war, hat nun eine schwierigere Aufgabe: die Frage, ob sie tatsächlich korrekt ist. Entspricht sie der Anforderung, nicht der Eingabeaufforderung? Passt sie zur Architektur? Bewältigt sie die Fälle, die das Modell nie gesehen hat? Wird jemand in der Lage sein, sie in sechs Monaten zu warten?

Das ist Testen. Es war schon immer Testen. Es trug nur früher den Namen von jemand anderem.

Das interessanteste Argument dazu kommt von einem KI-Optimisten

Wenn du denkst, dass es hier darum geht, dass Tester ihr Revier verteidigen, schau dir mal an, was Salvatore Sanfilippo geschrieben hat.

Sanfilippo, besser bekannt als antirez, hat Redis entwickelt und ist Ende 2024 wieder in das Unternehmen eingetreten. Er ist ein C-Systemprogrammierer der alten Schule, hat sich sein ganzes Berufsleben lang für kleinen, lesbaren, handgeschriebenen Code eingesetzt und öffentlich dazu aufgerufen, nicht auf den Anti-KI-Hype hereinzufallen. Niemand wird ihm vorwerfen, sich von einem Programmieragenten bedroht zu fühlen.

Sein Beitrag vom Juli, „Control the ideas, not the code“, enthält ein Argument, das jeden Testprofi interessieren sollte. Das Zeile für Zeile Durchlesen von generiertem Code, sagt er, sei mittlerweile eine schlechte Nutzung eines Arbeitstages. Niemand kann fünftausend Zeilen sinnvoll überprüfen. Modelle sind gut bei lokal optimalem Code, aber schwächer bei den großen Designentscheidungen – daher überprüft das Durchgehen von Funktion zu Funktion genau das, was am wenigsten wahrscheinlich falsch ist. Und jede Stunde, die man mit Lesen verbringt, ist eine Stunde, in der man sich nicht fragt, was die Software eigentlich tun soll.

Womit sollte man diese Zeit seiner Meinung nach stattdessen verbringen? Mit Qualität, Testen und dem Festhalten des Designs in menschlicher Sprache, damit der Nächste das mentale Modell übernimmt, anstatt es aus dem Quellcode rückzuentwickeln.

Lies das noch einmal. Einer der glaubwürdigsten Handprogrammierer seiner Generation, der in dieser Debatte auf der Pro-KI-Seite steht, kommt zu dem Schluss, dass Testen und Spezifikation die Arbeit sind, die Bestand hat. Genau dort landet auch die Faros-Telemetrie, die aus der entgegengesetzten Richtung kommt. Eine Überprüfung am Ende der Pipeline lässt sich nicht mit dem Volumen skalieren, daher muss Qualität früher etabliert und auf andere Weise nachgewiesen werden.

Seine eigene Praxis untermauert das. Der neue Redis-Array-Typ dauerte vier Monate, und sein Bericht darüber handelt nicht von Prompting. Es ist eine Geschichte darüber, das Ganze Zeile für Zeile durchzulesen, eine umfassende Testabdeckung aufzubauen, die Implementierung aus vielen Blickwinkeln einem Stresstest zu unterziehen und dann Module neu zu schreiben, mit denen er nicht zufrieden war. Seine Schlussfolgerung war, dass man bei ernsthafter Systemarbeit immer noch voll und ganz involviert sein muss, dass ihm das Sicherheitsnetz aber ermöglichte, ein Maß an Komplexität anzugehen, das er sonst übersprungen hätte.

Eine ehrliche Einschränkung, die er selbst anspricht: Er ist ein Fachexperte mit einem tiefgreifenden mentalen Modell davon, wie „richtig“ aussieht. Er ist sich ganz offen unsicher, was der richtige Weg für jüngere Programmierer ist, die dieses Modell noch nicht entwickelt haben. Diese Einschränkung fasst das ganze Problem in einem Satz zusammen. Wenn die Aufgabe nun darin besteht, Ideen zu steuern und Qualität zu gewährleisten, anstatt Code zu tippen – wo soll ein Entwickler dann lernen, wie man das gut macht?

Was gute Teams anders machen

Die Teams, die das gut hinbekommen, haben aufgehört, die Verifizierung als Phase zu betrachten, und behandeln sie nun als eigene Disziplin.

Sie trennen die Generierung von der Beurteilung. Die Maschine produziert, Menschen sind für die Teststrategie und die Entscheidungen über die Absicht verantwortlich. Sie schreiben klarere Spezifikationen und Akzeptanzkriterien, bevor die Generierung beginnt, denn die Verifizierung braucht etwas, anhand dessen sie überprüfen kann, und „sieht richtig aus“ ist kein Bezugspunkt. Sie verlegen Qualitätskontrollen früher in die Entwicklungsumgebung, statt am Ende noch mehr Reviews anzuhäufen. Sie halten Pull-Anfragen so klein, dass ein Mensch sie tatsächlich lesen kann. Sie nutzen unabhängige Modelle oder Agenten, um die Ausgabe zu überprüfen, anstatt das System, das den Code geschrieben hat, zu fragen, ob der Code gut ist. Und sie begegnen KI-generierten Änderungen mit derselben gesunden Skepsis, die sie früher dem ersten Commit eines unbekannten Auftragnehmers vorbehalten hatten.

Nichts davon ist ausgefallen. Das meiste davon ist genau das, wofür erfahrene Tester schon lange plädiert haben, lange bevor irgendjemand von einem LLM gehört hatte.

Zwei Fragen, die ich Führungskräften im Engineering immer wieder stelle

Wann habt ihr eure Entwickler das letzte Mal im Testen geschult?

Für die meisten Unternehmen lautet die ehrliche Antwort: noch nie. Testen war die Aufgabe von jemand anderem, also ging das auch auf dessen Schulungsbudget. Entwickler haben Unit-Tests von einem Kollegen gelernt, das Framework aus der Dokumentation, und das wurde als ausreichend angesehen, weil es weiter unten in der Kette eine Testabteilung gab, die auffing, was durchgerutscht war.

Diese Vorgehensweise funktioniert nicht mehr, und niemand hat den Schulungsplan entsprechend angepasst. Es wird von den Leuten verlangt, dass sie für Qualität sorgen – mit Wissen, das ihnen nie vermittelt wurde. Dann wird überrascht getan, wenn die Abdeckungszahlen gut aussehen und die Vorfälle trotzdem zunehmen.

Die Lücke liegt nicht bei den Tools. Entwickler können die Tools bereits bedienen. Was ihnen größtenteils nicht beigebracht wurde, ist die Denkweise: wie man Risiken analysiert und entscheidet, was tatsächlich einen Test verdient; der Unterschied zwischen einem Test, der besteht, und einem Test, der etwas beweist; wie man Testfälle anhand von Anforderungen entwirft, statt anhand einer Implementierung, die möglicherweise bereits falsch ist; wie exploratives Testen die Fehler aufspürt, für die keine Testsuite geschrieben wurde; und wie man einen Fehler als Information über einen Prozess interpretiert, statt als Bug, den es zu schließen gilt.

Dieses Wissen gibt es tatsächlich. Es wird vermittelt, ist strukturiert und kann zertifiziert werden. Eine Testschulung auf Einstiegsniveau dauert ein paar Tage und verschafft einem ganzen Team ein gemeinsames Vokabular, was allein schon überraschend viele Reibungspunkte zwischen Entwicklern und Testern beseitigt. Von dort aus verzweigen sich die Wege in die Testanalyse, die Testautomatisierung und tiefere Spezialisierungen. Nichts davon ist neu, und nichts davon wurde für das KI-Zeitalter erfunden. Es ist nur für eine Gruppe von Leuten zu einer tragenden Säule geworden, die sich das alles nie angeeignet haben.

Wenn eure Entwickler KI-generierten Code in die Produktion bringen, sind ein paar Tage fundierte Testschulung in diesem Jahr kein „Nice-to-have“. Es ist die kostengünstigste Möglichkeit zur Risikominderung, die euch zur Verfügung steht.

Wann hast du das letzte Mal einen Entwickler zu den Agile Testing Days mitgebracht?

Schulungen vermitteln ihnen die Grundlagen. Die Konferenz bietet ihnen etwas, was Schulungen nicht leisten können: die Argumente, die Erfahrungsberichte und die Menschen. Testprofis haben ihre gesamte Karriere damit verbracht, sich genau mit den Fragen zu beschäftigen, mit denen dein Team jetzt konfrontiert ist: Wie untersucht man Risiken, anstatt nur der Testabdeckung hinterherzujagen? Wie formuliert man die Absicht so, dass sie den Kontakt mit der Implementierung übersteht? Wie setzt man sich für Qualität ein in einem Raum, in dem nur von Velocity die Rede ist?

Dieses Wissen ist ungleich verteilt und findet sich größtenteils nicht in eurer Codebasis.

Die AgileTD 2026 findet vom 16. bis 19. November in Potsdam und online statt, mit mehr als 100 Vorträgen und über 80 Referenten zu den Themen agiles Testen, Automatisierung, KI im Quality Engineering, DevOps und Führung. Der Frühbucherrabatt gilt bis zum 20. September 2026. Das Programm war schon immer eher für ganze Teams als nur für Tester konzipiert, und dieses Jahr ist das wichtiger denn je. Der Entwickler, der das letzte Quartal damit verbracht hat, hinter einem Agenten aufzuräumen, wird einen Raum voller Menschen vorfinden, die sich intensiv mit dem Problem auseinandergesetzt haben, mit dem sie gerade zu kämpfen haben.

Schick sie hin. Besser noch: Geh mit ihnen hin. Die Gespräche auf dem Heimweg sind meist der Ort, an dem der Wandel tatsächlich beginnt.

Der Vorteil ist echt

Ich möchte klarstellen, dass nichts davon ein Argument gegen KI-gestützte Entwicklung ist. Die Durchsatzgewinne sind messbar und werden nicht verschwinden. Der Wettbewerbsdruck wird die Entscheidung zur Einführung für jeden treffen, der noch abwägt.

Aber die Vorteile werden erst dann dauerhaft, wenn das Testen mit der Entwicklung Schritt hält. Teams, die das Testen im KI-Zeitalter als eine Kompetenz erster Klasse betrachten, werden schneller bessere Software ausliefern als Teams, die immer noch generierte Codezeilen und zusammengeführte PRs zählen.

Vielleicht ist es für eure Entwickler genau der richtige Zeitpunkt, den Schritt zu wagen.