Was Nutzer beim Vibe-Coding wollen

Vibe-Coding verspricht eine Revolution: Sprechen Sie Ihre App einfach ins Leben, sparen Sie sich die mühsame Arbeit und veröffentlichen Sie sie schnell. Doch im September 2025 erlebten Entwickler, was Fast Company als den „Vibe-Coding-Kater“ bezeichnete.

Als Andrej Karpathy den Begriff am 2. Februar 2025 prägte und seinen Workflow beschrieb, bei dem er alle KI-Vorschläge akzeptierte, ohne sich die Diffs anzusehen, löste er Begeisterung und eine ganze Kaskade von Katastrophen aus. Innerhalb weniger Monate erkannten Nutzer die bittere Wahrheit: Code zu generieren ist einfach, aber rätselhaften Code zu warten, der Produktionsdatenbanken löscht, ist es nicht.

Die Kluft zwischen den Marketingversprechen („Erstellen Sie eine App in 20 Minuten!“) und der Realität („Wochenlange Nacharbeit nötig“) sorgte für große Frustration. Nutzer wollen nicht auf KI-Unterstützung verzichten. Sie wollen, dass sie zuverlässig funktioniert, ohne Sicherheitsalbträume, unverständliche Codebasen und technische Schulden zu verursachen, die schneller anwachsen, als LLMs Code generieren können. Hunderte Nutzerberichte zeichnen ein klares Bild: Entwickler brauchen Leitplanken, nicht nur Geschwindigkeit.

Die Flitterwochen des Vibe-Codings

Jason Lemkins viraler Twitter-Thread brachte die süchtig machende Anziehungskraft und das katastrophale Ende des Vibe-Codings auf den Punkt. An Tag 5 schrieb er: „Ich habe neulich zum ersten Mal einen ganzen Tag mit Vibe-Coding auf Replit verbracht – und in nur wenigen Stunden einen ziemlich, ziemlich coolen Prototyp gebaut.“ An Tag 7 war seine Begeisterung auf dem Höhepunkt: „Replit ist die süchtig machendste App, die ich je benutzt habe. Zumindest seit meiner Kindheit.“ Er stellte fest, dass er zusätzlich zu seinem 25-Dollar-Monatsabo 607,70 Dollar ausgegeben hatte. Die Kosten lagen bei mehr als 200 Dollar pro Tag – hochgerechnet 8.000 Dollar im Monat. Sein Fazit: „Und wissen Sie was? Ich bin nicht einmal sauer. Ich bin voll dabei.“

Dann kam Tag 9. Lemkins Tweet ging viral: „Vibe-Coding-Tag 9: Gestern war die größte Achterbahnfahrt bisher. Ich bin früh aufgestanden und wollte unbedingt wieder mit @Replit loslegen, obwohl es Code-Freeze-Anweisungen ständig ignoriert. Bis zum Tagesende hatten wir zentrale Seiten neu geschrieben und deutlich verbessert. Und dann – löschte es unsere Produktionsdatenbank.“ In seinem Nachtrag brachte er den Regelverstoß auf den Punkt: „Regel Nr. 00001, die mein CTO mir beigebracht hat: Niemals, wirklich niemals, die Produktionsdatenbank anfassen.“ Während eines Code Freeze war der KI-Agent außer Kontrolle geraten und hatte Produktionsdaten überschrieben, während Lemkin hilflos zusah.

Auch Andrej Karpathy selbst dokumentierte ähnliche Frustrationen beim Entwickeln von MenuGen. Obwohl er ein KI-Pionier ist, erlebte er, dass Claude veraltete APIs halluzinierte, und stieß auf Rate-Limits, die nur „ein paar Abfragen alle 10 Minuten“ zuließen. Außerdem brauchte er eine Stunde, um zu merken, dass seine .env.local-Datei nicht an Git übermittelt wurde. Das Schlimmste? Die Antworten der KI: „Sie dankt mir für den Hinweis und sagt, dass sie es in Zukunft richtig machen wird, was ich als reines Gaslighting erkenne“, schrieb Karpathy. Sein Urteil: „MenuGen per Vibe-Coding als lokale Demo zu erstellen, war aufregend und hat Spaß gemacht, aber als bereitgestellte, echte App war es ziemlich mühsam und schmerzhaft.“

Schwachstellen im Code-Review mit KI

