Vibe Coding erklärt: Vom Buzzword zur echten Einordnung

Do not index

Seit einigen Monaten taucht der Begriff "Vibe Coding" überall auf – in Tech-News, auf LinkedIn, in Gesprächen mit Entwicklern. Die einen feiern es als Revolution. Die anderen warnen vor dem Untergang der Softwarequalität. Beide Seiten reden aneinander vorbei, weil sie unter demselben Begriff völlig unterschiedliche Dinge verstehen.

Der Begriff stammt von Andrej Karpathy, einem bekannten KI-Forscher. Gemeint ist eine neue Art, Software zu entwickeln: Man beschreibt in natürlicher Sprache, was man haben will, und eine KI generiert den Code. Man programmiert nicht mehr im klassischen Sinne – man "promptet". Man verlässt sich auf das Gefühl, dass es funktioniert. Daher "Vibe".

Das klingt erstmal praktisch. Das Problem ist nur: Mittlerweile versteht jeder etwas anderes darunter. Jemand, der in einem Online-Tool wie Lovable eine Landingpage zusammenklickt? Vibe Coding. Ein erfahrener Softwareentwickler, der mit KI-Unterstützung ein komplettes System baut? Auch Vibe Coding. Das wäre so, als würde man "Autofahren" sagen und damit sowohl den Fahranfänger im Parkhaus als auch den Formel-1-Piloten meinen.

Dieses Begriffsproblem haben wir in der Softwareentwicklung schon lange. "Ich bin Entwickler" kann bedeuten: Ich baue einfache Webseiten. Oder: Ich schreibe seit 20 Jahren Systeme, die Millionen von Nutzern bedienen. Das Spektrum ist riesig – und bei KI-gestützter Entwicklung ist es genauso. Deshalb brauchen wir bessere Unterscheidungen.

Die fünf Stufen der KI-gestützten Entwicklung

Um Klarheit zu schaffen, hier eine Einordnung – von "komplett automatisiert" bis "vollständig selbst orchestriert".

Stufe 1: Vibe Coding im engeren Sinne

Auf dieser Stufe nutzt man einen Online-Dienst, gibt per Text ein, was man haben will, und bekommt eine fertige Anwendung ausgespuckt. Man hat keinen Einblick in den Code, keine Kontrolle über die technische Struktur. Tools wie Lovable, Bolt oder v0 funktionieren so – Plattformen, die aus Texteingaben komplette Apps generieren.

Diese Stufe nutzen vor allem Menschen ohne Programmierkenntnisse, die schnell einen Prototyp brauchen: Gründer, die eine Idee testen wollen. Für erste Prototypen kann das funktionieren. Für alles, was länger leben soll oder wo Qualität zählt, ist es riskant. Man vertraut einer Black Box.

Stufe 2: KI als Nachschlagewerk

Auf der nächsten Stufe nutzt man ChatGPT, Claude oder ähnliche KI-Assistenten im Browser. Man stellt Fragen, bekommt Code-Vorschläge, kopiert diese und fügt sie manuell in sein Projekt ein. Man schreibt noch primär selbst, die KI hilft punktuell.

Das ist die Stufe für Entwickler, die "irgendwie KI nutzen" – gelegentlich, für spezifische Probleme. Das Risiko ist niedrig, aber auch der Nutzen begrenzt. Man holt sich Hilfe bei einzelnen Aufgaben, aber der Arbeitsprozess bleibt klassisch.

Stufe 3: KI in der Entwicklungsumgebung

Hier wird es interessant. Die KI ist direkt in die Entwicklungsumgebung (IDE) integriert – also in das Programm, in dem Entwickler ihren Code schreiben. Tools wie GitHub Copilot machen automatisch Vorschläge während des Tippens. Cursor oder Claude Code können größere Einheiten auf Anfrage schreiben. Der Entwickler steuert, prüft, entscheidet.

Diese Stufe nutzen Entwickler, die ihren Arbeitsprozess bewusst umgestellt haben. Hier fängt echter Produktivitätsgewinn an – aber auch das Risiko steigt. Man muss erkennen können, wenn das Generierte Quatsch ist.

Stufe 4: Der Entwickler als Dirigent

Auf dieser Stufe schreibt der Entwickler kaum noch Code selbst. Stattdessen formuliert er Anforderungen, prüft was die KI liefert, trifft Architekturentscheidungen, stellt Qualität sicher. Die Arbeit verschiebt sich von "Code schreiben" zu "Code steuern und bewerten".

