← Alle Beitrage

Vibe Coding vs. Engineering: Wo ich die Grenze ziehe

7 Min. Lesezeit

Andrej Karpathy prägte den Begriff „Vibe Coding” im Februar 2025 und beschrieb damit einen Entwicklungsstil, bei dem der Programmierer „sich vollständig den Vibes hingibt, Exponentialkurven umarmt und vergisst, dass der Code überhaupt existiert.”1

Ich las das und dachte: Das ist die Hälfte meines Workflows. Die andere Hälfte ist das genaue Gegenteil.

TL;DR

Ich entwickle jeden Tag mit Claude Code. Ein Teil dieser Arbeit ist reines Vibe Coding: beschreiben, was ich will, das Ergebnis akzeptieren, weitermachen. Ein anderer Teil durchläuft 86 Hooks, einen Git-Sicherheitswächter, eine Rekursionssperre und ein Quality-Gate-System, das Commits mit KI-typischen Formulierungen oder Passivkonstruktionen blockiert. Die Grenze zwischen beidem ist nicht willkürlich. Prototypen bekommen Vibes. Produktion bekommt Engineering. Das Schwierige ist zu erkennen, wann ein Prototyp die Grenze überschreitet.

Mein tatsächlicher Workflow

Die Vibe-Seite

Wenn ich eine Idee erkunde, betreibe ich Vibe Coding ohne Entschuldigung. Meine Ace Citizenship iOS-App begann als Wochenendexperiment: „Baue ein Spaced-Repetition-Quiz für USCIS-Einbürgerungsfragen.” Claude Code generierte die anfänglichen SwiftUI-Views, die Fragenbank und den Planungsalgorithmus. Ich las nicht jede Zeile. Ich startete die App, testete manuell und iterierte, indem ich beschrieb, was sich falsch anfühlte.

Die interaktiven Komponenten auf diesem Blog (der RAG-Entscheidungsbaum, der Zinseszinsrechner) entstanden auf die gleiche Weise. „Baue einen Entscheidungsbaum, der Benutzer durch RAG vs. Fine-Tuning führt, mit animierten Übergängen.” Akzeptieren, testen, anpassen. Der Wirkungsradius eines Bugs in einem Blog-Widget ist auf eine einzelne Seite beschränkt.

Die Engineering-Seite

Meine Claude Code Hook-Architektur ist das Gegenteil von Vibe Coding. Jeder Hook existiert, weil etwas schiefgelaufen ist.

git-safety-guardian.sh existiert, weil Claude während einer frühen Sitzung einen Force-Push auf main ausführte. Der Hook fängt jetzt jeden Git-Befehl ab, gleicht ihn mit einer Schweregraddtabelle ab (CRITICAL: Force-Push auf main; HIGH: Hinzufügen von .env-Dateien; MEDIUM: –no-verify) und gibt eine Warnung aus, bevor der Befehl ausgeführt wird.

recursion-guard.sh existiert, weil ein Subagent unendlich viele Kindprozesse erzeugte. Der Hook verfolgt die Agentenherkunft in einer JSON-Datei, erzwingt Tiefenbegrenzungen und verwaltet ein Spawn-Budget-Modell, das unkontrollierte Agentenketten verhindert und gleichzeitig legitime parallele Arbeit ermöglicht.

blog-quality-gate.sh existiert, weil KI-generierte Prosa wie KI-generierte Prosa klingt. Der Hook blockiert Commits in content/blog/, wenn er Geviertstriche, Passivkonstruktionen oder Wörter wie „delve”, „crucial” oder „landscape” erkennt.

Keiner dieser Hooks wurde per Vibe Coding erstellt. Jeder einzelne wurde Zeile für Zeile geschrieben, gegen reale Fehlerszenarien getestet und vor der Inbetriebnahme überprüft. Die 86 Hooks bilden zusammen die Grenze zwischen Vibing und Engineering.

Wo die Grenze tatsächlich verläuft

Vibe: Wegwerf-Prototypen

