Vibe Coding ist genau in einem Kontext legitim: wenn Sie einen Prototyp bauen, den Sie wegwerfen wollen.
Das Problem ist, dass die meisten vibe-codierten Systeme nicht weggeworfen werden. Sie laufen. Sie akkumulieren Nutzer. Sie werden zu dem System, das gewartet, erweitert und debuggt werden muss von Personen, die es nicht geschrieben haben und die AI nicht bitten können, ihre Entscheidungen im Kontext zu erklären. Die Codebasis weiß nicht, dass sie temporär sein sollte.
Das ist keine Kritik an der Nutzung von AI, um Code schnell zu generieren. Es ist eine Beschreibung dessen, was passiert, wenn Sie eine Prototyp-Strategie auf eine Produktionsumgebung anwenden.
Was Vibe Coding tatsächlich ist
Vibe Coding ist das Generieren von Code durch Beschreibung von Absicht, Akzeptieren von dem, was richtig aussieht, Iterieren bis etwas funktioniert, ohne jede Zeile zu lesen oder jede Entscheidung zu verstehen. Der Feedback-Loop ist: Läuft es, sieht es richtig aus, funktioniert das Feature im Happy Path. Wenn die Antwort ja ist, wird der Code geliefert.
Dieser Ansatz ist für spezifische Zwecke wirklich nützlich. Ein Proof-of-Concept für die Stakeholder-Ausrichtung. Ein Design-Spike, um zu testen, ob eine API nutzbar ist, bevor man sich auf die Integration festlegt. Eine wegwerfbare Erkundung eines Frameworks, das man noch nie berührt hat. Generieren von Boilerplate, die Zeile für Zeile überprüft wird, bevor sie die Produktion erreicht.
In all diesen Fällen ist das Artefakt ein Kommunikationswerkzeug oder ein Lerngerät, kein Produktionssystem. Die Austrittsbedingung ist “das ist gut genug für das Gespräch”, nicht “das ist bereit für Nutzer.”
Wenn vibe-codierte Systeme ohne explizite Unterscheidung in die Produktion eintreten, tragen sie Schulden, die sich häufen. Die Entscheidungen, die nie bewusst getroffen wurden, werden zu Einschränkungen, die der nächste Ingenieur erbt. Die Edge Cases, die nie berücksichtigt wurden, werden zu den Bugs, die um 2 Uhr morgens erscheinen.
Das Jagged-Edge-Problem im Maßstab
AI-Coding-Agents sind nicht gleichmäßig fähig. Sie zeichnen sich bei ausgetretenen Mustern aus: CRUD-Endpunkte, UI-Komponenten, Datentransformation, Boilerplate-Konfiguration. Sie versagen unvorhersehbar bei neuartigen Architekturentscheidungen, Cross-System-State-Management, Security-Edge-Cases, Performance-Charakteristika im Maßstab und domänenspezifischer Korrektheit.
Das ist der Jagged Edge. Die Selbstsicherheit des agents ist gleichmäßig, auch wenn seine Zuverlässigkeit es nicht ist. Er schreibt sicherheitsnahen Code mit demselben Ton, den er für eine Utility-Funktion verwendet. Er behandelt ein neuartiges Concurrency-Muster mit derselben scheinbaren Gewissheit, die er beim Schreiben einer for-Schleife mitbringt.
Vibe Coding verstärkt den Jagged Edge im Maßstab. Ein System wächst in die Richtungen, die der agent gut handhabt, die auch die Richtungen sind, die sich reibungslos und schnell anfühlen, bis es auf eine Grenze trifft, die der agent nicht navigieren kann. Zu diesem Zeitpunkt ist die Grenze in der Produktion eingebettet, umgeben von Code, der auf den selbstsicheren, aber falschen Annahmen des agents aufgebaut wurde.
Der Jagged Edge ist kein Grund, AI-Coding-Tools zu vermeiden. Er ist ein Grund, menschliche Aufsicht an den spezifischen Punkten aufrechtzuerhalten, an denen die agent Zuverlässigkeit sinkt: Sicherheitsentscheidungen, performance-kritische Pfade, neuartige Domänenlogik, Cross-System-State.
Das Agentive Paradigma und seine Disziplin
Software wurde in Begriffen aufeinanderfolgender Programmierparadigmen beschrieben. Das erste: Explizite Anweisungen, von Menschen für deterministische Ausführung geschrieben. Das zweite, von Karpathy als Software 2.0 beschrieben: Verhalten kompiliert in neuronale Netzwerkgewichte aus Daten und Zielen, wo das Programm in den Gewichten ist, nicht in von Menschen geschriebenem Code.
Das dritte, was als agentives Paradigma bezeichnet wurde, erweitert das weiter: Systeme, bei denen das Programm zunehmend im Prompt, dem Kontext und den Tools liegt, mit einem Sprachmodell als Runtime. Die Codebasis ist immer noch Code, aber das Verhalten des Systems wird durch Kontext genauso wie durch Anweisungen geprägt.
Vibe Coding ist dieses Paradigma ohne Disziplin. Der Prompt ersetzt die Spezifikation. Der LLM ersetzt den Architekten. Das Gefühl von “es funktioniert” ersetzt die Testsuite.
Agentives Engineering wendet Disziplin auf dasselbe Paradigma an: Explizite Spec vor der Generierung, verifizierbare Akzeptanzkriterien, Testabdeckung im Besitz von Menschen, nicht an das Urteil des agents delegiert, Observability vor dem Go-Live, menschliche Review-Gates an architektonischen Entscheidungspunkten.
Die Disziplin verlangsamt das Paradigma nicht. Sie ist das, was das Paradigma im Produktionsmaßstab vertrauenswürdig macht.
Was Agentives Engineering hinzufügt
Agentives Engineering ist kein schnelleres Vibe Coding. Es ist dieselbe AI-gestützte Code-Generierung mit den Elementen, die Vibe Coding überspringt, bewusst angewendet.
Scope-Definition: was der agent bauen wird, was er nicht bauen wird, welche Dateien er berühren wird und welche nicht. Diese Grenze verhindert die Ausbreitung, die vibe-codierte Systeme unwartbar macht.
Annahmen-Aufzeigen: Der agent legt seine Interpretation dar, bevor er sie implementiert. Eine dreißigsekündige Klärung vor dem ersten Code-Block verhindert eine zweistündige Überarbeitung danach.
Worktree-Isolation: Der agent arbeitet in einem Branch, nicht auf main. Der Diff ist sichtbar und überprüfbar, bevor ein Mensch ihn akzeptiert.
Test-first-Disziplin: Der Akzeptanztest ist vor dem Beginn der Implementierung definiert. Der Test ist der Vertrag zwischen dem, was angefordert wurde, und dem, was geliefert wurde.
Adversariales Review vor dem Merge: Ein zweiter Durchlauf, bevor die Änderung die Produktion erreicht, auf das, was schiefgehen könnte. Kein bürokratisches Gate. Eine strukturierte Suche nach dem Fehler-Modus, an den niemand in der Planungsphase gedacht hat.
Observability von Tag eins: Logs und Alerts sind instrumentiert, bevor das Feature live geht, nicht hinzugefügt, wenn der erste Bug-Report eintrifft.
Rollback-Plan: Vor dem Deployment gibt es eine explizite Antwort auf “Was tun wir, wenn das in der Produktion scheitert?”
Teams, die agentives Engineering praktizieren, liefern in Monat zwei, Monat drei und darüber hinaus schneller als Vibe Coder. Nicht weil agentives Engineering mehr Code pro Stunde produziert. Weil es weniger Nacharbeit pro Monat produziert.
Wann Vibe Coding das richtige Tool ist
Die legitimen Einsatzbereiche sind real und es lohnt sich, sie zu benennen.
Design Spike: Sie müssen wissen, ob ein technischer Ansatz machbar ist, bevor Sie in ihn investieren. Einen Prototyp vibe-coden, das Ergebnis beobachten, wegwerfen oder die Erkenntnisse extrahieren.
Wegwerfbare Demo: Sie müssen einem Stakeholder zeigen, wie ein Feature aussehen könnte. Die Demo ist nicht das Produkt.
Lern-Erkundung: Sie machen sich mit einer API, einem Framework oder einer Domäne vertraut, in der Sie noch nicht gearbeitet haben. Der Output ist Wissen, keine Produktionssoftware.
Boilerplate-Scaffolding: Der generierte Code wird Zeile für Zeile überprüft, bevor er die Produktion berührt.
Die Austrittsbedingung für vibe-codierten Code, der in die Produktion eingeht, ist explizit: Architekturüberprüfung, um zu bestätigen, dass er den System-Konventionen entspricht; Security-Check für Injection-Punkte oder exponierte Anmeldeinformationen oder Auth-Lücken; Testabdeckung aus einer von Menschen geschriebenen Suite, die das Verhalten validiert; Observability, um zu bestätigen, dass was der Code in der Produktion tut, sichtbar ist.
Eine praktische Heuristik: Wenn Sie einem Kollegen nicht erklären können, was eine vibe-codierte Funktion tut und warum sie so funktioniert, ist sie nicht bereit für die Produktion. Die Unfähigkeit, es zu erklären, ist kein Zeichen dafür, dass der Code zu komplex ist. Es ist ein Zeichen dafür, dass Entscheidungen getroffen wurden, ohne verstanden zu werden.
Der echte Produktivitätsgewinn liegt in der Spezifikationsqualität
Die Teams, die mit AI-gestütztem Coding gewinnen, sind nicht jene, die am wenigsten Code schreiben. Sie sind jene, die die besten Spezifikationen schreiben.
AI-Coding-Tools komprimieren die Lücke zwischen Spezifikation und laufendem Code. Sie eliminieren nicht die Anforderung an eine gute Spezifikation. Eine gut spezifizierte Aufgabe, die einem agent unter Guardrails übergeben wird, produziert schnell produktionsreifen Code. Eine schlecht spezifizierte Aufgabe, die demselben agent übergeben wird, produziert selbstsicheren Code, der neu geschrieben werden muss.
Die Spezifikation beinhaltet, was die Komponente tut, was sie nicht tut, welche Inputs sie verarbeitet, welche Fehler-Modi existieren und wie Erfolg gemessen wird. Das ist kein Dokumentations-Overhead. Es sind die Informationen, die der agent benötigt, um beim ersten Durchlauf statt beim dritten korrekten Output zu produzieren.
Teams, die in Spezifikationsqualität investieren, erhalten Compound-Renditen von AI-Coding. Teams, die vibe-coden, akkumulieren Compound-Schulden. Beides sieht in Monat eins wie Produktivität aus. In Monat sechs ist der Unterschied sichtbar in der Cycle-Time zwischen Anforderung und Produktion, in der Größe des Backlogs, das eigentlich Nacharbeit ist, und in der Zuversicht der Ingenieure, die in der Codebasis arbeiten.
Die Verschiebung in der Rolle des Ingenieurs ist real: vom Schreiber zum Spezifizierer, Reviewer und Domain-Experten, der weiß, wann der agent zu übersteuern ist. Die Ingenieure, die diese Verschiebung machen, sind schneller. Jene, die AI-Coding als schnelleres Tippen behandeln, arbeiten härter, um auf der Stelle zu bleiben.
Die Frage ist nicht, ob AI zur Code-Generierung verwendet werden soll. Es ist, ob die Spezifikation existiert, die Tests im menschlichen Besitz sind und die Produktionscheckliste vor dem Deployment ausgeführt wird.
Verwandte Artikel: Claude Code ist kein Copilot. Es ist ein Delivery-System. und Die vier Guardrails, die AI-Coding von AI-Shipping trennen