Anti-Pattern: Wie Vibe Coding Projekte killt (und wie nicht)

Vibe Coding — der Begriff geprägt von Andrej Karpathy — beschreibt das Programmieren durch natürliche Sprache mit AI-Assistenten wie Cursor, Bolt, Claude oder v0. Du beschreibst was du willst, die AI schreibt den Code. Funktioniert erstaunlich gut. Bis es nicht mehr funktioniert.

Die meisten Vibe-Coding-Projekte scheitern nicht an der AI. Sie scheitern an den Gewohnheiten die sich einschleichen wenn Code „einfach da ist" ohne dass du ihn verstehst. Das sind Anti-Pattern — wiederkehrende Fehler die auf den ersten Blick wie gute Lösungen aussehen.

Merksatz: „Vibe Coding ist kein Freestyle. Es ist Jazz — Improvisation mit Struktur."

Was ist ein Anti-Pattern?

Ein Anti-Pattern ist eine scheinbar gute Lösung die sich langfristig als Problem entpuppt. In der Softwareentwicklung gibt es Dutzende davon — Spaghetti Code, God Objects, Golden Hammer. Im Vibe Coding gibt es eigene Anti-Pattern die spezifisch durch die Arbeitsweise mit AI entstehen.

Der Unterschied zu klassischen Coding-Fehlern: Bei Vibe Coding bist du kein Entwickler der schlechte Entscheidungen trifft. Du bist ein Nicht-Entwickler der die Konsequenzen seiner Entscheidungen nicht sehen kann — weil der Code eine Blackbox ist.

Die 7 tödlichen Anti-Pattern

Anti-Pattern 1 — Copy-Paste-Architektur

Was passiert: Du promptest ein Feature, die AI generiert Code. Du promptest das nächste Feature, die AI generiert mehr Code. Nach 20 Features hast du 5.000 Zeilen die niemand versteht — inklusive der AI die sie geschrieben hat.

Warum es gefährlich ist: Jedes Feature wird als Einzellösung generiert, nicht als Teil einer Architektur. Funktionen werden dupliziert statt wiederverwendet. Datenstrukturen widersprechen sich. Das Projekt wird mit jedem Feature fragiler statt stabiler.

Gegenmaßnahme: Definiere vor dem ersten Prompt die Architektur. Datenbankmodell, Ordnerstruktur, Namenskonventionen. Gib der AI bei jedem Prompt den Kontext des Gesamtprojekts. „Nutze die bestehende User-Komponente aus /components/User.tsx" statt „Erstelle eine Benutzeranzeige".

Anti-Pattern 2 — Das „Es funktioniert doch"-Syndrom

Was passiert: Die Website läuft. Auf deinem Laptop. Im Chrome-Browser. Mit schnellem Internet. Also ist sie fertig. Richtig?

Warum es gefährlich ist: „Funktioniert bei mir" ist kein Qualitätskriterium. Es bedeutet nur: In genau dieser einen Konfiguration tritt kein sichtbarer Fehler auf. Auf dem iPhone eines Kunden mit mobilem Internet sieht es anders aus. Google crawlt die Seite anders als du sie siehst. Screenreader können den Content nicht lesen. (→ Core Web Vitals erklärt)

Gegenmaßnahme: Teste systematisch. Mobile Ansicht, verschiedene Browser, langsames Internet (Chrome DevTools → Network → Slow 3G). Lighthouse-Test für Performance und Accessibility. Nicht einmal, sondern bei jedem Deploy.

Anti-Pattern 3 — Dependency-Hölle

Was passiert: Für jedes Feature installiert die AI ein npm-Package. Datumsformatierung? moment.js (2 MB). Icon? @heroicons/react (500 KB). Animation? framer-motion (150 KB). Nach 10 Features hast du 30 Dependencies und ein Bundle von 5 MB.

Warum es gefährlich ist: Jede Dependency ist ein Risiko: Sicherheitslücken, veraltete Packages, Breaking Changes bei Updates, und Performance-Probleme durch aufgeblähte Bundles. Core Web Vitals leiden direkt.

Gegenmaßnahme: Frag die AI: „Kann das auch ohne zusätzliches Package gelöst werden?" Oft ja. Eine Datumsformatierung braucht kein moment.js — Intl.DateTimeFormat ist im Browser eingebaut. Prüfe regelmäßig npm audit und entferne ungenutzte Packages.

Anti-Pattern 4 — Security by Ignorance

Was passiert: API-Keys im Frontend-Code. Keine Authentifizierung auf API-Routen. SQL-Queries die Benutzereingaben direkt einbauen. Passwörter im Klartext in der Datenbank. Die AI schreibt funktionierenden Code — aber nicht sicheren Code.

Warum es gefährlich ist: Ein Sicherheitsproblem muss nur einmal ausgenutzt werden. Ein geleakter API-Key kann Hunderte Euro Kosten verursachen (Cloud-Services). Ein ungeschütztes Admin-Panel wird garantiert gefunden (Bots scannen automatisch).

