Wenn KI die Entwicklung beschleunigt, wird „fertig“ schnell zur gefährlichsten Illusion
Mit KI kann aus einer Multiplayer-Idee erstaunlich schnell eine funktionierende App werden. Raum anlegen, beitreten, posten, abstimmen: alles geht. Das Gehirn meldet sofort:
Fertig.
Der Server antwortet:
Du hast mit einer Person getestet.
Die wichtigen Fragen kommen danach. Was passiert bei 100 gleichzeitigen Aktionen? Was, wenn der Datenbank-Write erfolgreich war, aber die Erfolgsantwort verloren geht? Was, wenn die letzte Stimme genau zur Deadline kommt? Was, wenn ein Zahlungsereignis zweimal eintrifft? Was, wenn sich nach einer Störung alle gleichzeitig wieder verbinden?
Bei einem Code-Review einer kleinen Multiplayer-Web-App wuchs der Testplan auf 324 Fälle. Das heißt nicht, dass 324 Bugs gefunden wurden. Alle 324 Punkte waren noch nicht ausgeführt. Es war ein Prüfplan, kein Gütesiegel.
1. DDoS ist nicht die einzige Art, eine App zu überlasten
Cloudflare bietet automatische DDoS-Erkennung und -Abwehr in allen Tarifen. Gleichzeitig empfiehlt Cloudflare zusätzliche Schutzmaßnahmen auf Anwendungsebene wie Rate Limiting, weil große Angriffe die Anwendung trotzdem beeinträchtigen können.[1]
Bei einem kleinen Projekt kann legitimer Verkehr das erste echte Lastproblem sein.
Bei Statusabfragen alle drei Sekunden:
| Gleichzeitige Geräte | Statusabfragen pro Stunde |
|---|---|
| 10 | 12.000 |
| 30 | 36.000 |
| 100 | 120.000 |
| 1.000 | 1.200.000 |
Das ist keine echte Kapazitätsprognose. Backoff und Caching können reduzieren; Posts, Bilder, Inbox, mehrere Tabs und geplante Jobs können erhöhen.
Am 5. Oktober 2026 nennt Workers Free 100.000 Requests pro Tag. D1 Free nennt 5 Millionen gelesene Zeilen pro Tag, 100.000 geschriebene Zeilen, 500 MB pro Datenbank und 50 Queries pro Worker-Aufruf.[2][3] Eine einzelne D1-Datenbank verarbeitet Queries nacheinander; zu viel Parallelität erzeugt Warteschlangen und kann schließlich Overload-Fehler verursachen.[3]
Nicht nur „eine Million Angreifer“ sind also gefährlich.
Hundert echte Nutzer, die gleichzeitig Spaß haben, können bereits ein Lasttest sein.
2. Warum daraus 324 Tests wurden
Die 16 Bereiche: Einstieg und Missbrauch, Kapazität, Parallelität und Wiederherstellung, geplante Jobs, Räume und Rechte, Bilder, Texteingabe, Abstimmung, Deadlines, Ergebnisfreigabe, öffentliche Räume, dauerhafte Verbindungen, Geräte und Reconnect, Integrationen, Zahlungen sowie Deployment und Monitoring.
Entscheidend ist die Priorisierung.
3. Diese 23 Punkte würde ich zuerst angreifen
- Erzeugen abgewiesene Requests trotzdem teure DB-Arbeit?
- Erfasst der eigene Usage-Zähler wirklich alle teuren Pfade?
- Überlebt Rate Limiting Neustarts und mehrere Instanzen?
- Liest „nichts geändert“ trotzdem viel aus der DB?
- Kann ein Sitz unbegrenzt dauerhafte Verbindungen öffnen?
- Gelten für HTTP und dauerhafte Verbindungen dieselben Grenzen?
- Stoppt ein Not-Aus auch bereits verbundene Clients?
- Lassen verspätete Scheduler Aktionen nach der Deadline durch?
- Kann ein Nebeneffekt fehlschlagen, während der Raum weiterläuft?
- Kann eine Reparatur Statistiken doppelt zählen?
- Kann eine Startreserve verbraucht werden, bevor das Spiel existiert?
- Kann ein Retry aus einer Antwort zwei machen?
- Umgehen optisch ähnliche Namen die Eindeutigkeit?
- Können zwei Nutzer gleichzeitig den letzten Platz bekommen?
- Können geplante Jobs mehr Arbeit ansammeln als sie verarbeiten?
- Werden gesamte DB und Indizes gemessen, nicht nur Bilder?
- Kann jemand eine verlorene Geräteidentität übernehmen?
- Werden Bildtyp, Abmessungen, Metadaten und Standortdaten sicher behandelt?
- Macht eine lange Historie jeden Seitenaufruf teurer?
- Können synchrone Reconnects einen zweiten Ausfall auslösen?
- Wurden doppelte, verspätete, fehlgeschlagene, stornierte und wiederhergestellte Zahlungen getestet?
- Wird lokales Bestehen mit Produktionssicherheit verwechselt?
- Fällt beim DB-Ausfall auch das Monitoring aus?
4. Bugs mögen Kombinationen
Ein wertvolles Szenario:
100 Nutzer stimmen ab → 20 laden neu → 10 verlieren die Verbindung → einige Writes gelingen, aber die Antwort geht verloren → Retry.
Dann prüft man doppelte Stimmen, verspätete Stimmen, Rücksprünge zu altem Zustand und doppelt ausgeführte Aktionen.
OWASP behandelt parallele Sessions, ungewöhnliche Eingaben und Fehlerbehandlung ebenfalls als eigene Testbereiche.[4]
5. „Gespeichert“ und „Erfolg beim Nutzer angekommen“ sind zwei Ereignisse
Der Server kann erfolgreich speichern, während die Netzwerkantwort verschwindet.
Der Nutzer sieht einen Fehler und klickt erneut.
Ohne Operations-ID oder andere Deduplizierung entstehen möglicherweise zwei Antworten, zwei Räume, zwei Stimmen, zwei Benachrichtigungen oder zwei Abbuchungen.
Retries müssen entworfen werden.
6. Lasttests stufenweise erhöhen
In einer kontrollierten Umgebung: 10 → 30 → 100 Clients.
Dann die Form ändern: ein voller Raum, viele Räume, gleichzeitige Joins, gleichzeitige letzte Abstimmungen, Massen-Reconnect, geplante Jobs und simulierte Storage-Ausfälle.
Keine absichtlich hohe Last auf fremde oder nicht autorisierte Systeme schicken. Budget und Abbruchkriterien vorher festlegen.
7. „Nicht abgestürzt“ ist noch kein Bestehen
Ein Startziel könnte sein: 95 % normaler Requests unter einer Sekunde, 99 % unter drei Sekunden und weniger als 0,1 % unerwartete 5xx-Fehler.
Diese Dinge sollten dagegen null sein:
- fremde Daten sichtbar;
- Aktion ohne Berechtigung;
- doppelte Wertung;
- bestätigte Daten verloren;
- doppelte Zahlung.
8. Testdesign 9/10, ausgeführte Evidenz 0/10
324 Fälle und 23 priorisierte Risiken können ein sehr gutes Design sein.
Vor der Ausführung bleibt die Beweislage trotzdem null.
Das ist kein Scheitern. Das Projekt ist von „wir wissen nicht, was wir prüfen sollen“ zu „wir wissen genau, wo wir versuchen müssen, es kaputtzumachen“ gekommen.
9. Danach kann zuerst das KI-Wochenlimit sterben
Wer einen ganzen Tag lang eine KI große Repositories lesen, implementieren, korrigieren, reviewen und wieder implementieren lässt, kann das KI-Kontingent vor dem Server erschöpfen.
Am 5. Oktober 2026 kostet Claude Max 20x im Web 200 US-Dollar pro Monat. „20x“ beschreibt die Kapazität pro Session relativ zu Pro. Session-Limits werden alle fünf Stunden zurückgesetzt; zusätzlich gibt es ein modellübergreifendes Wochenlimit.[5]
20x bedeutet also nicht unendlich.
Der tatsächliche Verbrauch hängt von Modell, Kontext und Aufgabe ab. Settings > Usage ist die praktische Quelle.
10. „Fable ist teuer“ passt auch zu den Zahlen
Bei Max gehören Fable 5 und 5.1 dazu, aber Fable kann bis zu 50 % des Wochenlimits verwenden, und Anthropic weist darauf hin, dass Fable das Kontingent schneller verbraucht als andere Claude-Modelle.[6]
| Modell | Input / 1 Mio. Token | Output / 1 Mio. Token |
|---|---|---|
| Sonnet 5.5 | $2 | $10 |
| Opus 5.5 | $4 | $20 |
| Fable 5.1 | $10 | $50 |
Fable 5.1 kostet bei Input und Output jeweils das 2,5-Fache von Opus 5.5. Günstigere Cache Reads senken die Kosten gegenüber Fable 5, aber der absolute Preis bleibt hoch.[6][7][8]
API-Preise lassen sich nicht direkt in Max-Wochenminuten umrechnen. Die Richtung bleibt jedoch: das schwerste Modell viele Stunden lang laufen zu lassen ist teuer.
11. Für jede Schraube braucht man keinen Kran
Sonnet 5.5: Routinefixes, bekannte Bugs, wiederholte Änderungen, klar abgegrenzte Implementierung.
Opus 5.5: unbekannte Ursache, Architekturänderung, Review über viele Dateien, wichtige Entscheidung vor Release.
Fable 5.1: besonders schwierige Aufgaben, bei denen zusätzliche Fähigkeit den höheren Preis oder Kontingentverbrauch rechtfertigt.
Das ist kein Modell-Ranking. Es ist Kostensteuerung pro Aufgabe.
12. KI beseitigt Engpässe nicht, sie verschiebt sie
Früher: Idee → Wochen Entwicklung → Test.
Heute: Idee → schnelle Umsetzung → Test, Betrieb, Serverlimits und KI-Limits kommen gleichzeitig.
„Ich habe die App an einem Tag gebaut“ kann stimmen.
Präziser ist:
„In einem Tag war ich an dem Punkt, an dem ich endlich ernsthaft versuchen konnte, sie kaputtzumachen.“
Dort beginnt die eigentliche Vorbereitung auf den Produktivbetrieb.
Quellen (8)
- Cloudflare DDoS developers.cloudflare.com
- Cloudflare Workers developers.cloudflare.com
- Cloudflare D1 developers.cloudflare.com
- OWASP WSTG wstg.owasp.org
- Anthropic Max support.claude.com
- Anthropic Fable support.claude.com
- Opus 5.5 anthropic.com
- Sonnet 5.5 anthropic.com