Das funktioniert – aber nur mit entsprechender Erfahrung. Man delegiert an einen sehr schnellen, aber unerfahrenen Mitarbeiter. Und wie bei jedem unerfahrenen Mitarbeiter muss man erkennen, wenn er Fehler macht. Diese Stufe ist deshalb nur für erfahrene Entwickler geeignet, die genau wissen, was guter Code ist – auch wenn sie ihn nicht mehr selbst tippen.

Stufe 5: Die selbstgebaute Pipeline

Auf der höchsten Stufe hat der Entwickler eine eigene, automatisierte Kette aufgebaut: Von der Anforderung über die technische Spezifikation zum Code zum Test – mit minimalem manuellem Eingriff. Jeder Schritt ist definiert, dokumentiert, abgesichert.

Das nutzen noch sehr wenige. Es ist experimentell und erfordert tiefes Verständnis von Softwarearchitektur und KI-Systemen. Das ist vermutlich die Zukunft – aber der Weg dahin führt über Stufe 4, nicht über Stufe 1.

Der scheinbare Kreis – und warum er keiner ist

Auf den ersten Blick sehen Stufe 1 und Stufe 5 ähnlich aus. In beiden Fällen: wenig manueller Code, viel Automatisierung. Der fundamentale Unterschied liegt in Verantwortung und Kontrolle.

Bei Stufe 1 hat jemand anderes das System gebaut. Man vertraut blind. Es ist eine Black Box ohne Einsicht. "Es funktioniert irgendwie" – und wenn es bricht, steht man hilflos da.

Bei Stufe 5 hat man das System selbst gebaut. Man hat jeden Schritt definiert. Volle Dokumentation, klare Regeln. "Ich weiß, warum es funktioniert" – und wenn es bricht, weiß man wo.

Die zwei Lager – und warum beide falsch liegen

In der Diskussion um KI-gestützte Entwicklung haben sich zwei Lager gebildet.

Die Begeisterten posten ihre Produktivitätssteigerungen auf LinkedIn und zeigen Apps, die in 30 Minuten entstanden sind. Was sie nicht zeigen: Wie die App nach sechs Monaten aussieht. Ob sie wartbar ist. Ob sie sicher ist.

Die Warner zeigen Beispiele von generiertem Code voller Fehler, Sicherheitslücken, Chaos. Was sie ignorieren: Schlechter Code existierte auch vor KI. Das Problem ist nicht das Werkzeug, sondern wer es benutzt.

Die Realität ist: Beide haben recht – in ihrem jeweiligen Kontext.

KI-gestützte Entwicklung funktioniert. Ich nutze sie täglich für echte Kundenprojekte: Modernisierung alter Systeme, komplexe Geschäftslogik, produktive Umgebungen. KI-gestützte Entwicklung produziert auch Müll. Ich habe selbst Code weggeworfen, den ich mit KI generiert hatte – zwei Stunden Arbeit, komplett unbrauchbar.

Der Unterschied war nicht das Werkzeug. Der Unterschied war, ob ich meinen eigenen Prozess befolgt habe oder nicht.

Warum die Studien nichts beweisen

Es gibt Studien zu KI-gestützter Entwicklung. Viele sogar. Es gibt ein ganzes akademisches Feld namens "Empirical Software Engineering", das vorgibt, solche Dinge wissenschaftlich zu untersuchen.

Das Problem ist: Softwareentwicklung ist kein Laborexperiment. Man kann nicht zwei identische Projekte nehmen, eins mit KI und eins ohne, und dann vergleichen. Es gibt keine zwei identischen Projekte. Keine zwei identischen Entwickler. Keine zwei identischen Rahmenbedingungen.

Was man messen kann: Ob jemand in einer künstlichen Labor-Situation eine klar definierte Aufgabe schneller löst. Was man nicht messen kann: Ob das in der echten Welt funktioniert – mit echten Anforderungen, die sich ändern, mit bestehendem Code, den man berücksichtigen muss, mit dem Druck, der am Donnerstag kommt, weil der Kunde am Montag Ergebnisse sehen will.

Geschwindigkeit in der Softwareentwicklung ist generell schwer messbar. Codezeilen? Bedeutungslos. Geschätzte Aufwände? Subjektiv. Zeit bis zur Auslieferung? Hängt von tausend Faktoren ab. Deshalb mein Standpunkt: Die einzige verlässliche Quelle ist Erfahrung aus echten Projekten – nicht Studien, die im Vakuum entstanden sind.

Der eigentliche Unterschied: Erfahrung

