Vibe Coding und Produktion: Überlebenshandbuch für IT-Entscheider

Vibe Coding und Produktion: Überlebenshandbuch für IT-Entscheider

Von einem Senior Product Manager, Praktiker der KI-gestützten Produktion

Präambel: ein semantisches Missverständnis ausräumen

Zunächst gilt es, einen Begriff zu klären, der sowohl in Führungskreisen als auch in Technikteams für Verwirrung sorgt. Vibe Coding ist nicht gleichbedeutend mit intensiver Nutzung künstlicher Intelligenz zur Codegenerierung. Cursor, Copilot oder Claude zu nutzen, um den Großteil der Codezeilen zu schreiben und dabei in einer engen Rückkopplungsschleife mit dem Modell zu bleiben, jeden Vorschlag zu lesen, zu validieren und zu korrigieren, ist eine inzwischen alltägliche Praxis der Entwicklungsunterstützung. Das ist kein Vibe Coding.

Die maßgebliche Definition, formuliert von Andrej Karpathy, ist weit radikaler: Vibe Coding bedeutet, sich von den Schwingungen tragen zu lassen, die Exponentialkurve zu umarmen und zu vergessen, dass der Code existiert. Der Schlüsselbegriff, der die Aufmerksamkeit jedes Entscheiders verdient, ist der letzte: vergessen, dass der Code existiert.

Dieser Paradigmenwechsel ist kein kosmetisches Detail. Er definiert das Verhältnis zwischen Ingenieur und Artefakt neu und verändert damit die Governance der Informationssysteme, die Sie führen.

Warum Vibe Coding IT-Verantwortliche interessieren muss

Die anfängliche Demokratisierung des Vibe Coding hat gemischte Ergebnisse hervorgebracht. In der Erfolgsspalte finden sich Videospiele, Prototypen, persönliche Projekte, also Objekte, bei denen Fehler tolerierbar sind. In der Desasterspalte finden sich Anwendungen, die von Neulingen in Produktion gebracht wurden, mit dem vorhersehbaren Gefolge: exponierte API-Schlüssel, umgangene Authentifizierungssysteme, gesprengte Kontingente, durch sorglose Injektionen verschmutzte Datenbanken. Vibe Coding schien damit auf Freizeitnutzung oder bestenfalls Exploration beschränkt.

Warum also sollten Sie sich als IT-Entscheider mit einer Praxis befassen, die scheinbar Amateuren oder Prototypen mit geringem Einsatz vorbehalten ist?

Die Antwort passt in ein Wort: die Exponentialkurve.

Die Länge der Aufgaben, die KI eigenständig erledigen kann, verdoppelt sich alle sieben Monate. In diesem Tempo ist Vibe Coding keineswegs nötig: Sie können Ihren Ingenieur Claude Code oder Cursor an einer Funktionalität arbeiten lassen und anschließend das Ergebnis vollständig gegenlesen. Die Prüfkosten bleiben im Verhältnis zum Produktivitätsgewinn vertretbar.

Doch blicken wir voraus. In zwölf Monaten, in vierundzwanzig Monaten, wenn diese Systeme das Äquivalent eines ganzen Arbeitstages und dann einer Woche in einer einzigen Inferenz erzeugen, wird es materiell unmöglich, im Lockstep mit der Maschine zu bleiben. Der Ingenieur, der jede Zeile lesen will, wird zum Engpass seiner Organisation. Die Verweigerung der Anpassung wird bezahlt, nicht mit technischer Schuld, sondern mit Wettbewerbsfähigkeit.

Die Gründungsanalogie: die Compiler

Um zu erfassen, worum es geht, hilft ein historischer Umweg. Zu Beginn der Compiler misstrauten viele Entwickler ihnen. Sie nutzten den Compiler zwar, lasen aber systematisch den erzeugten Assembler gegen, um sicherzugehen, dass er dem entsprach, was sie selbst geschrieben hätten. Diese Praxis, in einer Phase der Akkulturation legitim, wurde schnell untragbar: Die Systeme wurden zu groß, als dass ein vollständiges Gegenlesen des Assemblers wirtschaftlich zu rechtfertigen gewesen wäre.