Ich nutze Vibe Coding für alles, was ich möglicherweise wegwerfe. Ein Datentransformationsskript, das ich einmal ausführe. Ein CLI-Tool für den persönlichen Gebrauch. Ein Proof-of-Concept, um zu testen, ob eine API das tut, was die Dokumentation verspricht. Die Kosten eines Bugs in Wegwerf-Code sind meine eigene Zeit, und der Geschwindigkeitsvorteil überwiegt das Debugging-Risiko.

Vibe: Kreative Exploration

Wenn ich eine Designrichtung erkunde, lässt mich Vibe Coding Interaktionsmuster schneller testen als Figma. „Baue ein Suchmodal mit Tastaturnavigation, Ergebnishervorhebung und Cmd+K-Aktivierung” liefert in Minuten einen funktionierenden Prototypen. Ich bewerte das Gefühl, nicht den Code.2

Engineering: Alles, was Benutzer erreicht

Sobald Code jemand anderem als mir dient, überschreitet er die Grenze. Mein Blog durchläuft einen 12-Modul-Linter, der Quellenangaben, Überschriftenhierarchie, Lesbarkeitsgrad, Bild-Alt-Texte, interne Linkdichte und Inhaltstiefe prüft. Der Linter hat 77 Tests. Der Blog hat 29 Beiträge. Der Linter hat mehr Tests als der Blog Inhalte hat.

Engineering: Alles, was bestehen bleibt

Datenbankschemata, API-Verträge, Hook-Konfigurationen und Deployment-Manifeste erhalten die volle Engineering-Behandlung. Diese Entscheidungen akkumulieren sich. Ein Schema, das in einer Vibe-Sitzung entworfen wurde, wird zum Migrationalptraum, wenn sich drei Jahre an Daten darauf ansammeln.3

Engineering: Alles, was sicherheitsrelevant ist

KI-generierter Code spiegelt die Sicherheitslage seiner Trainingsdaten wider, die Tutorials und Stack-Overflow-Antworten umfassen, in denen Authentifizierung, Eingabevalidierung und Fehlerbehandlung routinemäßig aus Gründen der Kürze weggelassen werden.4 Meine Hooks fangen einiges davon ab (der Git-Sicherheitswächter meldet .env-Ergänzungen, Anmeldedateien und Force-Pushes), aber sicherheitskritischer Code wird unabhängig davon manuell überprüft.

Das Problem der Verständnislücke

Das gefährlichste Muster beim Vibe Coding ist nicht schlechter Code. Es ist Code, der funktioniert, bis er es nicht mehr tut.

Ich generierte eine Caching-Schicht für mein i18n-Übersetzungssystem. Sie funktionierte einwandfrei für englische Inhalte. Als ich Koreanisch und traditionelles Chinesisch hinzufügte, erzeugte die Cache-Key-Generierung stillschweigend Kollisionen bei bestimmten Unicode-Codepunkten. Das Debugging dauerte vier Stunden, weil ich die Cache-Key-Funktion nie gelesen hatte. Der Code war korrekt für ASCII, was die Trainingsdaten vorrangig abdeckten.5

Die Lektion: Per Vibe Coding erstellte Systeme versagen an den Rändern, die in den Trainingsdaten unterrepräsentiert sind. Wenn Ihre Benutzer an diesen Rändern operieren (nicht-lateinische Schriften, hohe Parallelität, ungewöhnliche Netzwerkbedingungen), bergen Vibe-Coding-Implementierungen versteckte Risiken.

Das Review-Gate

Jedes Stück produktionsbestimmten Codes in meinem System durchläuft ein Review-Gate, unabhängig davon, ob ich es geschrieben habe oder Claude Code:

  1. Jede Zeile lesen. Generierter Code ist ein Pull Request von einem nicht vertrauenswürdigen Mitwirkenden. Überprüfen Sie ihn entsprechend.
  2. Fehlerbehandlung verifizieren. Prüfen Sie, ob Fehlerpfade die Domänenanforderungen widerspiegeln und nicht generische Try-Catch-Muster.
  3. Abhängigkeiten auditieren. KI löst jeden Prompt isoliert und importiert jede Bibliothek, die die unmittelbare Anfrage löst. Nach 50 Prompts haben Sie möglicherweise drei Datumsbibliotheken und zwei HTTP-Clients.
  4. Tests hinzufügen. Generierter Code deckt selten Randfälle ab, die spezifisch für Ihre Domäne sind.
  5. Sicherheit prüfen. Führen Sie statische Analyse durch. Verifizieren Sie Authentifizierung, Autorisierung und Eingabevalidierung.6