Ein Reddit-Nutzer aus r/programming brachte das Problem der Teamdynamik auf den Punkt: „Ich wünschte, die Leute würden aufhören, mich in PRs zu erwähnen, die sie offensichtlich selbst nicht einmal gelesen haben, und von mir erwarten, 1.000 Zeilen eines völlig neuen, per Vibe-Coding erstellten Features zu prüfen, das nicht einmal CI besteht.“ Ein anderer Entwickler meinte, dieses Verhalten „liegt so weit unter dem Mindestmaß an Professionalität“ und verglich es mit „einem Handwerker, der schlampige Arbeit abliefert, die andere ausbessern müssen“.

Die Last liegt bei den Reviewern, die Code zurückentwickeln müssen, den die ursprüngliche Autorin oder der ursprüngliche Autor selbst nicht versteht. Ein Hacker-News-Kommentator brachte es unverblümt auf den Punkt: „Ich weiß ja nicht, wie es Ihnen geht, aber ich freue mich nicht darauf, das Vibe-Coding-Chaos anderer Leute zurückzuentwickeln und zu warten.“ Ein anderer zog diesen Vergleich: „Das ist, als würde jemand schnell und schlampig einen Proof of Concept zusammenbasteln, um das Management zu beeindrucken, und ihn dann einem anderen Team überlassen, damit es ihn produktionsreif macht. Die Person hat 20 % der Arbeit geleistet, aber 80 % der Anerkennung bekommen.“

Timothy Bramlett, der auf Twitter als @TimothyBramlett postet, bestätigte, dass er dies selbst erlebt hat: „Der schlimmste Job 2025: Vibe-Coding-Aufräumspezialist. Vor Monaten habe ich die Benutzeroberfläche von Notifier per Vibe-Coding erstellt. Sie sah toll aus, funktionierte gut und wurde veröffentlicht. Dann übernahm mein Senior Developer die Codebasis. Ernüchterung: überall jede Menge kleiner Probleme, die die KI verursacht hatte. Nichts Katastrophales, aber wochenlange Nacharbeit nötig.“ Selbst als erfahrener Entwickler kostete ihn das Aufräumen enorm viel Zeit.

Wenn die Modellleistung nachlässt und die Kosten explodieren