Heute wissen wir alle, dass unter der Haube Assembler steckt. Doch kaum ein Anwendungsingenieur liest ihn. Wir bauen robuste Software, ohne diese Schicht zu inspizieren. Wir haben prüfbare Abstraktionsebenen gefunden, die uns von der Inspektion des Substrats befreien.

Die These für Entscheider lautet: Wir werden vergessen, dass der Code existiert, aber wir werden nie vergessen, dass das Produkt existiert. Die Herausforderung der nächsten Jahre besteht darin, die methodischen Bedingungen dieses delegierten Vertrauens zu schaffen, genau wie wir gemeinsam die Bedingungen des Vertrauens in Compiler geschaffen haben.

Ein Problem so alt wie die Zivilisation

Es lohnt sich, auf einen Punkt zu beharren, den Ingenieure als individuelle Beitragende kulturell oft schwer akzeptieren: Eine Expertise zu führen, die man selbst nicht beherrscht, ist eines der ältesten Probleme menschlicher Organisation.

• Wie überwacht ein technischer Leiter einen Experten in einem Bereich, in dem er selbst kein Experte ist?
• Wie validiert ein Product Manager eine Funktionalität, ohne den gesamten zugrunde liegenden Code zu lesen?
• Wie prüft ein Geschäftsführer die Arbeit seines Buchhalters, ohne selbst Buchhalter zu sein?

Diese Fragen haben erprobte Antworten, teils seit Jahrhunderten:

• Der CTO schreibt Abnahmetests, die das erwartete Verhalten des Systems validieren, ohne seine Implementierung vorauszusetzen.
• Der Product Manager nutzt das Produkt und stellt sicher, dass es wie spezifiziert funktioniert, ohne den Code gegenzulesen.
• Der Geschäftsführer zieht Stichproben von Kontrollpunkten, die er beherrscht, prüft Datenausschnitte und baut so ein aggregiertes Vertrauen in das Finanzmodell auf.

Diese Verfahren sind keine managementale Blindheit: Sie sind die Kunst der prüfbaren Abstraktionsebenen. Jede kompetente Führungskraft praktiziert diese kontrollierte Delegation bereits. Neu ist für Softwareingenieure, dass sie sie auf den eigenen Beruf anwenden müssen.

Der einzige aktuelle blinde Fleck: die technische Schuld

Seien wir ehrlich: Es gibt heute eine methodische Grenze des Vibe Coding in Produktion, und diese Grenze heißt technische Schuld. Anders als funktionale Korrektheit, Stabilität oder Sicherheit, die alle durch externe Tests messbar sind, lässt sich technische Schuld nur durch das Lesen des Codes wirklich messen. Es gibt heute keine verlässliche Abstraktionsmetrik, die ohne erfahrene menschliche Inspektion erkennt, dass ein vibe-gecodetes Modul Entwurfsentscheidungen anhäuft, die künftige Entwicklungen belasten.

Diese Grenze entwertet Vibe Coding nicht. Sie begrenzt seinen Anwendungsbereich.

Die Strategie der Blattknoten: eine Doktrin für Entscheider

Die operative Antwort auf diese Grenze ist einfach: Vibe Coding auf die Blattknoten Ihrer Architektur konzentrieren.

Im Abhängigkeitsbaum eines Softwaresystems unterscheidet man:

• Stämme und tragende Äste: grundlegende Schichten, auf denen andere Komponenten aufbauen. Datenarchitektur, Authentifizierungssysteme, Service-Orchestrierung, gemeinsam genutzte interne APIs. Das ist der Kern, den Ihre Ingenieure weiterhin in der Tiefe beherrschen müssen, denn diese Zonen entwickeln sich, werden erweitert, und jede Schuld vervielfacht sich dort.

• Blattknoten: endständige Funktionalitäten, von denen nichts abhängt. Spezifische Benutzeroberflächen, Exportskripte, Ad-hoc-Berichte, periphere Integrationen, One-Shot-Konnektoren. Lagert sich dort technische Schuld ein, ist sie eingegrenzt. Diese Zonen ändern sich wenig, dienen nicht als Fundament für anderen Code, und ihre eventuelle Neufassung bleibt lokal.

