Ein neulicher Abend, ein Pair-Programming mit einem Kollegen, der seit zehn Jahren Backends in Go baut. Er öffnet einen Tab mit einem Tool, das ihm gerade jemand empfohlen hatte. Tippt einen Satz ein. Bekommt eine kleine React-App. Drückt Run. Es funktioniert. Er sagt: „Ich verstehe, warum Leute begeistert sind. Aber wenn ich morgens vor unserem 80.000-Zeilen-Repository sitze, ist das hier eine andere Disziplin.“
Genau das ist der Punkt, an dem die Debatte um Vibe Coding meistens entgleist. Der Begriff vermischt zwei sehr unterschiedliche Dinge: eine Spielwiese für Nicht-Entwickler und einen Workflow für professionelle Softwareentwicklung. Wer beides in einen Topf wirft, redet zwangsläufig aneinander vorbei — und kommt zu falschen Schlussfolgerungen über Risiken, Produktivität und die Zukunft des Berufs.
Dieser Beitrag zieht die Linie sauber. Aus einer Perspektive, die sich seit Jahren mit dem täglichen Einsatz dieser Werkzeuge beschäftigt — nicht aus Anbietersicht, nicht aus dem Twitter-Hype, sondern aus dem realen Arbeitsalltag.
Was Vibe Coding wirklich beschreibt
Die nützlichste Definition stammt aus einer Beobachtung von Simon Willison: Vibe Coding heißt, den generierten Code bewusst nicht zu lesen. Man beschreibt das Ziel, prüft das Ergebnis funktional, und wenn es läuft, läuft es.
Das ist keine schwache Definition — sie ist die einzig saubere. Sobald ein Entwickler den Code Zeile für Zeile durchgeht, refaktoriert, Tests schreibt und Architekturentscheidungen bewusst trifft, hat er den Vibe-Coding-Modus verlassen. Dann nutzt er Sprachmodelle als Werkzeug, nicht als Quelle der Wahrheit.
Diese Unterscheidung wirkt akademisch, ist aber operationell entscheidend. In der Praxis bedeutet sie:
- Vibe Coding — Output wird funktional getestet, nicht gelesen. Verständnis ist optional.
- KI-gestützte Entwicklung — Output wird gelesen, geprüft, abgelehnt oder verbessert. Verständnis ist Pflicht.
- Agentische Workflows — Modelle führen Aufgaben weitgehend selbständig aus, der Entwickler definiert Leitplanken, Tests und Akzeptanzkriterien.
Diese drei Modi unterscheiden sich nicht nur stilistisch, sondern in den Konsequenzen für Wartbarkeit, Sicherheit, Team-Onboarding und Architekturqualität.
Warum der Begriff so eingeschlagen hat
Der Hype um Vibe Coding ist erklärbar. Erstens: Die Tools sind objektiv beeindruckend. Modelle der aktuellen Generation generieren in Sekunden funktionierende Komponenten, die vor zwei Jahren noch Stunden Recherche und Boilerplate erfordert hätten. Diese Beschleunigung ist real und sie sieht magisch aus.
Zweitens: Vibe Coding bedient das Versprechen einer demokratisierten Softwareentwicklung. Jeder kann bauen. Jeder kann seine Idee umsetzen. Das ist eine attraktive Erzählung — und für bestimmte Anwendungsfälle stimmt sie sogar.
Drittens: Der Begriff selbst ist klebrig. „Vibe Coding“ klingt nach Lifestyle, nicht nach Disziplin. Er macht eine ernsthafte Tätigkeit zugänglich, indem er sie entwertet — und genau das ist Teil der Anziehungskraft.
Der Schaden entsteht dort, wo das Versprechen auf Bereiche übertragen wird, in denen es nicht funktioniert: produktive Systeme mit echten Nutzern, Compliance-Anforderungen, Wartung über Jahre, Integration in bestehende Codebases.
Wo Vibe Coding seinen legitimen Platz hat
Es gibt Anwendungsfälle, in denen Vibe Coding nicht nur akzeptabel, sondern eine echte Effizienzgewinn-Strategie ist.
Prototypen mit klarem Verfallsdatum
Ein Konzept-Demo für einen Pitch, ein Mockup für ein Stakeholder-Gespräch, eine Visualisierung einer Idee — wenn von vornherein klar ist, dass dieser Code nie in Produktion geht, ist die Lesepflicht überflüssig. Wichtig ist nur: Das Verfallsdatum muss tatsächlich gelten. Prototypen, die „nur kurz“ produktiv gehen, werden zur größten technischen Schulquelle, die ich kenne.
Persönliche Tools mit einem Nutzer
Ein Skript, das Sie selbst zweimal pro Woche laufen lassen, ein lokales Dashboard, ein Helper-Tool für Ihren Workflow — hier ist der einzige Nutzer auch der einzige Maintainer. Wenn es kaputt geht, schreiben Sie es neu. Das ist ökonomisch sinnvoll.
Lernen durch Spielen
Wer einen Eindruck bekommen will, wie eine Technologie funktioniert, kann mit Vibe Coding sehr schnell ein Gefühl entwickeln. Das ersetzt kein systematisches Lernen, aber es senkt die Hürde für den ersten Kontakt. Ehrlich gesagt: Es ist ein besserer Einstieg als die meisten Tutorials.
Einmalige Datenverarbeitung
CSV-Transformation, einmaliges Migrationsskript, Ad-hoc-Analyse — typische Bereiche, in denen die Frage nach Wartbarkeit irrelevant ist. Hier ist die Beschleunigung durch generierten Code echter Mehrwert.
In all diesen Szenarien gilt eine harte Regel: Der Code darf nicht in einer Umgebung landen, in der ihn jemand anderes pflegen müsste, ohne ihn gelesen zu haben.
Wo Vibe Coding nicht hingehört
Hier wird die Position konkret — und sie ist eindeutig. Wer in den folgenden Kontexten Vibe-Coding-Output ungelesen in Produktion bringt, handelt fahrlässig. Nicht im moralischen Sinn, sondern im technischen.
Bestehende Codebases mit Team-Eigentum
Sobald mehr als eine Person den Code pflegen muss, ist die Lesepflicht nicht verhandelbar. Jede ungelesene Zeile ist eine Schuld, die jemand anderes mit Zinsen begleichen wird — meistens unter Zeitdruck, wenn ein Bug auftaucht.
Code mit Datenfluss aus dem Internet
User-Input, API-Daten, Datei-Uploads, Webhooks — alles, was nicht aus einer kontrollierten Quelle kommt, ist Angriffsfläche. Modelle generieren oft funktionierenden Code mit klaffenden Sicherheitslücken: fehlende Input-Validierung, SQL-Injection-Anfälligkeit, unsichere Deserialisierung, fehlende Authentifizierung an exponierten Endpoints. Das fällt im funktionalen Test nicht auf — bis es jemand ausnutzt.
Persistenzschicht und Migrationen
Datenbankschemata, Migrationen, Indexstrategien sind Bereiche, in denen falsche Entscheidungen sich erst Monate später rächen, dann aber teuer. Ein Modell, das ein hübsches CREATE TABLE generiert, hat nicht den Kontext, um zu wissen, dass diese Tabelle in zwei Jahren 80 Millionen Zeilen haben wird.
Zahlungs- und Auth-Logik
Hier reicht ein subtiler Fehler, um echtes Geld oder echte Konten zu verlieren. Ungelesener Output in diesen Bereichen ist nicht produktivitätsgewinnend, sondern existenzgefährdend.
Code mit regulatorischer Relevanz
DSGVO, Buchhaltungspflichten, branchenspezifische Vorgaben, EU AI Act — überall dort, wo die Software einer externen Prüfung standhalten muss, braucht es nachvollziehbare Entscheidungen. „Das hat die KI generiert“ ist keine Antwort, mit der man durch einen Audit kommt.
Die Verwechslung, die fast jede Hype-Debatte zerstört
Die produktivsten Diskussionen über KI in der Entwicklung scheitern an einer einzigen Verwirrung: Die Begeisterung der einen Seite und die Skepsis der anderen meinen nicht dasselbe.
Wer sagt, KI mache ihn doppelt so schnell, meint typischerweise ein Setup mit gut konfiguriertem Editor-Plugin, Repository-Kontext, Test-Suite und einer Disziplin im Prompt- und Review-Workflow. Das ist keine Vibe — das ist Engineering mit besserem Werkzeug.
Wer sagt, KI produziere unbrauchbaren Code, hat oft entweder unrealistische Erwartungen (ein Prompt, ein perfektes System) oder die andere Seite des Spektrums gesehen: ungeprüfter Vibe-Coding-Output in einem Kontext, der ihn nicht trägt.
Diese Bezeichnung könnte schärfer sein. „Vibe Coding“ für den nicht-lesenden Modus, „assistierte Entwicklung“ für den Werkzeug-Modus, „agentische Entwicklung“ für autonome Aufgabenketten mit klaren Leitplanken. Dass sich dieser Sprachgebrauch nicht durchgesetzt hat, ist Teil des Problems.
Wie ein produktiver KI-Workflow für Entwickler tatsächlich aussieht
Wer in einem ernsthaften Projekt arbeitet, profitiert massiv von Sprachmodellen — aber anders, als der Twitter-Diskurs suggeriert. Ein paar Muster, die in der Praxis tragen.
Tests vor Code
Wer das Modell zuerst die Tests schreiben lässt und dann den Code, hat ein eingebautes Korrektiv. Die Tests sind menschlich lesbar, formulieren das gewünschte Verhalten und sind unabhängig vom konkreten Output. Wenn der Code nicht durchläuft, ist die Schleife klar.
Kleine, abgegrenzte Aufgaben
Ein Modell, das eine isolierte Funktion implementieren soll, liefert konsistent gute Ergebnisse. Ein Modell, das „bitte die ganze Feature-Pipeline“ bauen soll, scheitert vorhersagbar. Aufgaben so schneiden, dass jede einzelne in eine geprüfte Mini-PR passt, ist der wichtigste Skill im KI-Workflow.
Repository-Kontext aktiv steuern
Moderne Tools können große Codebases lesen — aber nur das, was man ihnen explizit gibt. Wer pauschal ganze Verzeichnisse einspielt, bekommt Antworten, die wahrscheinlich klingen, aber an internen Konventionen vorbei gehen. Bessere Strategie: gezielt die zwei bis fünf Dateien einspielen, die wirklich relevant sind.
Refactoring als Strapazfähigkeitstest
Modelle generieren oft Code, der funktioniert, aber strukturell mittelmäßig ist. Eine produktive Routine: Erstes Ergebnis akzeptieren, dann gezielt nach Strukturproblemen fragen — „Wo bist du mit dieser Lösung nicht zufrieden? Wo wäre eine kleinere oder klarere Version möglich?“ Die Antworten sind häufig erstaunlich präzise.
Dokumentation und Erklärung
Eine der unterschätzten Stärken: Sprachmodelle erklären fremden Code zuverlässig gut. Beim Einstieg in eine neue Codebase ist das Lesen mit Modell-Begleitung eine deutliche Beschleunigung — vorausgesetzt, der Entwickler liest selbst weiter und nimmt die Erklärung nicht als Wahrheit.
Modellwahl bewusst treffen
Nicht jedes Modell ist für jede Aufgabe richtig. Schnelle, kleinere Modelle für Boilerplate und Routine; größere, teurere Modelle für komplexe Algorithmik und Architektur. Wer ein Sonnet-Modell für Tippfehlerfixes nutzt, verbrennt Geld; wer ein Haiku-Modell auf eine Migrations-Strategie wirft, bekommt mittelmäßige Antworten.
Die unsichtbaren Kosten des Vibe-Stils
Wenn Vibe Coding in falschen Kontexten eingesetzt wird, treten die Kosten zeitversetzt auf — und sind dann höher als der ursprünglich eingesparte Aufwand.
- Onboarding-Aufwand für neue Teammitglieder — wer eine Codebase ohne erkennbare Konventionen und ohne nachvollziehbare Entscheidungen übernimmt, braucht länger, um produktiv zu werden
- Höhere Fehlerquote bei Erweiterungen — wer Code ändert, den er nicht versteht, bricht häufiger versteckte Annahmen
- Sicherheitsschulden — Lücken, die im ersten Audit auffallen, hätten in der Code-Review der Generierung sofort auffallen können
- Modellabhängigkeit — Codebases, die nur mit dem Modell verstanden werden können, das sie generiert hat, sind funktional gesperrt
- Vendor-Drift — ein Tool, das heute super funktioniert, kann morgen die Preisstruktur ändern oder vom Markt gehen
Diese Posten gehören in jede Diskussion zum Thema. Wer den Sales-Pitch hört, hört davon selten etwas.
Eine ehrliche Position
Sprachmodelle sind das einschneidendste Werkzeug, das in den letzten zwanzig Jahren in die Softwareentwicklung gekommen ist. Wer sie nicht einsetzt, lässt einen sehr großen Produktivitätsgewinn liegen. Wer sie unkritisch einsetzt, baut Schuldscheine, die später jemand einlöst.
Die produktive Mitte ist keine geheime Kunst. Sie besteht aus zwei Sätzen: Lies, was du in Produktion bringst. Behandle das Modell als sehr schnellen, sehr fleißigen, manchmal unzuverlässigen Pair-Programmer — nicht als Quelle der Wahrheit.
Wer diesen Grundsatz hält, kann fast alle Vorteile mitnehmen und fast alle Risiken vermeiden. Wer ihn aufgibt, weil es so schön schnell geht, lernt die Lektion früher oder später auf die teure Tour.
Fazit
Vibe Coding ist ein gutes Wort für eine schlechte Praxis — wenn man es als ungelesenen Akzeptanztest-Stil versteht. Es hat seinen Platz: Prototypen, Wegwerf-Skripte, persönliche Tools, erste Schritte in einer neuen Technologie. In diesem Rahmen ist es ein produktives Werkzeug.
Außerhalb dieses Rahmens ist es eine Methode, mit der Teams Schulden schneller produzieren als sie sie abbauen können. Die Branche tut sich keinen Gefallen, wenn sie diesen Modus als Standardweg der KI-Entwicklung verkauft.
Die ehrliche Empfehlung für jeden, der professionell Software baut: Nutzen Sie Sprachmodelle täglich, intensiv und mit Disziplin. Lesen Sie, was sie produzieren. Testen Sie, was sie behaupten. Behandeln Sie sie wie einen sehr begabten Junior, der schnell lernt — und manchmal selbstbewusst Unsinn schreibt. Mit dieser Haltung sind die Werkzeuge ein massiver Hebel. Ohne sie wird Vibe Coding zu der Falle, vor der die nüchterneren Stimmen seit zwei Jahren warnen.