Gegenmaßnahme: Prompt die AI explizit nach Security: „Prüfe diesen Code auf Sicherheitslücken." API-Keys gehören in Environment Variables, nie in den Code. Jede API-Route braucht Authentifizierung. Bei Benutzereingaben: Immer validieren, sanitizen, und parametrisierte Queries nutzen.

Anti-Pattern 5 — Deploy und Vergessen

Was passiert: Die Website ist live. Gratulation. Niemand schaut mehr hin. Sechs Monate später: SSL-Zertifikat abgelaufen, Dependencies veraltet, drei Sicherheitswarnungen, und ein Plugin das nicht mehr existiert.

Warum es gefährlich ist: Eine Website ist kein fertiges Produkt. Sie ist ein lebender Organismus der Pflege braucht. Dependencies bekommen Updates, Browser ändern sich, Google ändert seine Anforderungen.

Gegenmaßnahme: Setze automatische Alerts: Uptime-Monitoring (z.B. UptimeRobot, kostenlos), Dependabot für Security-Updates, und einen monatlichen 15-Minuten-Check: Läuft die Seite? Sind Updates da? Gibt es Warnungen in der Search Console?

Anti-Pattern 6 — Prompt-Amnesia

Was passiert: Du promptest 50× über den Tag verteilt. Jeder Prompt ist kontextlos — die AI weiß nicht was du vor 2 Stunden entschieden hast. Ergebnis: Widersprüchliche Implementierungen, doppelte Funktionen, inkonsistenter Coding-Style.

Warum es gefährlich ist: Ohne Projekt-Kontext generiert die AI jedes Mal eine neue Lösung für das gleiche Problem. Du baust im Kreis statt vorwärts.

Gegenmaßnahme: Nutze Projekt-Dateien als Kontext. Eine CLAUDE.md oder cursor-rules.md die Architektur, Conventions und Entscheidungen dokumentiert. Bei jedem Prompt: Gib der AI den Gesamtkontext, nicht nur das aktuelle Problem. Tools wie Claude Code mit CLAUDE.md lösen das systematisch.

Anti-Pattern 7 — Feature Creep durch Einfachheit

Was passiert: Weil es so einfach ist, baust du immer mehr Features. „Noch schnell eine Kommentarfunktion." „Noch ein Dashboard." „Noch Multi-Language-Support." Jedes Feature dauert nur einen Prompt — aber die Komplexität summiert sich exponentiell.

Warum es gefährlich ist: Mehr Features = mehr Code = mehr Bugs = mehr Wartung. Irgendwann verstehst du das System nicht mehr gut genug um Probleme zu debuggen. Die AI generiert zwar neuen Code, kann aber nicht das Gesamtsystem überblicken.

Gegenmaßnahme: MVP-Disziplin. Definiere vor Projektstart die Kernfeatures — maximal 5. Alles andere kommt auf eine „Später"-Liste. Für jedes neue Feature frag dich: „Braucht der Nutzer das wirklich, oder will ich es nur weil es geht?"

Warum Vibe Coding trotzdem funktioniert

Nach sieben Anti-Pattern könnte man denken: Finger weg. Aber das wäre falsch.

Vibe Coding funktioniert — wenn du Leitplanken einbaust. Die Anti-Pattern entstehen nicht durch die Technologie, sondern durch fehlende Struktur. Ein Vibe-Coding-Projekt mit klarer Architektur, Security-Checks und regelmäßiger Wartung ist genauso stabil wie ein „professionell" entwickeltes Projekt.

Der Vorteil bleibt: Du baust in Stunden was früher Wochen gedauert hat. Du brauchst kein Informatik-Studium für eine professionelle Website. Du kannst iterieren, experimentieren, und schnell live gehen. (→ Vibe Coding, aber stabil)

Vibe Coding mit Leitplanken

Die Leitplanken die ein Vibe-Coding-Projekt stabil machen:

1. Architektur-Dokument vor dem ersten Prompt (Datenmodell, Ordnerstruktur, Tech-Stack)

2. Projekt-Kontext-Datei die bei jedem Prompt mitgegeben wird

3. Security-Review nach jedem Feature (prompt die AI explizit)

4. Test auf Mobile + Slow Connection vor jedem Deploy

5. Monatlicher Wartungs-Check (15 Minuten, Dependencies + Monitoring)

6. Feature-Freeze nach MVP (erst stabilisieren, dann erweitern)

Die Checkliste gegen Anti-Pattern

Vor jedem Deploy — prüfe diese 7 Punkte:

• [ ] Architektur: Gibt es eine konsistente Ordnerstruktur und Namenskonvention?
• [ ] Tests: Funktioniert die Seite auf Mobile, langsamer Verbindung, und verschiedenen Browsern?
• [ ] Dependencies: npm audit zeigt keine kritischen Warnungen?
• [ ] Security: Keine API-Keys im Code? Alle Routes authentifiziert? Input-Validierung?
• [ ] Monitoring: Uptime-Check und Error-Tracking eingerichtet?
• [ ] Kontext: Projekt-Dokumentation aktuell?
• [ ] Scope: Nur geplante Features implementiert, kein Scope Creep?