Ihr Team liefert schneller als je zuvor. Die KI schreibt das Feature, schreibt die Tests, die Suite wird grün, der Pull Request geht durch. Und dann kommt im Planning die Frage, meistens von der Person, die die Rechnungen unterschreibt: Brauchen wir wirklich noch Menschen, die sich manuell durch die App klicken? Und brauchen wir am Ende noch eine echte Abnahme durch einen Menschen?
Ja, beides. Und die menschliche Abnahme braucht heute mehr Raum als vor zwei Jahren, nicht weniger.
Automatisieren Sie alles, was die Frage beantwortet, ob der Code das tut, was ihm gesagt wurde. Behalten Sie Menschen für die Frage, die keine Testsuite stellen kann: Fühlt sich die Nutzung richtig an. Das sind zwei verschiedene Fragen. Die zweite stellen die meisten Teams inzwischen kaum noch, weil die erste so billig zu beantworten geworden ist.
Was bei KI-generiertem Code wirklich schiefgeht
Die Datenlage dazu ist im letzten Jahr deutlich besser geworden, und sie sagt nicht das, was die Toolhersteller sich erhofft hatten.
CodeRabbit hat im Dezember 2025 470 echte Open-Source-Pull-Requests ausgewertet, davon 320 mit KI als Co-Autor und 150 rein menschlich geschrieben. Kritische und schwere Defekte lagen auf der KI-Seite bis zu 1,7-mal höher. Logik- und Korrektheitsfehler, also falsche Geschäftslogik und unsichere Kontrollflüsse, stiegen um 75 %. Performanceprobleme wie exzessive I/O traten fast achtmal so häufig auf.
Lightrun hat für seinen Report 2026 200 SRE- und DevOps-Verantwortliche aus den USA, Großbritannien und der EU befragt. Bei 43 % der KI-generierten Änderungen war manuelles Debugging in Produktion nötig, nachdem sie QA und Staging bereits passiert hatten. Lesen Sie diese Zahl zweimal, denn sie entscheidet die ganze Diskussion. Das Qualitätstor war da. Es hat nichts gefangen.
SmartBear hat im Mai 2026 273 Software-Verantwortliche gefragt, ob die Qualität gehalten hat. 70 % sagten, sie habe bereits nachgelassen, weil die Codeerstellung der Testkapazität davongelaufen ist.
Nichts davon spricht gegen KI-gestützte Entwicklung. Wir nutzen sie täglich und geben sie nicht wieder her. Es spricht dafür, dass die Menge an Code stark gestiegen ist, während die Instanz, die diesen Code prüft, exakt gleich groß geblieben ist.
Die Frage, die kein Test stellt
An dieser Stelle denken die meisten Teams meiner Meinung nach falsch herum.
KI ist wirklich gut darin, Geschäftslogik in Code zu übersetzen. Geben Sie ihr eine klare Regel, und sie implementiert die Regel, deckt die Verzweigungen ab und schreibt einen Test, der beweist, dass die Regel hält. Dieser Teil ist so gut wie gelöst, und alles andere zu behaupten ist Nostalgie.
Was sie nicht kann, ist die Welt zu verstehen, in der Ihre App lebt. Sie hat noch nie ein Handy einhändig in der Straßenbahn gehalten, bei zwei Balken Empfang. Sie weiß nicht, dass Ihre wichtigste Aktion genau dort sitzt, wo der Daumen auf einem Sechs-Zoll-Display nicht hinkommt. Oder dass der Ladezustand technisch korrekt ist und die App trotzdem kaputt wirken lässt. Oder dass das Formular in Ordnung ist, nur würde kein Mensch es in dieser Reihenfolge ausfüllen.
Es gibt kein Assert für "das fühlt sich falsch an". Kein Test schlägt fehl, weil ein Screen verwirrend ist.
Fast alles, was Sie bauen, ist für Menschen gebaut. Also muss ein Mensch die Abnahme machen. Das ist keine Prozessvorliebe, das ist die Form des Problems.
Ihre vier Optionen
1. Nur automatisierte Suites, inklusive KI-geschriebener Tests
Die billigste Variante und aktuell mit Abstand die häufigste. Unit-Tests, Integrationstests, CI, und zunehmend auch Tests, die derselbe Assistent geschrieben hat wie das Feature.
Schnell, an der Grenze fast kostenlos, und sie fängt echte Regressionen. Sie hat aber ein strukturelles Loch. Wenn dasselbe Modell Implementierung und Test schreibt, entstehen beide aus derselben Lesart der Anforderung. War diese Lesart falsch, bekommen Sie eine selbstbewusst grüne Suite, die beweist, dass das Falsche einwandfrei funktioniert.
2. Automatisierte Suites plus Emulatoren und Cloud-Gerätefarmen
BrowserStack oder Ähnliches dazu, Läufe über Geräte- und Browsermatrizen, Screenshots einsammeln. Nichts anzuschaffen, skaliert so weit, wie Sie zahlen, und es fängt tatsächlich Layoutbrüche.
Was es nicht liefert, ist ein Mensch, der das Produkt benutzt. Ein Screenshot auf einem virtuellen Pixel sagt Ihnen, dass der Button gerendert wurde. Er sagt nichts darüber, ob die App ruckelt, sobald das Gerät warm wird, ob die Push-Nachricht ankommt, während man gerade hinschaut, oder ob der Ablauf angenehm ist.
3. Entwickler testen ihre eigene Arbeit
In kleinen Teams verbreitet und besser als nichts. Es ist trotzdem die schwächste der vier Optionen, aus einem Grund, der mit Können nichts zu tun hat.
Wer ein Feature gebaut hat, kann es nicht mehr frisch sehen. Er weiß, welchen Button er drückt, in welcher Reihenfolge, mit welchen Daten. Er meidet unbewusst genau die Pfade, die sich falsch anfühlen, weil sie sich schon beim Bauen falsch angefühlt haben. Lassen Sie einen Entwickler seinen eigenen Screen testen, und Sie bekommen den Happy Path, wunderbar verifiziert.
4. Eine dedizierte QA-Person, auf echten Geräten, in festem Takt
Jemand, dessen Aufgabe Qualität ist, der auf der Hardware testet, die Ihre Nutzer wirklich besitzen, nach Kalender statt am Projektende.
So arbeiten wir. Eine QA-Expertin oder ein QA-Experte, ein voller Tag pro Woche und App, auf 16 physischen Geräten mit Android, iOS, iPadOS, macOS, Windows und Linux. Keine automatisierten Läufe auf diesen Geräten. Ein Mensch, der sie in der Hand hält und das Produkt so benutzt, wie ein Nutzer es täte.
Der Preis ist ehrlich: ein Tag pro Woche, jede Woche, der kein Feature produziert. Dafür sehen Sie Ihr Produkt so, wie Ihre Nutzer es sehen werden, ungefähr eine Woche bevor sie es tun.
Wo jede Option bricht
Option 1 bricht leise, und genau das macht sie gefährlich. Nichts sieht falsch aus, bis ein Nutzer es Ihnen sagt, und dann ist es Produktion und ein Support-Gespräch.
Option 2 bricht an allem Physischen. Echte Netze, echte Akkus, thermisches Drosseln auf einem drei Jahre alten Android-Mittelklassegerät, echte Hände.
Option 3 bricht an Vertrautheit, und zwar umso stärker, je erfahrener die Entwicklerin oder der Entwickler ist.
Option 4, meine Empfehlung, bricht auf eine sehr spezifische und sehr verbreitete Art: wenn die QA-Person außerhalb der Entwicklungsschleife sitzt. Wer einen fertigen Build bekommt, durchklickt und Tickets ins Backlog schreibt, ist ein Filter, kein Feedback. Alles, was dort gefunden wird, ist zum Zeitpunkt des Fundes schon teuer, und das Team fühlt sich nicht mehr zuständig dafür, wie sich das Produkt anfühlt, weil Qualität jetzt jemand anderes Spalte auf dem Board ist. Der Takt verhindert das. Wöchentlich heißt, die Funde landen, solange der Code noch warm ist und die Person, die ihn geschrieben hat, sich noch erinnert, warum.
Und das ehrliche Zugeständnis: Wenn Ihr Produkt ein internes Werkzeug ist, ein Admin-Panel oder ein Betriebsdashboard für 20 geschulte Mitarbeiter ohne Alternative, dann geben Sie hier zu viel aus. Diese Nutzer werden Ihnen sagen, dass es hässlich ist, und es weiter benutzen, weil es ihr Job ist. Automatisieren Sie die Korrektheit, schützen Sie die Daten, sparen Sie sich die Zeremonie.
Die Entscheidungstabelle
- Nur Automatisierung. Was er fängt: Regressionen und Logik, die die Spezifikation richtig beschrieben hat. Was er verpasst: Alles, was die Spezifikation falsch hatte, sowie UX und Gefühl. Passt zu: APIs, Backend-Dienste, interne Werkzeuge.
- Plus Cloud-Geräte. Was er fängt: Layoutbrüche über Bildschirme und Browser hinweg. Was er verpasst: Reale Bedingungen, ob der Ablauf Sinn ergibt. Passt zu: Webprodukte mit breiter Browserstreuung.
- Entwickler testen selbst. Was er fängt: Offensichtliche Fehler, den Happy Path. Was er verpasst: Alles, worauf frische Hände als Erstes stoßen. Passt zu: Sehr frühe Phase, vor Umsatz.
- Dedizierte QA auf echten Geräten, wöchentlich. Was er fängt: Gefühl, Ablauf und das korrekt gebaute Falsche. Was er verpasst: Strukturell nichts, kostet aber einen Tag pro Woche. Passt zu: Alles, wo Nutzer abspringen können.
Nehmen Sie das
Wenn Ihre Nutzer die Wahl haben, also Consumer-Apps, Marktplätze, alles, wo eine schlechte erste Sitzung mit einer Deinstallation endet, nehmen Sie Option 4. Ein echter Mensch, auf echter Hardware, im Wochentakt, der den Code nicht geschrieben hat. Das ist die Empfehlung, und ich halte sie nicht für knapp.
Wenn Ihre Nutzer keine Wahl haben, also interne Werkzeuge und Backoffice-Systeme, nehmen Sie Option 1 oder 2 und stecken Sie die gesparte Zeit in Korrektheit und Datenintegrität. Niemand kündigt ein ERP, weil die Animation hakt.
Wenn Sie reguliert sind, Gesundheitswesen, Fintech, alles mit Prüfpfad, brauchen Sie die dokumentierte QA-Funktion unabhängig davon, wie sich die Nutzung anfühlt. "Das hat die KI geschrieben" ist keine Antwort, die Prüfer akzeptieren, und sie wird auch keine werden.
Eine Regel gilt über alle vier hinweg: Lassen Sie niemals das, was den Code schreibt, das Einzige sein, was den Code prüft. Ein Mensch prüft die Abnahmekriterien, bevor die KI sie anfasst, ein anderer Mensch bestätigt das Ergebnis. Sonst korrigieren Sie Ihre eigenen Hausaufgaben, nur in Maschinengeschwindigkeit.
Sie müssen dafür wahrscheinlich niemanden einstellen
Und hier liegt der Fehler in die andere Richtung. Nach dem bisher Gesagten ist der Reflex, eine QA-Stelle zu schaffen. Für die meisten Teams mit einem oder zwei Produkten ist das ein volles Gehalt für Arbeit, die ehrlich gesagt einen Tag pro Woche braucht.
Wir haben den Aufbau für unsere eigenen Projekte geschaffen, und er war nicht ausgelastet, also bieten wir ihn anderen Teams an. Eine QA-Fachkraft, ein Tag pro Woche, 16 Geräte mit Android, iOS, iPadOS, macOS, Windows und Linux, die Ihre Builds auf der Hardware testet, die Ihre Nutzer wirklich besitzen. Sie bekommen die Funde, solange der Code noch warm ist, ohne feste Stelle und ohne ein Regal voller Telefone, die in drei Jahren veraltet sind.
Bei Conimex IT bauen wir maßgeschneiderte Web- und Mobilprodukte mit Laravel, React und React Native, als Laravel Community Partner, und wir arbeiten durchgehend mit KI-Unterstützung. Genau deshalb ist der manuelle Testtag bei uns geschützt und nicht optional.
Wenn Sie KI-gestützte Arbeit schneller ausliefern, als Sie sie prüfen können, und nicht sicher sind, ob das letzte menschliche Tor in Ihrem Prozess echt oder nur Zeremonie ist, schauen wir es uns gemeinsam an. Schreiben Sie uns an [email protected].