Andrej Karpathy nennt es 'Vibe Coding' — Software bauen, ohne den Code wirklich zu lesen. Klingt verrückt. Funktioniert aber immer öfter. Eine Einordnung.
Was ist Vibe Coding?
Anfang 2026 hat Andrej Karpathy — Ex-Tesla AI-Chef und OpenAI-Mitgründer — einen Begriff geprägt, der seitdem die Developer-Community spaltet: Vibe Coding.
Die Idee: Du beschreibst, was du willst. Die AI baut es. Du testest das Ergebnis, nicht den Code. Wenn es funktioniert, funktioniert es.
Klingt unprofessionell? Vielleicht. Funktioniert es? Überraschend oft.
Warum der Begriff polarisiert
Lager 1: "Das ist nicht echte Entwicklung"
Erfahrene Entwickler sehen Vibe Coding als Rückschritt. Code, den niemand versteht, wird zur Blackbox. Wartbarkeit geht gegen Null. Technische Schulden explodieren.
Lager 2: "Das ist die Zukunft"
Business-Leute und Indie-Hacker lieben es. Sie bauen in Stunden, was früher Wochen dauerte. Prototypen, MVPs, interne Tools — alles ohne Engineering-Hintergrund.
Die Wahrheit: Beide haben recht. Es kommt auf den Kontext an.
Wo Vibe Coding funktioniert
Prototypen und MVPs
Du willst eine Idee testen. Ob der Code "schön" ist, spielt keine Rolle — nur ob das Produkt funktioniert. Hier ist Vibe Coding ideal: Schnell bauen, Feedback einholen, iterieren.
Interne Tools
Das Dashboard für das Sales-Team. Das Monitoring-Tool für Ops. Das Migrations-Script, das einmal läuft und dann nie wieder. Code, der kein 10-Jahres-Lifecycle hat, braucht kein 10-Jahres-Engineering.
Proof of Concepts
Vor dem Meeting mit dem Investor oder dem Vorstand: Eine funktionierende Demo statt Slides. Vibe Coding liefert in Stunden, was sonst Sprints dauert.
Persönliche Projekte
Side Projects, Hobby-Apps, Lernprojekte. Wer Spaß haben will, muss nicht jede Zeile reviewen.
Wo Vibe Coding gefährlich wird
Production-Code für Kunden
Software, die Geld kostet, Daten verarbeitet oder reguliert ist. Hier ist "ich verstehe den Code nicht" keine akzeptable Haltung. Bugs, Security-Lücken und Compliance-Verstöße lauern überall.
Langlebige Systeme
Code, der in 5 Jahren noch gewartet werden muss, kann nicht "gevibt" sein. Irgendwann muss jemand einen Bug fixen — und dann muss er den Code verstehen.
Team-Kontexte
Ein Entwickler vibt alleine. Im Team wird Vibe Coding zum Chaos: Kein Reviewer versteht den Code, kein Onboarding ist möglich, keine Architektur-Entscheidungen sind nachvollziehbar.
Der professionelle Mittelweg
Statt Vibe Coding komplett abzulehnen oder blind zu umarmen, gibt es einen pragmatischen Ansatz:
- 1.Phase 1: Vibe — Schnell bauen, Idee validieren, Feedback einholen
- 2.Phase 2: Verify — Ergebnis prüfen, Tests schreiben, Security checken
- 3.Phase 3: Harden — Code reviewen, refactoren, Production-ready machen
Der Trick ist, Phase 1 nicht mit Phase 3 zu verwechseln. Vibe Coding ist ein Prototyping-Tool, kein Production-Workflow.
Was du davon mitnehmen kannst
Vibe Coding zeigt, wohin die Reise geht: Software wird auf einem höheren Abstraktionslevel gebaut. Nicht "welche Zeile Code schreibe ich?" sondern "welches Ergebnis will ich?"
Für dein Team heißt das: Die Fähigkeit, AI effektiv zu steuern, wird wichtiger als die Fähigkeit, jede Zeile selbst zu schreiben. Das ist kein Qualitätsverlust. Das ist eine Verschiebung der Qualitätskriterien.