Die strategische Empfehlung lautet daher: Erlauben Sie Vibe Coding dort, wo die Schuld architektonisch eingegrenzt ist, verbieten Sie es im tragenden Kern, und investieren Sie in eine explizite Kartografie dieser Grenze. Diese Kartografie ist heute ein Governance-Artefakt von gleicher Bedeutung wie Ihr Zielarchitektur-Bild.

Fallstudie: ein Pull Request mit 22.000 Zeilen, gelassen gemergt

Ein jüngeres Ereignis veranschaulicht die Machbarkeit dieser Doktrin im industriellen Maßstab. Bei Anthropic wurde eine Änderung von 22.000 Zeilen in eine Produktions-Codebasis für Reinforcement Learning integriert, deren Code weitgehend von Claude selbst geschrieben wurde.

Wie konnte eine solche Operation verantwortungsvoll durchgeführt werden? Vier Prinzipien wurden konsequent angewandt:

1. Eine massive menschliche Vorleistung. Es handelte sich nicht um einen einzelnen Prompt mit anschließendem Merge. Mehrere Arbeitstage flossen in die Erarbeitung der Anforderungen, die iterative Steuerung des Modells und die Spezifikation des Zielsystems.

2. Konzentration auf die Blattknoten. Der Großteil der Änderung betraf periphere Zonen, bei denen es akzeptabel war, dass sie einen Teil technischer Schuld tragen, weil sie kein Fundament für weitere Entwicklungen bildeten.

3. Intensive menschliche Review in den tragenden Teilen. Die wenigen Komponenten, die erweiterbar bleiben mussten, wurden von erfahrenen Ingenieuren Zeile für Zeile gegengelesen.

4. Explizites Design für Prüfbarkeit. Belastungstests wurden im Voraus entworfen, das System wurde um menschlich prüfbare Ein- und Ausgaben herum architektiert, sodass Kontrollpunkte unabhängig vom Lesen des Codes existieren.

Das Ergebnis: ein Vertrauen in diese Änderung, das dem für jede andere Änderung der Codebasis entspricht, aber in einem Bruchteil der Zeit geliefert wurde, die eine vollständige manuelle Erstellung mit anschließender umfassender Review erfordert hätte.

Noch interessanter für Entscheider: der Sogeffekt auf die Produktstrategie. Wenn die Grenzkosten einer Funktionalität von zwei Wochen auf einen Tag sinken, ändert sich die Portfolio-Rechnung. Zuvor als zu teuer verworfene Projekte werden trivial. Man macht nicht nur dasselbe schneller: Man macht Dinge, die man nie erwogen hätte.

Das PM-Handbuch für Claude: operative Methodik

Das Mantra, das ich allen Teams in diesem Übergang empfehle: "Frag nicht, was Claude für dich tun kann, frag, was du für Claude tun kannst."

Wenn Sie vibe coden, sind Sie kein Ingenieur mehr, sondern Product Manager für eine KI. Das erfordert einen tiefgreifenden Kulturwandel.

Kontext ist der neue Code

Die Versuchung ist groß, die KI wie einen Chatbot zu behandeln: eine kurze Anfrage, ein schneller Fix, eine in drei Zeilen bestellte Funktionalität. Diese Praxis aus den ersten Chatbot-Interaktionen ist kontraproduktiv, sobald die Einsätze steigen.

Stellen Sie sich vor: Wenn ein neuer Ingenieur in Ihr Team käme, würden Sie ihm am ersten Tag mit einem einzigen Satz Briefing eine Funktionalität anvertrauen? Natürlich nicht. Sie würden ihm die Codebasis zeigen, die Architekturvorgaben, die internen Konventionen, die nicht-funktionalen Anforderungen, die bekannten Randfälle beschreiben.