Das Review-Gate ist nicht optional. Es ist der Unterschied zwischen der Nutzung von KI als Kraftmultiplikator und der Nutzung von KI als Krücke.

Die Spaltung der Branche

Software Engineering spaltet sich in zwei Ebenen. Die erste nutzt KI als Kraftmultiplikator: Boilerplate generieren, Lösungsräume erkunden und die Implementierung gut verstandener Muster beschleunigen, während Verständnis und Qualitätsstandards erhalten bleiben. Die zweite generiert ganze Anwendungen, ohne den Output zu verstehen, und tauscht kurzfristige Geschwindigkeit gegen langfristige Fragilität.7

Die Spaltung spiegelt die frühe Webentwicklung wider. Template-Builder wie Squarespace demokratisierten das Web-Publishing und erzeugten Millionen funktionaler Websites. Professionelle Webentwicklung besteht fort, weil Produktionssysteme Qualität, Sicherheit und Wartbarkeit erfordern, die Templates nicht bieten können.

Ich operiere bewusst auf beiden Ebenen. Mein Hook-System und meine Quality-Gates existieren genau dafür, den Moment zu erkennen, in dem Arbeit der zweiten Ebene auf Standards der ersten Ebene gehoben werden muss. Die 86 Hooks sind keine Bürokratie. Sie sind das Immunsystem, das es mir ermöglicht, frei per Vibe Coding zu arbeiten und gleichzeitig verhindert, dass per Vibe Coding erstellte Arbeit ohne Überprüfung in die Produktion gelangt.

Wichtigste Erkenntnisse

Für Engineers, die täglich KI nutzen: - Ziehen Sie eine klare Grenze zwischen Exploration und Produktion; nutzen Sie Vibe Coding für Wegwerf-Arbeit frei, aber erzwingen Sie Review-Gates, bevor irgendetwas Benutzer erreicht oder persistiert wird - Bauen Sie automatisierte Leitplanken (Hooks, Linter, Quality-Gates) statt sich allein auf Disziplin zu verlassen; Disziplin versagt um 2 Uhr nachts, Hooks nicht

Für Engineering-Manager: - Etablieren Sie klare Grenzen zwischen Prototyp-Qualität und Produktions-Qualität im Code; per Vibe Coding erstellte Prototypen, die in die Produktion rutschen, schaffen eine neue Kategorie technischer Schulden - Bewerten Sie Produktivität anhand von Ergebnissen (ausgelieferte Funktionen, Bugs pro Funktion, Benutzerzufriedenheit) statt anhand von Velocity-Metriken; Vibe Coding bläht Zeilenzahlen auf, ohne die Ergebnisse proportional zu verbessern

Referenzen

  1. Karpathy, Andrej, „Vibe Coding,” X/Twitter, Februar 2025. Ursprüngliche Definition des Begriffs. ↩

  2. Workflow des Autors beim Erstellen interaktiver Komponenten und Designprototypen mit Claude Code, 2025–2026. ↩

  3. Analyse des Autors zu Datenbankmigrations-Kosten über drei Produktionssysteme. Die Migrationskosten stiegen über drei Jahre um das 15-Fache. ↩

  4. Pearce, Hammond et al., „Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions,” IEEE S&P 2022. ↩

  5. Erfahrung des Autors beim Debugging von i18n-Cache-Key-Kollisionen im Übersetzungssystem von blakecrosley.com, Februar 2026. ↩

  6. Anthropic, „Claude Code Documentation: Best Practices,” docs.anthropic.com, 2025. ↩

  7. Analyse des Autors zum entstehenden Entwickler-Ebenensystem, beobachtet auf Hacker News, X/Twitter und Entwicklerkonferenzen, 2025–2026. ↩