KI-Slop im App Store: Was Vibe Coding mit der Softwarequalität wirklich macht

Apple hat in den letzten Monaten still und leise begonnen, eine bestimmte Kategorie von Apps aus dem App Store herauszuhalten. Keine große Ankündigung, kein offizielles Memo — nur Entwickler, die plötzlich keine Updates mehr einreichen konnten. Der Grund: Diese Apps sind mit sogenannten Vibe-Coding-Tools gebaut worden, und Apple ist damit nicht mehr einverstanden.

Gleichzeitig stiegen die App-Store-Einreichungen laut einem Bericht von Winbuzzer (April 2026) innerhalb eines einzigen Quartals um 84 Prozent. Wer Ursache und Wirkung zusammenführt, bekommt ein klares Bild: Vibe Coding flutet den App Store mit Masse, und Apple zieht die Bremse. Das Qualitätsproblem dahinter ist aber größer als ein Plattform-Streit zwischen Apple und Drittanbietern.

Was ist Vibe Coding — und warum ist es in aller Munde?

Den Begriff hat Andrej Karpathy geprägt: Einfach beschreiben, was man haben möchte, das Modell schreibt den Code, man akzeptiert alles und schaut, ob es funktioniert. Kein tiefes Verständnis nötig, kein Review, kein Durchdenken der Architektur. Der “Vibe” zählt, nicht das Handwerk.

Tools wie Replit, Cursor, Lovable oder Bolt haben das Versprechen weitergetrieben: Wer keine Programmierkenntnisse hat, kann trotzdem in wenigen Stunden eine lauffähige App bauen und sie direkt in den App Store einreichen. Für Nicht-Entwickler ist das verlockend. Für die Ökosystem-Qualität ist es ein Problem.

Das liegt nicht daran, dass KI grundsätzlich schlechten Code schreibt. Es liegt daran, dass der Prozess rund um Vibe Coding strukturell alle Qualitätssicherung ausblendet: kein Code-Review, keine Sicherheitsüberprüfung, kein Verständnis dafür, warum eine Lösung so aussieht wie sie aussieht.

Die Zahlen hinter dem Qualitätsverlust

Die eindrücklichsten Zahlen kommen aus einer Sicherheitsstudie von Tenzai (Dezember 2025), die von der DEV Community ausführlich dokumentiert wurde: Fünf bekannte Vibe-Coding-Tools wurden jeweils verwendet, um drei identische Testanwendungen zu bauen — zusammen 15 Apps. Das Ergebnis: 69 Sicherheitslücken, davon sechs kritisch.

Kritisch bedeutet hier: Ein Angreifer kann die Datenbank auslesen, Sessions kapern oder Privilege Escalation betreiben. Das Bemerkenswerte daran ist nicht die Anzahl, sondern die Art der Lücken. Es sind keine exotischen Zero-Days. Es sind klassische OWASP-Top-10-Probleme — SQL Injection, fehlende Eingabevalidierung, Hardcoded Secrets, Broken Authentication. Der Code, den jeder Junior-Entwickler im Review sofort sehen würde.

Die Plattform Escape hat das noch größer angelegt: Über 5.600 öffentlich verfügbare Anwendungen wurden analysiert und mehr als 2.000 Sicherheitslücken, über 400 exponierte Secrets und 175 Fälle von offengelegten Personendaten (inklusive Krankenakten, IBANs und Telefonnummern) identifiziert.

Dazu kommen Codequalitätskennzahlen, die ebenfalls zu denken geben: Vibe-gecodeede Projekte weisen laut demselben Bericht eine Code-Churn-Rate von 41 Prozent auf — der Anteil des Codes, der kurz nach dem Schreiben wieder umgeschrieben wird. In einem gesunden Projekt liegt diese Rate bei 15 bis 20 Prozent. Bei 41 Prozent arbeitet das System gegen sich selbst: Der Großteil der Energie fließt nicht in neue Features, sondern ins Reparieren des Bestehenden.

Eine separate Analyse zeigte, dass KI-mitgenerierter Code im Schnitt 1,7-mal mehr schwerwiegende Issues aufweist als handgeschriebener Code, mit 75 Prozent mehr Fehlkonfigurationen und 2,74-mal so vielen Sicherheitslücken.

Warum Apple die Bremse zieht

Apples offizieller Grund ist technischer Natur: Viele Vibe-Coding-Plattformen erlauben es Apps, nach ihrer Einreichung Code nachzuladen oder ihre eigene Funktionalität zu verändern — was gegen die App-Store-Richtlinien verstößt. Die Review-Pipeline soll bewerten, was ausgeliefert wird, nicht was das Programm sich im Nachhinein selbst beibringt.

MacRumors berichtete im März 2026, dass Replit und Vibecode keine Updates mehr einreichen konnten, ohne Änderungen vorzunehmen. Am 30. März 2026 entfernte Apple die App “Anything” des Vibe-Coding-Anbieters vollständig aus dem Store. 9to5Mac dokumentierte, dass Blockaden für einzelne Apps bereits seit Dezember 2025 aktiv waren — Apple hatte nur lange geschwiegen.

Der operative Druck dürfte die Entscheidung beschleunigt haben: Die Review-Zeiten stiegen von historisch 24 bis 48 Stunden auf 7 bis 30 Tage. Ein 84-prozentiger Einreichungsanstieg schlägt sich eben direkt in den Bearbeitungsqueues nieder. Apple kämpft gleichzeitig mit der Überlastung des Systems und dem inhaltlichen Qualitätsproblem.