Genau das muss der Vibe Coder mit Claude tun. Fünfzehn bis zwanzig Minuten Kontexterfassung vor dem Ausführungs-Prompt sind eine normale Investition. Diese Phase nimmt oft die Form eines separaten Vorgesprächs an, in dem die KI die Codebasis erkundet, betroffene Dateien identifiziert und Muster findet. Das Ergebnis dieser Phase ist ein dokumentierter Plan, der anschließend entweder in einer neuen Sitzung oder als Ausführungsanweisung in das Modell injiziert wird.

Die empirische Erfahrung zeigt, dass dieses Protokoll die Erfolgsquote ehrgeiziger Aufgaben radikal erhöht.

Nicht übersteuern

Paradoxerweise gilt: So entscheidend der Kontext ist, so sehr sollte man sich vor Überregulierung hüten. Aktuelle Modelle liefern ihre besten Ergebnisse, wenn der Rahmen klar, aber nicht käfigartig ist. Wo das Wie gleichgültig ist, lassen Sie dem Modell Freiheit. Wo Sie eine starke architektonische Präferenz haben, werden Sie explizit. Denken Sie an einen kompetenten Junior: weder Mikromanagement noch Vernachlässigung.

Test-driven Development neu gedacht

Testgetriebene Entwicklung (TDD) erlebt hier einen zweiten Frühling. Doch Vorsicht vor einer klassischen Falle: Sich selbst überlassen, neigt die KI zu Tests, die zu eng an die Implementierung gekoppelt sind und bei der kleinsten Änderung brechen. Die Abhilfe: Seien Sie in der Form vorschreibend und verlangen Sie explizit drei End-to-End-Tests, einen Normalfall, zwei Fehlerfälle, auf Verhaltensebene. Diese Minimierung macht die Tests menschlich lesbar und ist oft der einzige Teil des Codes, den der Vibe Coder tatsächlich inspiziert.

Kompaktierung und Kontext-Hygiene

Bei langen Sitzungen ist die Verschlechterung der Kohärenz (erratische Umbenennungen, Konventionsdrift) ein reales Problem. Die gute Praxis: die Sitzung an natürlichen Haltepunkten kompaktieren, wie es ein Mensch vor der Mittagspause täte. Ein bewährter Workflow: Claude in der Erkundungsphase einen dokumentierten Plan erzeugen lassen, kompaktieren, dann die Ausführung auf Basis dieses Dokuments angehen. Diese Mechanik reduziert eine Konversation von 100.000 Tokens auf einige Tausend, ohne das Wesentliche zu verlieren.

Welche Produkte sollte man bauen?

Für Plattformbetreiber und Entscheider zeichnet sich eine große strategische Chance ab: Systeme, deren Fehlerfreiheit formal bewiesen werden kann. Frameworks, in denen sensible Teile (Authentifizierung, Zahlung, Persistenz) vorgebaut und verriegelt sind, sodass dem Vibe Coder eine klar begrenzte Sandbox für seine funktionale Schicht bleibt.

Das archetypische Beispiel existiert bereits: die Claude-Artefakte, in denen generierter Code in einer eingeschränkten Frontend-Umgebung ohne Backend, ohne Secrets und ohne nennenswerte Angriffsfläche läuft. Doch hier ist ein ganzer Markt zu erfinden: BaaS (Backend as a Service), die Vibe Coding absorbieren, ohne jede Anwendung in einen Sicherheitsschweizerkäse zu verwandeln. Das ist wohl einer der vielversprechendsten Investitionsachsen der nächsten Jahre.

Die Exponentialkurve umarmen: was das wirklich bedeutet

Das letzte Prinzip, embrace exponentials, ist das am schlechtesten verstandene. "Die Modelle werden besser" ist eine schwache, fast triviale Lesart. Die starke Lesart ist weit anspruchsvoller: Die Modelle werden schneller besser, als wir es uns vorstellen können.

Zurück zur Gründungsintuition. Ein Ingenieur der 1990er mit wenigen Kilobyte RAM hätte sich kaum eine Welt vorstellen können, in der persönliche Rechner Terabytes beherbergen. Das ist nicht Faktor zwei oder vier: Das ist Faktor eine Million. Genau das erzeugt exponentielles Wachstum über zwanzig Jahre.