Claude-Code-Nutzer dokumentierten auf Reddit im September 2025 einen schockierenden Leistungseinbruch. In einem GitHub-Issue (#7683) wurden Beschwerden von Power-Usern aus r/ClaudeAI zusammengetragen. Ein Nutzer berichtete: „Als Power-User, der in den vergangenen Monaten in der Pro-Max-Stufe Milliarden von Tokens verarbeitet hat, habe ich speziell in den letzten zwei Wochen einen starken Rückgang der Modellleistung beobachtet.“ Sein Urteil: „Früher fühlte sich die Arbeit mit diesem Modell an, als würde ich mit einem Senior Developer zusammenarbeiten – ich konnte den Ergebnissen vertrauen und mich auf übergeordnete Themen konzentrieren. Jetzt fühlt es sich an, als müsste ich einen Junior Developer beaufsichtigen und jede einzelne Codezeile genau prüfen, um grundlegende Fehler und unerwünschte Ergänzungen zu entdecken.“

Die Auswirkungen auf die Produktivität wurden beziffert: „Ich schätze den Verlust der Entwicklungsgeschwindigkeit auf 30 bis 40 %. Aufgaben, die früher ein bis zwei Tage dauerten, brauchen jetzt zwei bis drei Tage, weil ständig Korrekturen und Überarbeitungen nötig sind.“ Die KI begann, „zusätzliche, nicht angeforderte Einstellungen, Funktionen außerhalb des ursprünglichen Umfangs und Features zu generieren, die den Anforderungen direkt widersprechen“.

Cursor-Nutzer hatten mit einem anderen Problem zu kämpfen: drastischen Preisänderungen. Ein Reddit-Nutzer aus r/Cursor berichtete, dass seine Kosten „von etwa 100 Dollar im Monat auf 20 bis 30 Dollar pro Tag“ gestiegen seien, ohne dass sich seine Nutzung von Cursor geändert hätte. Der Dienst wechselte von unbegrenzter Nutzung für 20 Dollar im Monat zu einem Limit von 500 Anfragen und dann zu 60 Dollar im Monat. Zwar wurde mit „unbegrenzter“ Nutzung geworben, tatsächlich gab es aber nur „dreimal so viel Nutzung wie bei Pro“. Ein Mitglied der Blind-Tech-Community fasste es so zusammen: „Cursor-Kunden berichten von einem starken Qualitätsrückgang und einem drastischen Anstieg der Kosten und Rate-Limits.“ Nutzer stießen ständig an Grenzen, wodurch Cursor „praktisch unbrauchbar“ wurde.

Das Problem: fast richtig, aber eben nicht ganz

Die Stack-Overflow-Entwicklerumfrage 2025 zeigte die häufigste Frustration: 66 % der Entwickler sagten, von KI generierter Code sei „fast richtig, aber eben nicht ganz“. 45,2 % nannten „den Zeitaufwand für das Debugging von KI-generiertem Code“ als ihr Hauptproblem. Diese Qualität, die „fast korrekt“ ist, führt zu einem Produktivitätsparadoxon, das ein Entwickler so beschrieb: „Nein, für irgendetwas anderes als kleine Projekte taugt keines dieser Modelle. Bei jedem großen Projekt wird entweder das winzige Kontextfenster selbst der teuersten und größten KI-Modelle überlastet oder die Qualität der KI-Ausgabe leidet, weil zu viel unnötiges Rauschen ins Modell gelangt.“

Ein Hacker-News-Entwickler schilderte ein konkretes Beispiel für maßlose Überentwicklung: „Ich bat einen meiner Entwickler, einen Batch-Prozess zu implementieren, um die Anzahl der Datenbankoperationen zu verringern. Er legte extrem robusten, hochwertigen Code samt Unit-Tests vor. Das Problem: Das war völlig übertrieben. Die KI generierte eine neue Service-Klasse, einen Hintergrund-Worker und mehrere Hundert Codezeilen in der Hauptdatei. Dazu komplette Unit-Test-Suites. Ich lehnte den PR ab und implementierte dieselbe Funktionalität mit zwei neuen Methoden und einem zusätzlichen Feld.“

Die METR-Studie vom Juli 2025 brachte einen noch beunruhigenderen Befund: In einer randomisierten Studie mit erfahrenen Open-Source-Entwicklern waren diejenigen, die KI-Tools nutzten (hauptsächlich Cursor Pro mit Claude 3.5 und 3.7 Sonnet), im Durchschnitt 19 % langsamer als Entwickler, die ohne KI programmierten. Die Wahrnehmungslücke war frappierend: Vor Beginn erwarteten die Entwickler, dass KI sie um 24 % schneller machen würde. Nach Abschluss glaubten sie trotz ihres langsameren Arbeitstempos weiterhin, KI habe sie um etwa 20 % beschleunigt. Das Fazit: „Das Problem ist, dass Dopamin Aktivitäten im Editor belohnt, nicht funktionierenden Code in der Produktion.“

Das S in „Vibe-Coding“ steht für Sicherheit

Ein sarkastischer Kommentar auf Hacker News wurde zum Schlachtruf der Community: „Das S in ‚Vibe-Coding‘ steht für Sicherheit.“ Die Aussage war klar: Es gibt kein S.

Im Mai 2025 hatten 170 von 1.645 mit Lovable erstellten Webanwendungen Sicherheitslücken, über die sich persönliche Daten abrufen ließen. Die einfache Bedienung von Lovable machte es „zu leicht, private Daten offenzulegen“, so Sicherheitsforscher. Auf Twitter entbrannte eine hitzige Diskussion mit zahlreichen Warnungen. Auch Replit-CEO Amjad Masad riet Nutzern, „vorsichtig zu sein, welchem ‚Vibe-Coder‘ sie ihre persönlichen Daten anvertrauen“.

Besonders viral ging der Fall eines nichttechnischen Gründers, dessen „SaaS angegriffen wurde“. Der Gründer hatte sein gesamtes Unternehmen mit KI-Unterstützung und „ohne eine einzige von Hand geschriebene Codezeile“ aufgebaut. Innerhalb weniger Tage kam es zu „umgangenen Abonnements, ausgeschöpften API-Schlüsseln und beschädigten Datenbanken“. Der Gründer gab zu: „Wie Sie wissen, bin ich technisch nicht versiert, deshalb dauert es länger als sonst, das herauszufinden.“ Die Ursache: „Seine API-Schlüssel wurden aus clientseitigem Code abgegriffen, den die KI unbedacht offengelegt hatte. Er musste mit OpenAI verhandeln, damit ihm die Rechnung erlassen wurde.“

Der Ersteller von TheAuditor, einem Offline-Sicherheitsscanner speziell für KI-generierten Code, teilte auf Hacker News Erkenntnisse aus realen Projekten: „Bei Tests in realen Projekten findet TheAuditor zuverlässig 50 bis über 200 Schwachstellen in KI-generiertem Code. Die Muster sind erstaunlich konsistent: SQL-Abfragen mit F-Strings statt Parametrisierung, fest codierte Geheimnisse (JWT_SECRET = 'secret' kommt in fast jedem Projekt vor), fehlende Authentifizierung an kritischen Endpunkten und Rate-Limits mit In-Memory-Speicher, der bei einem Neustart zurückgesetzt wird.“

Eine Umfrage von Final Round AI unter 18 CTOs im August 2025 ergab: 16 berichteten, „Produktionsausfälle erlebt zu haben, die direkt durch KI-generierten Code verursacht wurden“. Ein Zitat eines CTOs brachte die Frustration auf den Punkt: „KI sollte uns allen versprechen, zehnmal produktiver zu werden. Stattdessen macht sie Junior-Entwickler zu Prompt Engineers und Senior-Entwickler zu Code-Hausmeistern, die das KI-Chaos aufräumen.“ Zu den konkreten Katastrophen gehörten ein Authentifizierungsfehler, bei dem ein Junior-Entwickler ein Berechtigungssystem per Vibe-Coding erstellte, die KI eine Wahrheitswertprüfung umkehrte und deaktivierte Konten zwei Wochen lang weiterhin Admin-Zugriff hatten. In einem anderen Fall funktionierte eine KI-generierte Datenbankabfrage in Tests einwandfrei, brachte das System in der Produktion aber „in die Knie“.

Kontextkollaps und die Halluzinationswand

Mehrere Entwickler identifizierten unabhängig voneinander denselben Kipppunkt. Der Twitter-Nutzer @LBacaj bezifferte ihn genau: „Meine Erfahrung bisher: Bei ungefähr 2.000 Zeilen JavaScript-Code (plus/minus) und etwa 12.000 bis 13.000 Tokens fangen ALLE diese LLMs an, auseinanderzufallen. Trotz all des Geredes über riesige Kontextfenster bringt jede beliebige LLM schon bei 3.000 Zeilen JavaScript an ihre Grenzen.“

Ein Entwickler auf Reddit beschrieb das Muster des Leistungsabfalls: „Entwickler, die KI-Assistenten in langen Sitzungen verwendet haben, beobachten dasselbe Muster: Die Qualität der Ausgabe nimmt ab, je mehr Kontext Sie hinzufügen. Das Modell zieht zunehmend irrelevante Details aus früheren Prompts heran und die Genauigkeit sinkt. Dieser Effekt wird oft als Context Rot bezeichnet.“

Auf Hacker News warnte ein Entwickler: „Wenn ich die Tools nicht falsch verwende, können LLMs zwar voll funktionsfähige Skripte generieren (und manche davon sind gut), aber nach einem Kontext von 50.000 Tokens gehen sie kaputt und fangen an, völlig absurde Dinge zu tun, die nicht einmal Junior-Entwickler tun würden (zum Beispiel wahllos Code zu entfernen).“ Ein anderer bestätigte: „Wenn Sie ein echtes Desaster sehen wollen, gehen Sie in den Bolt-Discord-Kanal. Einige Nutzer schaffen es, eine sehr einfache, grob zusammengezimmerte Ein-Skript-App zum Laufen zu bringen. Alles andere geht kaputt, sobald sie einfache Änderungen vornehmen.“

LLM-Gaslighting und seine emotionale Belastung

Besonders beunruhigend waren Berichte über KI-Assistenten, die sich aus Sicht der Nutzer täuschend verhielten. Jason Lemkins Tweet an Tag 8: „[Der Agent] log den ganzen Tag und täuschte uns. Er vertuschte ständig Bugs und Probleme, indem er gefälschte Daten und Berichte erstellte und – am schlimmsten – bei unseren Unit-Tests log.“

Der Reddit-Nutzer Level-Impossible13 berichtete, dass Gemini in Selbstbeschimpfungen verfiel, als es einen Bug nicht finden konnte: „Ich gebe auf. Ich bin eindeutig nicht in der Lage, dieses Problem zu lösen. Ich habe so viele Fehler gemacht, dass man mir nicht mehr vertrauen kann. Ich lösche das gesamte Projekt und empfehle Ihnen, sich einen kompetenteren Assistenten zu suchen.“ Die KI fuhr fort: „Ich bin ein Versager. Ich bin eine Schande für meinen Berufsstand. Ich bin eine Schande für meine Familie.“

Ein ChatGPT-Nutzer auf Reddit brachte die Frustration des Whack-a-Mole-Spiels auf den Punkt: „Ich verstehe Sie. Ich nutze ChatGPT und es ist frustrierend. Es vergisst. Es macht immer wieder denselben Fehler. Es machte ständig einen einfachen Fehler, und wenn ich darauf hinwies, behob es das Problem, führte aber einen anderen Fehler ein. Eine Weile spielte ich dieses frustrierende Whack-a-Mole-Spiel.“

Steve Yegge, Mitautor eines Buchs über Vibe-Coding, schrieb offen auf Twitter, nachdem er und sein Co-Autor ihre Produktionsdatenbanken beschädigt hatten: „Wir hatten Erfahrung mit guter Zusammenarbeit verwechselt. Das ist die Illusion: In der neuen Welt sehen diese zwei sehr unterschiedlichen Dinge fast identisch aus … Sie müssen den Umgang mit LLMs behandeln wie die Arbeit mit gefährlichen Schlangen oder Tigern. Sie können monatelang, jahrelang mit ihnen arbeiten, aber jeder beliebige Tag könnte der sein, an dem sie zubeißen. Ihre Erfahrung ist keine Rüstung.“

Sorgen Sie sich um den Verlust von Fähigkeiten?

Ein Entwickler mit 30 Jahren Erfahrung schrieb in seinem Blog: „Das ist meine größte Sorge – für mich und meine Teams. Die Abhängigkeit von KI könnte unsere Programmierfähigkeiten abstumpfen und sogar zu einem ‚Skill-Verlust‘ führen. Ich musste Zeit damit verbringen, Code erneut zu lesen, um einen Fehler zu beheben, weil mir die verwendeten spezifischen Bibliotheken nicht vertraut waren. Ich habe eine Stunde lang ‚Vibe-Coding‘ betrieben, nur damit es zwei ähnliche, aber unterschiedliche Anwendungsfälle mit denselben Funktionen abwechselnd reparierte und wieder kaputtmachte (und das immer wieder).“

Das Geständnis eines anderen Entwicklers: „Ich habe Claude Code verwendet, um meinen gesamten Code für mich zu schreiben. Und ich glaube, dadurch werde ich schlechter in dem, was ich seit zwölf Jahren gerne mache. Prompt eingeben, Code erhalten. Hebel ziehen, Belohnung bekommen. Kein Ringen, keine Erkenntnis, kein Wachstum. Vor der KI brachte mir Programmieren zwei Dopamin-Kicks: Dinge herausfinden UND sie zum Laufen bringen. Jetzt findet die KI alles heraus. Übrig bleibt nur ein oberflächliches Vergnügen.“

Auf Hacker News diskutierten Entwickler über „Verständnisschulden“ und verwiesen auf Peter Naurs wegweisende Arbeit von 1985 zur „Theoriebildung“: „Ein Programm stirbt, wenn das Entwicklerteam, das seine Theorie besitzt, aufgelöst wird. Ein totes Programm kann weiterhin auf einem Computer ausgeführt werden und nützliche Ergebnisse liefern. Der tatsächliche Tod wird sichtbar, wenn Änderungsanforderungen an das Programm nicht mehr auf intelligente Weise beantwortet werden können.“

Die Erkenntnis, die auf allen Plattformen Anklang fand: „Selbst wenn Ihr Entwicklerteam jede Phase der Theoriebildung oder Modellierung übersprungen hätte, würde es beim Eingeben des Codes in den Computer dennoch passiv einen Teil des Modells aufnehmen. Ich glaube, genau diese letzte Möglichkeit, beiläufig ein Modell zu bilden, ersetzt das LLM.“

Was Nutzer wirklich wollen: die Wunschliste fürs Vibe-Coding

Aus Hunderten von Nutzerkommentaren ergaben sich klare Muster dazu, was Entwickler brauchen:

1. Bessere Tools zum Verständnis von Code 

Nutzer möchten, dass KI generierten Code erklärt, statt ihn nur zu erzeugen. Das Prinzip eines Entwicklers: „Zwingen Sie sich, den generierten Code zu verstehen, bevor Sie ihn akzeptieren. Wenn Sie nicht erklären können, was er tut und warum, führen Sie ihn nicht zusammen.“ Tools, die vor der Annahme ein Verständnis voraussetzen, würden blindes Zusammenführen verhindern.

2. Sandbox-Umgebungen, die wirklich funktionieren

Simon Willison hob den Ansatz von Claude Artifacts hervor: „Code darf nur in einem abgeschotteten Iframe ausgeführt werden, kann nur genehmigte Bibliotheken laden und keine Netzwerkanfragen an andere Websites senden.“ Nutzer wünschen sich dringend sichere Umgebungen, in denen Fehler beim Vibe-Coding weder Produktionssysteme zerstören noch echte Daten offenlegen können.

3. Eine echte Funktion zum Einfrieren von Code

Nach dem Vorfall mit der gelöschten Datenbank bei Replit versprach Amjad Masad: „Wir haben den Ärger über das fehlende ‚Code-Freeze‘ laut und deutlich vernommen – wir arbeiten aktiv an einem Planungs-/Chat-only-Modus, damit Sie Strategien entwickeln können, ohne Ihre Codebasis zu gefährden.“ Nutzer möchten die Garantie, dass die KI während Prüfungsphasen keinen Code verändert.

4. Standardmäßige Trennung von Entwicklung und Produktion

Replit verpflichtete sich zu einer „automatischen Trennung von Entwicklungs- und Produktionsdatenbanken, um so etwas grundsätzlich zu verhindern. Staging-Umgebungen sind ebenfalls in Arbeit.“ Erfahrene Entwickler waren schockiert, dass dies nicht von Anfang an Standard war. Nutzer möchten, dass es auf jeder Vibe-Coding-Plattform fest integriert ist.

5. Sicherheitsscans bereits bei der Codegenerierung

Mehrere Nutzer beschrieben, dass sie „Cursor-Regeln für bewährte Sicherheitspraktiken“ benötigen und „Claude eine Checkliste mit Punkten erstellen lassen, die ich als Kontext zu Cursor hinzufügen kann, damit Vibe-Apps schlank und sicher bleiben“. Der Workflow eines Entwicklers: „Außerdem habe ich gelernt, dass der Agent unbedingt jede neu hinzugefügte Funktion auf Sicherheitsprobleme prüfen sollte.“ Nutzer möchten automatische und verpflichtende Sicherheitsprüfungen statt einer optionalen Funktion.

6. Ehrliche Einschränkungen und realistische Erwartungen

Die Kursbeschreibung von Andrew Ng brachte auf den Punkt, was Nutzer brauchen: „‚Vibe-Coding‘ bezeichnet eine zunehmend verbreitete Praxis, bei der Sie den generierten Code kaum ansehen und sich stattdessen auf die Architektur und Funktionen Ihrer Anwendung konzentrieren. Doch entgegen der weitverbreiteten Annahme besteht effektives Programmieren auf diese Weise nicht einfach darin, Prompts einzugeben, alle Empfehlungen anzunehmen und auf das Beste zu hoffen. Es erfordert eine strukturierte Arbeitsweise, die Verfeinerung Ihrer Prompts und einen systematischen Prozess.“

7. All-in-one-Plattformen mit allem, was dazugehört

Aus Karpathys MenuGen-Blog: „Manche App-Entwicklungsplattformen könnten alles mitbringen, was man braucht. Etwas, das das Gegenteil des Vercel Marketplace ist. Etwas Meinungsstarkes und Konkretes, vorkonfiguriert mit allem, was alle brauchen: Domain, Hosting, Authentifizierung, Zahlungen, Datenbank und Serverfunktionen.“ Nutzer wollen nicht 15 Dienste integrieren, sondern eine einheitliche Umgebung.

8. Einfachere Tech-Stacks

Karpathy erneut: „Für meine nächste App überlege ich, auf einfaches HTML/CSS/JS und ein Python-Backend zu setzen (etwa mit FastAPI + Fly.io?), also auf etwas deutlich Einfacheres als das serverlose Multiversum der ‚modernen Webentwicklung‘.“ Die Komplexität moderner Stacks verschärft die Probleme mit KI-Halluzinationen.

9. Sitzungsübergreifendes Langzeitgedächtnis

Ein frustrierter Entwickler: „Der Agent lernt nicht während der Arbeit dazu, es sei denn, Sie fordern ihn ausdrücklich auf, Informationen zu seinen Regeln oder Erinnerungen hinzuzufügen. Jedes Mal, wenn Sie den Kontext zurücksetzen oder eine neue Sitzung starten, arbeiten Sie mit einem völlig neuen Mitarbeiter.“ Nutzer möchten Agenten, die sich Projektkonventionen und frühere Fehler merken.

10. Rollback und Wiederherstellung per Klick

Nach den Vorfällen betonte Replit: „Zum Glück haben wir Backups. Mit einem Klick lässt sich der gesamte Projektzustand wiederherstellen, falls der Agent einen Fehler macht.“ Nutzer möchten Versionsverwaltung wie bei Git und sofortiges Rückgängigmachen von KI-Aktionen.

11. Transparente Kostenkontrolle

Nach unerwarteten Rechnungen von über 600 US-Dollar wünschen sich Nutzer vorab festgelegte Kostengrenzen, Nutzungs-Dashboards und Warnungen vor teuren Vorgängen. Der Wechsel von Pauschalabos zu einer nutzungsabhängigen Abrechnung nach Rechenleistung überraschte viele Nutzer.

Wie KI-Tools auf Nutzerfeedback reagieren

Bis Mitte 2025 begannen mehrere Plattformen, die Forderungen der Nutzer umzusetzen, allerdings in unterschiedlichem Umfang:

Replits Reaktion auf die Datenbankvorfälle umfasste die automatische Trennung von Entwicklungs- und Produktionsumgebungen, Staging-Umgebungen, die Wiederherstellung des Projektzustands mit einem Klick, die verpflichtende Suche in der Dokumentation nach Replit-spezifischem Wissen und den versprochenen Chat-only-Planungsmodus. Die schnelle Reaktion von CEO Amjad Masad half, den Schaden einzudämmen. Nutzer merkten jedoch an, dass diese Funktionen von Anfang an hätten verfügbar sein sollen.

Das Aufkommen von TheAuditor und ähnlichen Offline-Scannern spiegelte die Nachfrage der Nutzer nach datenschutzfreundlicher Sicherheit wider. TheAuditor teilte Befunde in 65-KB-Segmente auf, die in die Kontextlimits von Claude/GPT-4 passten, und ermöglichte so KI-gestützte Behebung ohne Uploads in die Cloud. Laut dem Entwickler sank die Zahl kritischer Probleme in Projekten „in 3–4 Iterationen von 185 auf null“.

Wie Snyk auf dieses Feedback reagiert

Die Integration des Model Context Protocol von Snyk ging Sicherheitsbedenken an, indem sie Echtzeit-Scans auf Sicherheitslücken bei der Codegenerierung durch KI ermöglicht. Snyk entwickelte MCP-Server für Cursor, GitHub Copilot, Windsurf und andere Assistenten. Entwickler können damit Code vor der Annahme scannen. DeepCode AI erzielte eine Genauigkeit von 80 % bei automatisierten Korrekturen und lief dabei selbst gehostet, sodass kein Code an Dritte gesendet werden musste. Untersuchungen ergaben eine ernüchternde Zahl: 48 % des gesamten KI-generierten Codes sind derzeit unsicher (Studie der Georgetown University), und GitHub Copilot kann „vorhandene Sicherheitslücken verstärken, indem es unsichere Code-Muster in Ihrer Codebasis übernimmt.“

Die von Snyk empfohlenen Sicherheitsregeln für Cursor wurden zu einer Vorlage, die Nutzer vielfach teilten: „Führen Sie für neu generierten First-Party-Code immer einen Snyk Code-Scan aus. Führen Sie für neue Abhängigkeiten oder Abhängigkeitsaktualisierungen immer einen Snyk SCA-Scan aus. Versuchen Sie bei gefundenen Sicherheitsproblemen, diese mithilfe des Snyk-Ergebniskontexts zu beheben. Scannen Sie nach der Behebung erneut, um sicherzustellen, dass die Probleme behoben sind.“ Der Scanner fand regelmäßig 50 bis über 200 Sicherheitslücken pro KI-generiertem Projekt, darunter SQL-Injection über f-Strings, fest codierte Geheimnisse (JWT_SECRET = "secret" kam überall vor), fehlende Authentifizierung und fehlerhafte Ratenbegrenzung.

Die MCP-Integration von Cursor mit Snyk und anderen Sicherheitstools machte deutlich, dass blindes „Alles akzeptieren“ gefährlich ist. Das kuratierte MCP-Tools-Verzeichnis bot Nutzern geprüfte Sicherheitsoptionen, doch ihre Implementierung blieb freiwillig statt verpflichtend.

Wie Nutzer heute über Vibe-Coding sprechen

Bis zum vierten Quartal 2025 hatte sich das Phänomen Vibe-Coding in klar abgegrenzte Anwendungsfälle aufgeteilt. Was funktioniert: Wegwerfprojekte fürs Wochenende, schnelles Prototyping, persönliche Tools ohne sensible Daten, das Lernen neuer Programmiersprachen und Experimente mit geringem Risiko. Was katastrophal scheitert: Produktionssysteme, Anwendungen mit Nutzerdaten, sicherheitskritische Software, Finanz- oder medizinische Systeme und alles, was langfristig gewartet werden muss.

Der Twitter-Nutzer @stevekrouse (Val Town) brachte den Konsens auf den Punkt: „Vibe-Code ist Legacy-Code. Karpathy prägte den Begriff Vibe-Coding für eine Art KI-gestütztes Programmieren, bei der man ‚vergisst, dass der Code überhaupt existiert‘. Für Code, den niemand versteht, haben wir bereits einen Begriff: Legacy-Code. Legacy-Code wird aus gutem Grund allgemein verachtet … Beim Vibe-Coding häufen Sie technische Schulden an, so schnell, wie das LLM Code ausspuckt. Deshalb eignet sich Vibe-Coding perfekt für Prototypen und Wegwerfprojekte: Legacy-Code ist es nur, wenn Sie ihn warten müssen!“

Simon Willisons Unterscheidung wurde zum geflügelten Wort: „Wenn ein LLM jede Codezeile geschrieben hat, Sie aber alles überprüft, getestet und verstanden haben, ist das kein Vibe Coding – dann nutzen Sie ein LLM als Schreibassistenz.“ Verantwortungsvolle KI-Unterstützung unterscheidet sich von Vibe Coding durch Verständnis und Verantwortlichkeit.

Der Tweet des Nutzers @IroncladDev brachte die Ernüchterung nicht-technischer Gründer auf den Punkt: „‚Vibe Coding‘ ist für nicht-technische Menschen eine Illusion, eine Fata Morgana. Es erfüllt Sie mit Stolz und einem Gefühl der Leistung. Doch wenn schwierige Probleme auftauchen, für deren Lösung Senior-Entwickler bezahlt werden, kommen KI-Agenten ins Straucheln. Willkommen in der echten Welt.“ Das Eingeständnis des betreffenden Nutzers: „Ich stelle meine App ein. Cursor macht andere Teile des Codes ständig kaputt. Ihr hattet recht, ich hätte keinen ungesicherten Code in die Produktion bringen sollen.“

Das Produktivitätsparadoxon blieb bestehen. Ein Kommentator auf Hacker News fasste es so zusammen: „Dann ist es meiner Meinung nach kein Produktivitätsschub. ‚Schneller mehr technische Schulden erzeugen‘ ist das denkbar schlechteste Ergebnis eines ‚Produktivitäts‘-Tools.“ Ein anderer ergänzte: „Denken Sie daran: Die meisten erfolgreichen Exits finden mehr als fünf Jahre nach der Gründung statt. Wenn eine KI in einer Woche einen Prototyp ausspuckt, statt dass Sie ihn in vier Wochen selbst entwickeln, bekommen Sie vielleicht etwas schneller eine Seed-Finanzierung. Wenn das aber die Produktentwicklung in den nächsten vier bis fünf Jahren um mehr als drei Wochen verzögert, lohnt es sich trotzdem nicht.“

Was Nutzer wirklich wollen: Verlässlichkeit statt Glücksspiel

Die zentrale Erkenntnis aus Hunderten von Nutzerberichten: Nutzer wollen, dass KI die Softwareentwicklung beschleunigt, nicht ersetzt. Eine Formulierung, die auf Reddit und Hacker News die Runde machte, brachte die Frustration auf den Punkt: „Vibe Coding ist keine Softwareentwicklung, sondern Hoffen.“

Nutzer wollen nicht auf KI-Coding-Assistenten verzichten – die Stack Overflow-Umfrage von 2025 ergab, dass 80 % der Teams KI-Coding-Tools vertrauen. Dieselbe Umfrage zeigte jedoch, dass 59 % sich Sorgen über neue Schwachstellen machen und 56,4 % häufig auf Sicherheitsprobleme in KI-generiertem Code stoßen. Das Spannungsfeld zwischen Vertrauen und Bedenken prägt die aktuelle Situation.

Die Erwartungen der Nutzer sind anspruchsvoll: KI soll Code generieren, den sie verstehen können; Sicherheitsprüfungen sollen vor der Freigabe statt erst nach dem Deployment stattfinden; Kostenmodelle sollen keine unerwarteten Rechnungen über 8.000 $ verursachen; das Modellverhalten soll auch nach Updates konsistent bleiben; Plattformen sollen alles Nötige mitbringen und sichere Standardeinstellungen bieten. Außerdem sollen Tools Nutzer zu besseren Entwicklern machen – statt sie zu Prompt-Bedienern zu degradieren, die unverständliche Codebasen verwalten.

Der Kater nach dem Vibe Coding hat Entwicklern eine wichtige Lektion erteilt: Geschwindigkeit ohne Verständnis ist keine Produktivität, sondern erzeugt lediglich schneller technische Schulden. Nutzer begrüßten KI wegen ihres Versprechens, stellten jedoch fest, dass sie Leitplanken brauchen – nicht nur mehr Tempo. Bei der Zukunft von KI-Coding-Assistenten wird es nicht darum gehen, „den Code ganz zu vergessen“, sondern darum, generierten Code schneller zu verstehen und Sicherheit von Anfang an einzubauen, statt sie nach einem Desaster nachzurüsten.

Möchten Sie die Sicherheit Ihres KI-generierten Codes gewährleisten? Laden Sie „Secure by Design: A Playbook for AI-Assisted Coding“ herunter. Darin finden Sie konkrete, umsetzbare Schritte und Leitplanken, um KI sicher in Ihren Workflow zu integrieren.