Apps testen, die mit Cursor, Claude Code und Lovable gebaut wurden — die versteckte Bug-Klasse
KI-generierter Code fühlt sich richtig an, scheitert aber auf Wegen, wie es handgeschriebener Code selten tut. Hier ist das Failure-Pattern, das Vibe-Coding-Apps teilen.
Wenn du eine App mit Cursor, Claude Code, Lovable oder einem anderen “Vibe Coding”-Tool gebaut hast, hast du das Muster schon bemerkt: Die KI shipt Features schnell, die Tests bestehen, die Demo funktioniert, und dann trifft ein echter User einen Pfad, den die KI nicht modelliert hat, und das Ganze kollabiert auf interessante Weise.
Dieser Post handelt von dieser spezifischen Bug-Klasse — was sie von traditionellen Bugs unterscheidet, warum dein Test-Suite sie wahrscheinlich nicht abfängt, und wie Crowd-Testing die Lücke besser füllt als bei handgeschriebenem Code.
Die Bug-Klasse, die KI-Code konsistent produziert
Nachdem man genug KI-gebaute Apps in Beta gesehen hat, entsteht ein Muster. Die Bugs clustern sich um Vertrauensgrenzen — die Stellen im Code, an denen eine Komponente Daten oder Kontrolle an eine andere übergibt:
- Auth-Tokens, die gültig aussehen aber auf eine Session verweisen, die vor 5 Minuten rotiert wurde
- Validatoren, die
nullablehnen aberundefinedakzeptieren (oder umgekehrt), weil die KI geraten hat, welches relevant war - Error-Handler, die
Exceptionfangen, wenn sie einen spezifischeren Typ fangen sollten — und damit echte Bugs stillschweigend verschlucken - Navigation, die auf den richtigen Screen zurückkehrt aber den State verliert, der mitwandern sollte
- API-Verträge, die die KI basierend darauf geschrieben hat, was die Docs wahrscheinlich sagen — nicht was die API tatsächlich zurückgibt
Das sind keine Syntax-Fehler. Der Code kompiliert, läuft, sieht im Review richtig aus. Die Bugs tauchen erst auf, wenn echte Bedingungen das unvollständige Mental-Modell der KI schneiden. Und hier kommt der Knaller: Die Tests der KI fangen sie auch nicht ein, weil die KI Code und Tests aus dem gleichen fehlerhaften Mental-Modell geschrieben hat.
Warum dein Test-Suite dir falsches Vertrauen gibt
Wenn du Cursor oder Claude Code Tests zusammen mit dem Code generieren lässt, hast du fast garantiert ≥80 % Code-Coverage. Dein CI ist grün. Du fühlst dich sicher.
Solltest du nicht.
KI-generierte Tests decken den Happy-Path ab, weil die KI den Happy-Path gut genug verstanden hat, um den Code zu schreiben. Sie decken offensichtliche Failure-Modes ab, weil die KI an sie gedacht hat. Aber die Bugs, die in Produktion landen, kommen aus den Failure-Modes, an die die KI nicht gedacht hat — und definitionsgemäß sind das die, für die die KI keine Tests geschrieben hat.
Das ist kein Modell-Fehler. Es ist eine strukturelle Eigenschaft. Das gleiche Gehirn, das den Code geschrieben hat, hat die Tests geschrieben. Die Blind-Spots korrelieren.
Drei Dinge, die wirklich helfen
1. Cross-Model-Review
Lass eine andere KI den Code reviewen. Nicht das gleiche Modell. Ein anderes.
Claude reviewt Cursor-Output und fängt Dinge ein, die Cursor verpasst hat, weil die Modelle unterschiedliche Trainings-Daten, unterschiedliche Priors, unterschiedliche Muster haben, in denen sie selbstsicher sind. Ein 10-Minuten-Cross-Model-Pass über ein frisches Feature fängt ~30 % der Issues ein, die sonst geliefert worden wären.
Same-Model-Review (Claude reviewt Claude-Output) fängt fast nichts. Die Blind-Spots überlappen perfekt.
2. Adversariale Test-Prompts
Lass die KI Tests adversarial schreiben. Konkret:
“Schreib Tests, die einen Junior-Entwickler erwischen würden, der die Auth-Logik fast richtig hat. Fokus auf die Fälle, wo es richtig aussieht aber falsch ist.”
Das verschiebt die KI von “teste den Happy-Path” zu “stell dir eine falsche Implementierung vor und schreib Tests, die sie aufdecken würden”. Die Tests, die sie unter diesem Prompt schreibt, fangen eine messbar andere Bug-Klasse ein als die Default-Prompt-Tests.
3. Menschliche Tester auf echten Geräten
Das ist der Teil, den man nicht wegautomatisieren kann. Echte menschliche Tester auf echten Geräten schneiden deinen Code mit Bedingungen, die die KI nicht modellieren konnte:
- Netzwerk-Drops mitten in einem Request
- Background-App-Suspension im falschen Moment
- Berechtigungen nach erstem Grant verweigert
- iOS-Tastatur nimmt auf einem iPhone SE 60 % des Bildschirms ein
- Ein User mit aktiviertem VoiceOver
- Ein User dessen Locale
de-DEist und Dezimal-Trenner Kommas sind
Die KI weiß nichts von dem speziellen Pixel 6a deines Testers mit 2GB freiem RAM, und sie kann das Timing einer Notification, die exakt während eines Screen-Übergangs ankommt, nicht simulieren. Crowd-Testing auf echter Hardware ist der einzige verlässliche Weg, diese aufzudecken.
Was du in einer KI-gebauten App speziell crowd-testen solltest
Generische Crowd-Testing-Aufgaben (“probier die App”) geben generische Findings (“nettes UI”). Deine Test-Aufgaben müssen speziell die Nähte überqueren, an denen die KI schlecht ist. Ein nützliches Tasking-Muster für Vibe-Coding-Apps:
| Task-Typ | Was er einfängt |
|---|---|
| ”Anmelden, App schließen, nach 24h öffnen, Aktion X” | Session-Persistenz + Token-Rotations-Bugs |
| ”App im Flugmodus benutzen, dann wieder online” | Offline-State + Sync-Edge-Cases |
| ”Schnell durchs Onboarding tappen ohne lesen” | Race-Conditions die die KI nicht modelliert hat |
| ”Notification triggern, dann App sofort backgrounden” | Lifecycle-Bugs auf OS-Ebenen-Übergängen |
| ”Gerätesprache auf Deutsch, App neu starten” | i18n-/Locale-Bugs |
| ”App auf dem billigsten Android-Phone das du hast” | Memory- + Performance-Edge-Cases |
Das sind die Aufgaben, die die Blind-Spots der KI aufdecken. Es sind auch Aufgaben, die kein KI-Test-Suite von alleine generieren würde — weil die KI nicht weiß, dass das interessante Failure-Modes für die App sind, die sie gerade geschrieben hat.
Die ehrliche Preisrechnung für KI-gebaute Indie-Apps
Eine typische KI-gecodete Indie-App von einem einzelnen Dev:
- 30–50 Features
- Gebaut in 2-6 Wochen
- 0 € dediziertes QA-Budget
Fürs Testing hast du folgende Optionen:
| Option | Kosten | Fängt KI-Naht-Bugs? |
|---|---|---|
| Vertrau auf KI-generierte Tests | 0 € | Meistens nein |
| Cross-Model-KI-Review | 0–20 € (API-Kosten) | ~30 % davon |
| Freunde + Familie Beta | 0 € + Social-Capital | Zufall, ad-hoc |
| Crowd-Testing-Plattform | 50–300 € pro Kampagne | Ja, die Bedingungen die du speziell nicht simulieren kannst |
Die Crowd-Testing-Zeile ist die einzige, die dir wirklich etwas verkauft, was die KI nicht liefern kann. 100 € für 10 echte Tester auf echten Geräten fängt die Bugs ein, die sonst deine ersten 100 echten User treffen würden.
Wenn die KI die App gebaut hat — wer sollte sie crowd-testen?
Der richtige Tester-Pool für eine KI-gebaute Indie-App:
- Nicht-technische User (Tester die nicht wissen, was TestFlight ist) fangen die UX-Bugs ein, die die KI durchgelassen hat
- Diverse Geräte — das “läuft auf meinem Rechner” der KI ist dein Test-Simulator. Echte Geräte über iOS + Android + verschiedene Größen/Alter verteilt fangen die Bugs ein, die sich auf dem M4-Mac des Devs verstecken
- Real-World-Tasks — nicht “App öffnen und rumtappen”, sondern spezifische Aufgaben, die deine echten User machen würden
TesterPayKit ist speziell für diese Kohorte gebaut. Wenn du mit Cursor, Claude Code oder Lovable ausgeliefert hast und in 48 Stunden Real-Tester-Signal brauchst, ist das der Pfad mit der geringsten Reibung. 0 € zum Start, Pay-per-Tester.
Teil von TesterPayKits Crowd-Testing-Serie. Der Pillar: Was ist Crowd-Testing?. Verwandt: Beta-Tester für deine Flutter-App finden.