Das ist kein isoliertes Apple-Problem. Die Dynamik ist dieselbe wie anderswo: Wenn die Eintrittshürde sinkt, steigt die Masse — und die Qualitätssicherung wird zum Flaschenhals. Das betrifft NPM-Pakete genauso wie GitHub-Repositories. Das Vibe-Coding-Phänomen macht es nur sichtbarer, weil ein Plattformbetreiber wie Apple eine klare Gating-Funktion hat.

Was schlechten KI-Code von gutem unterscheidet — und wie man es besser macht

Die eigentliche Frage ist nicht, ob KI-generierter Code grundsätzlich schlecht ist. Die Frage ist, unter welchen Bedingungen er gut genug wird, um produktiv eingesetzt zu werden.

Das Kernproblem beim Vibe Coding ist fehlendes Kontext-Management im Prompt. Wer einem Modell sagt “Bau mir eine Login-App”, bekommt eine Login-App — ohne Sanitization, ohne Rate Limiting, ohne CSRF-Schutz, weil niemand diese Anforderungen explizit gestellt hat. Der Code ist funktional. Er ist nur nicht produktionsreif.

Das Gegenteil davon ist kein kompliziertes Framework, sondern ein strukturierter Prompt:

Erstelle eine Login-API in Node.js/Express mit folgenden Anforderungen:
- Eingabevalidierung und Sanitization für alle Felder
- Rate Limiting: max. 5 Versuche pro IP und 15 Minuten
- Passwort-Hashing mit bcrypt (min. 12 Rounds)
- CSRF-Schutz für alle Endpunkte
- Keine Rückgabe von Fehlermeldungen, die Enumeration erlauben
  ("Ungültige Zugangsdaten", nicht "Passwort falsch")
- Logs für fehlgeschlagene Anmeldeversuche (ohne Passwort-Wert)
- Kein Secret in der Antwort, kein Debug-Output in Production

Das ist kein Aufwand, der KI-Tools schlechter macht — es ist der Aufwand, den ein erfahrener Entwickler in jede Implementierung steckt, egal ob mit oder ohne KI. Der Unterschied ist: Beim Vibe Coding entfällt genau dieser Teil, weil die Zielgruppe oft nicht weiß, was sie nicht fragen soll.

Eine ähnliche Logik gilt für Code Review. Der sinnvolle Einsatz von KI ist nicht, das Review zu überspringen, sondern es anders aufzuteilen: Modell schreibt, Entwickler reviewt — mit dem expliziten Fokus auf Sicherheit und Kanten­fälle, nicht auf die Syntax. Wer KI-generierten Code wie eigenen Code behandelt und denselben Review-Prozess durchlaufen lässt, behebt den Großteil der Qualitätsprobleme.

Das Thema hat auch eine Open-Source-Dimension: Ähnliche Qualitätsbedenken bewegen inzwischen Maintainer-Communities dazu, KI-generierten Code grundsätzlich aus Beiträgen auszuschließen. Wie OpenJDK das handhabt — und was dieser Trend für die Open-Source-Welt bedeutet — habe ich heute in einem separaten Post beschrieben: OpenJDK sperrt KI-generierten Code aus.

Meine Einschätzung: Kein Werkzeugproblem, sondern ein Processproblem

Ich nutze KI-Coding-Tools täglich. Ich halte Vibe Coding trotzdem für eine problematische Entwicklung — nicht wegen der Tools, sondern wegen der Botschaft, die sie senden: dass Prozess und Handwerk optional sind.

Die 69 Sicherheitslücken in 15 Apps sind kein Versagen der Modelle. Die Modelle haben genau das gebaut, was man von ihnen wollte: schnell, funktional, ohne Friction. Das Versagen liegt im Weglassen des nächsten Schritts — des Verständnisses, des Reviews, der Verantwortung für das, was man ausliefert.

Fortune formulierte es im April 2026 treffend: Im Zeitalter des Vibe Codings ist Vertrauen der eigentliche Engpass. Nicht die Geschwindigkeit, nicht die Kosten — sondern die Frage, ob das, was aus einem Prompt entsteht, tatsächlich so funktioniert wie beabsichtigt, und ob die Person, die auf “Deploy” drückt, das überhaupt beurteilen kann.

Für professionelle Entwickler ändert das nichts an der Nutzung von KI-Tools, solange man weiß, was man tut. Für Plattformen wie den App Store bedeutet es, dass die Qualitätssicherung nicht verschwinden, sondern wandern muss — vom Plattformbetreiber zurück zu denen, die die Tools einsetzen.

Ob das passiert, ist eine andere Frage. Solange der Marktanreiz “App in zwei Stunden statt zwei Wochen” lautet, wird der Vibe wichtiger sein als das Handwerk. Zumindest bis die erste ernsthafte Sicherheitslücke in einer vibe-gecodeeten App die großen Schlagzeilen macht.

---

Quellen:

• Winbuzzer: Apple Cracks Down as Vibe Coding Drives 84% App Store Submissions Surge
• MacRumors: Apple Quietly Blocks Updates for Popular ‘Vibe Coding’ Apps
• 9to5Mac: Apple pushing back on ‘vibe coding’ iPhone apps
• DEV Community: 69 Vulnerabilities in 15 Apps — The Vibe Coding Security Reckoning Is Real
• Escape.tech: Methodology — 2k+ Vulnerabilities in Vibe-Coded Apps
• Fortune: In the age of vibe coding, trust is the real bottleneck
• HowToGeek: AI Slop / Vibe Coding Could Destroy Open Source Software Forever