Die gute strategische Frage ist daher nicht "Was tun wir, wenn die Modelle in zwei Jahren doppelt so gut sind?", diese Frage ist zu klein. Die gute Frage ist: "Welche Organisation, welche Prozesse, welche Architektur werden wir gebaut haben, um gegenüber Modellen relevant zu bleiben, deren Fähigkeiten sich um Größenordnungen vervielfacht haben?"

Empfehlungen für Entscheider

Zur Beachtung für technische Leiter, IT-Leiter und Produktverantwortliche, die diesen Artikel lesen, hier die prioritären Handlungsachsen:

1. Kartografieren Sie Ihre Blattknoten explizit. Erstellen Sie ein Governance-Dokument, das den unantastbaren architektonischen Kern von den für Vibe Coding geeigneten Randzonen unterscheidet. Machen Sie daraus ein lebendes Artefakt, das jedes Quartal überarbeitet wird.

2. Investieren Sie in Prüfbarkeit. Automatisierte Sicherheitsaudits, Belastungstests, vom Code unabhängige Validierungs-Harnesse: Diese Artefakte werden zur eigentlichen Verteidigungslinie, wenn menschliches Lesen wirtschaftlich nicht mehr praktikabel ist. Sie sind die neuen internen Kontrollen Ihres Systems.

3. Schulen Sie Ihre Teams in der Product-Manager-Haltung. Der Beruf des Softwareingenieurs wandelt sich zum Agenten-Piloten. Diese Mutation will geübt sein: Spezifikationen schreiben, Testprotokolle entwerfen, die Kunst des kontextualisierten Prompts.

4. Bauen Sie von Grund auf sichere Umgebungen. Ob Nutzer oder Anbieter von Plattformen: Die Zukunft gehört Umgebungen, in denen die Fehler des Vibe Coders strukturell eingegrenzt sind.

5. Verbieten Sie Vibe Coding heute im tragenden Kern. Die Vorsicht verlangt eine klare Grenze. Die Modelle werden besser, die Grenze wird sich verschieben, aber zu jedem Zeitpunkt müssen Sie wissen, wo sie liegt.

6. Bereiten Sie den Umschwung vor. Wer in zwei Jahren von seinen Teams noch verlangt, jede KI-erzeugte Zeile gegenzulesen, gerät in eine strukturelle Wettbewerbsschwäche. Nicht weil er im Prinzip unrecht hätte, sondern weil seine Organisation zum Engpass ihrer eigenen Produktivität geworden ist.

Outro

Vibe Coding in Produktion ist keine Spinnerei neuerungsfreudiger Geeks. Es ist die pragmatische, noch tastende Antwort auf eine Frage, die sich der gesamten Softwareindustrie in den nächsten achtzehn Monaten stellen wird: Wie nutzt man produktiv Systeme, deren Produktionsgeschwindigkeit unsere menschliche Fähigkeit zur zeilenweisen Prüfung übersteigt?

Die Antwort besteht weder darin, das Werkzeug abzulehnen, noch darin, sich ihm ohne Schutzgeländer auszuliefern. Sie besteht darin, in unserem Beruf Methoden wiederzuentdecken, die die Menschheit seit Jahrhunderten in allen Disziplinen erprobt hat, in denen man Expertisen führen muss, die man selbst nicht beherrscht: rigorose Spezifikation, Prüfung durch Abstraktion, architektonische Eingrenzung, gezielte Stichproben.

Entscheider, die diesen Übergang heute verstehen, die geeigneten Governance-Verfahren einrichten und ihre Teams in der Product-Manager-Haltung für KI schulen, bauen einen dauerhaften Wettbewerbsvorteil auf. Die anderen werden auf die harte Tour lernen, dass sich Rückstand im exponentiellen Regime kaum aufholen lässt.

Vergessen, dass der Code existiert, aber nie, dass das Produkt existiert. Dieser Satz, richtig verstanden, ist der Kompass der nächsten Jahre.