Ein Anfänger mit KI produziert schneller mehr Code. Ein Anfänger mit KI produziert auch schneller mehr Chaos.

Ein erfahrener Entwickler mit KI produziert schneller besseren Code – weil er erkennt, wenn das Ergebnis falsch ist, weil er weiß, welche Fragen er stellen muss, weil er Entscheidungen über die Struktur treffen kann, die eine KI nicht trifft.

Das ist der Kern: KI verstärkt, was da ist.

Wer weiß, was guter Code ist, dem hilft KI, ihn schneller zu produzieren. Wer nicht weiß, was guter Code ist, dem hilft KI, schneller Chaos zu produzieren.

Die Metapher, die es am besten trifft: Man delegiert an einen sehr schnellen, aber unerfahrenen Mitarbeiter. Der Mitarbeiter kann unfassbar schnell tippen. Aber er trifft keine strategischen Entscheidungen. Er erkennt keine Sicherheitslücken. Er weiß nicht, wann ein bestimmtes Vorgehen passt und wann nicht.

Das ist der Job des erfahrenen Entwicklers. Und wer diesen Job nicht beherrscht, dem hilft der schnelle Mitarbeiter nicht – er macht alles nur schlimmer.

Die echten Gefahren

Sicherheitslücken, die niemand sieht

KI generiert Code, der funktioniert. Das heißt nicht, dass er sicher ist. Typische Sicherheitsprobleme – Eingaben, die nicht geprüft werden, Daten, die ungeschützt übertragen werden – KI reproduziert Muster aus ihrem Training. Auch die schlechten.

Technische Schulden, die niemand versteht

Wenn KI den Code schreibt und niemand ihn wirklich durcharbeitet: Was passiert in zwei Jahren, wenn etwas geändert werden muss? Man hat eine Anwendung, die niemand mehr nachvollziehen kann.

"Es funktioniert" ist nicht genug

Der gefährlichste Satz in der Softwareentwicklung ist "Es funktioniert doch." Ja, heute. Was ist morgen? Was ist, wenn sich die Anforderungen ändern? Funktionieren und wartbar sein sind zwei verschiedene Dinge.

Kopieren ohne Verstehen

KI liefert eine Lösung. Man versteht sie nicht, aber sie funktioniert. Also übernimmt man sie. Und dann die nächste. Und noch eine. Nach einem halben Jahr hat man eine Anwendung aus zusammenkopierten Teilen, die niemand mehr reparieren kann.

Was das für Unternehmen bedeutet

Wenn du ein Unternehmen führst und dein Team anfängt, KI zu nutzen – oder du überlegst, ob sie es sollten – hier ein paar Orientierungspunkte.

Die richtige Frage ist nicht: "Sollen wir KI nutzen?" Die richtige Frage ist: "Haben wir die Leute, die KI richtig nutzen können?"

Warnsignale:

"Wir sind jetzt viel schneller" ohne erkennbare Qualitätskontrolle

Niemand prüft den generierten Code ernsthaft

Keine automatisierten Tests, weil "es funktioniert ja"

Die Anwendung wächst, aber niemand kann erklären, was genau drin passiert

Gute Zeichen:

Klare Prozesse, wer KI-generierten Code prüft

Tests werden geschrieben – auch für KI-generierten Code

Entwickler können erklären, was der Code tut und warum

Technische Entscheidungen werden dokumentiert

Die unbequeme Wahrheit: KI macht gute Teams besser und schwache Teams gefährlicher. Wenn du vorher schon Qualitätsprobleme hattest, verschwinden die nicht durch KI. Sie entstehen nur schneller.

Fazit

Vibe Coding ist nicht gut oder schlecht. Es ist ein Spektrum.

Auf der einen Seite steht blindes Vertrauen in Werkzeuge, die man nicht versteht. Das ist gefährlich. Auf der anderen Seite stehen erfahrene Profis, die KI nutzen, um bessere Software schneller zu bauen. Das ist die Zukunft.

Der Unterschied ist nicht das Werkzeug. Der Unterschied ist, wer es benutzt.

Und wenn du gerade anfängst, mit KI zu arbeiten – oder dein Team es tut – dann ist die wichtigste Investition nicht das Werkzeug. Es ist das Wissen, was gute Software ausmacht. Mit oder ohne KI.

Weiterführend: Git Gud: Warum KI-Entwicklung wie Dark Souls ist – Konkrete Leitplanken aus echten Projekten

Vibe Coding: Warum der Begriff mehr schadet als hilft – und wie du KI-gestützte Entwicklung wirklich einordnest