Vibe Coding 6 Monate später: Was wirklich funktioniert – und was nicht

Im März haben wir hier zum ersten Mal über Vibe Coding geschrieben. Seitdem haben wir unser eigenes Produkt ScopeFlow damit gebaut, Prototypen für Kundenprojekte entwickelt und intern Tools gebaut, die früher Entwickler-Stunden gebraucht hätten.

Jetzt, sechs Monate später, ist ein guter Zeitpunkt für einen ehrlichen Rückblick. Ohne Hype. Ohne Doom-Posting. Mit konkreten Beispielen.

Was tatsächlich besser funktioniert als erwartet

Iteration ist fundamental schneller geworden

Das ist das größte und wichtigste Ergebnis. Nicht "ich kann jetzt auch ohne Entwickler Code schreiben" – das wäre die falsche Rahmung. Sondern: Die Schleife zwischen Idee, Implementierung, Test und Korrektur ist 5–10x schneller.

Ein Feature, über das ich vorher nachgedacht und es dann für die nächste Entwickler-Session aufgehoben hätte, kann ich heute in 2 Stunden selbst testen. Das verändert, wie ich an Produktentscheidungen herangehe.

KI als Denkpartner – nicht nur als Schreibtool

Der unterschätzte Aspekt von Claude: Ich nutze es mehr für Planung als für Codegenerierung. "Ich will Feature X bauen. Welche Ansätze gibt es, was sind Trade-offs, was würdest du in meinem Fall empfehlen?"

Dieser Dialog hat mein technisches Verständnis mehr erweitert als Jahre oberflächlicher Entwicklerkontakte. Weil ich Fragen stellen kann, ohne Angst zu haben, unwissend zu wirken.

Kommunikation mit Entwicklern auf einer anderen Ebene

Ich kann heute in Code-Reviews substantiell mitdiskutieren. Ich verstehe Datenbankentscheidungen. Ich kann einschätzen, ob eine Implementierung unnötig komplex ist. Das ist für die Arbeit mit Entwicklerteams wertvoll – nicht als Kontrolle, sondern als echter Austausch.

Was nicht funktioniert hat

Komplexes State-Management wird schnell chaotisch

Sobald ein Feature mehrere abhängige Zustände, asynchrone Operationen und Fehler-Handling kombiniert, verliert KI-generierter Code schnell die Übersicht. Die KI löst das Problem, das man ihr stellt – aber versteht nicht immer das Problem, das dahinterliegt.

Ich habe gelernt: Für komplexe Logik zuerst das Problem auf Papier durchdenken, dann promoten. Ohne diesen Schritt wird der Code zwar kompiliert, aber funktioniert nicht wie erwartet.

Technische Schulden entstehen schnell

Vibe Coding macht es einfach, Features zu bauen. Es macht es nicht automatisch einfach, guten Code zu bauen. Ohne regelmäßige Refactoring-Sessions – die ich als Designer intuitiv nicht priorisiert habe – sammelt sich Komplexität an, die spätere Features schwieriger macht.

Nach dem zweiten Monat habe ich eine feste Regel eingeführt: Für jedes neue Feature, das ich baue, überarbeite ich einen bestehenden Code-Bereich. Das hat die Codebase erheblich stabiler gemacht.

"Vibe" ist kein Ersatz für Spezifikation

Das ist der wichtigste Lerneffekt: Je unklarer meine Intention beim Prompt, desto öfter muss ich iterieren. Vibe Coding heißt nicht, unstrukturiert zu denken. Es heißt, strukturierte Gedanken in natürlicher Sprache ausdrücken zu können.

Ein Prompt wie "Bau mir eine Tabelle" produziert generischen Code. Ein Prompt mit Kontext ("Bau mir eine sortierbare Tabelle für Projektdaten mit Kolumnen für Name, Status, Fälligkeitsdatum – Status soll als farbige Badge dargestellt werden, die Komponente soll shadcn/ui DataTable nutzen") produziert direkt nutzbaren Code.

Security und Backend: Das bleibt Expertenterritorium

Ich weiß mehr als vor 6 Monaten. Ich bin kein Backend-Entwickler. Das ist keine Kritik an Vibe Coding – es ist eine realistische Einschätzung meiner Kompetenzen und der Komplexität des Themas. Für ScopeFlow arbeiten wir mit einem Entwickler zusammen, der Security-Review macht. Das ist richtig so.

Was ich anders machen würde

Früher an Struktur arbeiten. Die ersten zwei Monate habe ich Features gebaut und die Architektur sich entwickeln lassen. Das hat zu Refactoring geführt, das aufwändiger war als eine saubere Initialplanung.

Kleinere, häufigere Commits. Ich habe gelernt: Wenn ein Feature in 20 Stunden nicht funktioniert, ist es meistens 10 Features gleichzeitig, nicht eines. Kleinere Einheiten machen alles überschaubarer.

AI-Tools nicht als Orakel behandeln. KI-Empfehlungen hinterfragen, nicht blind umsetzen. Das klingt trivial – in der Praxis ist die Versuchung groß, der ersten plausiblen Antwort zu folgen.

Fazit: Transformativ für den richtigen Kontext

Vibe Coding hat meine Arbeit fundamental verändert. Nicht weil ich kein Entwickler mehr brauche – sondern weil ich die Lücke zwischen Design-Entscheidung und funktionierendem Produkt erheblich verkleinern kann.

Der Wert liegt nicht im einzelnen generierten Code. Der Wert liegt in der Geschwindigkeit des Lernens und der Validierung. In der Möglichkeit, eigene Produkte zu bauen, ohne auf externe Ressourcen zu warten.

Für Designer mit technischem Grundverständnis: Einsteigen. Die Lernkurve ist real, aber sie lohnt sich.

---

FAQ: Vibe Coding in der Praxis

Wie lange dauert es, Vibe Coding zu lernen? Erste nutzbare Ergebnisse: 1–2 Wochen. Produktive Routine: 1–2 Monate. Tiefes Verständnis der Grenzen: nach 6 Monaten noch im Aufbau.

Ersetzt Vibe Coding Entwickler? Nein. Es verschiebt die Grenze dessen, was Nicht-Entwickler selbst umsetzen können. Für komplexe, sicherheitskritische oder skalierbare Systeme sind erfahrene Entwickler weiterhin unverzichtbar.

Was ist die größte Gefahr bei Vibe Coding? Unkontrolliertes Wachstum von technischen Schulden und fehlende Sicherheitsüberprüfungen. Wer Vibe Coding produktiv einsetzt, sollte regelmäßige Refactoring-Sessions einplanen und Security-kritische Bereiche von Experten reviewen lassen.

Cursor oder andere Tools – was empfiehlst du nach 6 Monaten? Cursor bleibt mein primärer Editor. Die Community ist groß, die Entwicklung ist aktiv, der Projektkontext-Feature ist für echte Projekte unersetzlich.

---

Ihr wollt mit Vibe Coding anfangen und wissen, was realistische erste Schritte für euer Projekt sind? Wir beraten euch gerne: hallo@betaform.io