vi3ecoding Team
Frag zehn Leute, was Vibe Coding ist, und du kriegst zehn Antworten.
Die Hälfte ist falsch. Die andere Hälfte zu generisch, um nützlich zu sein.
Vibe Coding heißt: echte Software shippen, indem man AI-Tools dirigiert statt jede Zeile selbst zu tippen. Das Schlüsselwort ist „dirigieren" — nicht „zuschauen".
Weiterlesen auf vi3ecoding:
- Sieben Fehler, die neue Vibe Coder machen
- Context Engineering: Die Fähigkeit, die gute AI-Builder von großartigen unterscheidet
- Der Lovable AI Builder Guide
Ich verdiene seit etwa zwei Jahren damit Geld. Lang genug, um eine Meinung zu haben. Hier die ehrliche Founder-Definition.
Was Vibe Coding nicht ist
Erstmal das Rauschen entfernen.
- Es ist nicht „die AI schreibt den Code, während du zuschaust". Das ist eine YouTube-Demo, kein Workflow.
- Es ist kein No-Code mit Zwischenschritten. Echter Code wird geshippt — lesbar, änderbar, deploybar.
- Es ist kein Prompt Engineering. Prompts sind ein kleiner Teil. Kontext und Urteilsvermögen sind die größeren.
- Es ist keine Phase. Die Tools werden besser, nicht schlechter.
- Es ist nicht „Coden ohne Nachdenken". Eher mehr Nachdenken, weniger Tippen.
Woher der Begriff kommt
Andrej Karpathy hat ihn Anfang 2025 geprägt für eine Art zu bauen, bei der man sich in die „Vibes" dessen, was die AI produziert, hineinlehnt und Richtung gibt. Der Begriff hat sich verselbstständigt — in zwei Richtungen verzerrt. Kritiker meinen damit schlampigen AI-Output, den man nicht gelesen hat. Marketer meinen jedes Produkt, das mit einem AI-Tool gebaut wurde. Beides verfehlt die Praxis.
Was Vibe Coding wirklich ist
Drei Bewegungen, in dieser Reihenfolge.
- Entscheiden, was gebaut werden soll. Echte Produktarbeit. Strategie, Scope, Trade-offs.
- Der AI sagen, was sie bauen soll. Mit Kontext, Beispielen, strukturierten Anfragen.
- Den Output editieren wie ein Senior-Engineer. Diff reviewen. Tests laufen lassen. Den Geruch bemerken.
Ein Vibe Coder ist nicht jemand, der weniger tippt. Ein Vibe Coder ist jemand, der mehr denkt — und das Tippen an die Tools auslagert.
Die drei Rollen, die du wirklich spielst
Wenn ich Foundern Vibe Coding erkläre, nutze ich drei Rollen.
- Stratege — was soll existieren, für wen, bis wann.
- Direktor — was soll die AI als nächstes bauen, mit welchen Constraints.
- Editor — was bleibt, was wird umgeschrieben, was fliegt.
Die AI ist der Entwickler. Du bist Stratege, Direktor und Editor. Das ist der ganze Job. In einem gesunden Projekt rund 40 % Strategie, 30 % Direktion, 30 % Editing. Wenn du 80 % als Direktor unterwegs bist, sind die Context-Dateien zu dünn.
Ein echtes Beispiel: foodla.eu
Multi-Restaurant-Plattform. Restaurants onboarden sich selbst, verwalten Menüs, werden über die Suche gefunden. Echte User. Echtes Geld.
Rund 10 Stunden fokussierte Arbeit nach den Context-Dateien. Lovable hat das React geschrieben. Supabase trug Datenbank, Auth und RLS. Ich habe Produkt-Entscheidungen getroffen, den Build dirigiert und jeden relevanten Diff gereviewed.
War das „Coden"? Nach der 2018er-Definition: nein. War es Software bauen, die Rechnungen zahlt? Absolut.
Für wen Vibe Coding ist
Drei Gruppen, geordnet nach Fit.
- Produkt-orientierte Founder, die ihre eigene Idee shippen wollen, ohne für die ersten 100 Kunden ein Team aufzubauen.
- Designer und PMs, die immer bauen wollten, aber nie gegen Tooling kämpfen.
- Engineers, die bereit sind, „ich schreibe jede Zeile" aus ihrer Identität zu streichen.
Gruppe 3 ist die spannendste. Die Engineers, die sich auf Vibe Coding einlassen, shippen mehr als je zuvor. Die, die sich weigern, werden langsam ausgespielt.
Für wen Vibe Coding nicht ist
Ehrlichkeits-Sektion.
- Performance-kritische Systeme — Game Engines, Datenbanken, Embedded.
- Codebases, in denen jede Regression Millionen kostet — Fintech-Rails, Medizingeräte.
- Leute, die Editing hassen und nur tippen wollen.
Wenn deine Domäne auf dieser Liste steht, ist Vibe Coding ein Werkzeug in deinem Kasten, nicht dein Job.
Der Skill-Stack eines arbeitenden Vibe Coders
Worauf ich beim Einstellen oder Zusammenarbeiten achte:
- Kann einen einseitigen Produkt-Brief ohne Füllwörter schreiben.
- Kann einen Code-Diff lesen und merken, was fehlt — nicht nur, was da ist.
- Kennt den Unterschied zwischen UI-Bug und Datenmodell-Bug.
- Hat etwas Echtes an echte User geshippt — auch winzig.
- Behandelt AI-Output als Entwurf, nie als Deliverable.
Was nicht auf der Liste steht: Jahre Erfahrung, Framework-Zertifikate, CS-Abschluss. Hilft. Entscheidet nicht.
Wie Vibe Coding Vi3ecoding verändert hat
Drei konkrete Verschiebungen.
- Ich nehme mehr Kunden-Projekte pro Quartal an — ohne das Team zu vergrößern.
- Ich price nach Outcomes, nicht nach Stunden. Stunden sind nicht mehr der Engpass.
- Ich verbringe mehr Zeit mit Briefs und Reviews, weniger mit Glue-Code.
Die Arbeit fühlt sich mehr wie Magazin-Editing an als wie Roman-Schreiben. Der Trade war es wert.
Die Zukunft des Begriffs
„Vibe Coding" ist vielleicht nicht der Begriff, den wir in fünf Jahren nutzen. Die Praxis wird das Label überleben. Egal wie wir es nennen werden — AI-assisted Development, Agentic Engineering, Product-led Building — die Form bleibt dieselbe: Menschen entscheiden, AI führt aus, Menschen reviewen.
Also — was ist Vibe Coding wirklich?
Es ist nicht der Tod des Codens. Es ist der Aufstieg des Dirigierens.
Ein Vibe Coder ist ein Stratege mit einem Entwickler-Team aus AI-Tools und der Bereitschaft, zu shippen.
Das Label wird sich weiter entwickeln. Die Praxis ist schon hier — und zahlt Miete für Leute wie mich, die sie früh ernst genommen haben.