Vibe Coding in Prod ist ein Management-Problem, kein Coding-Problem

Eric Schluntz, Researcher bei Anthropic und Co-Autor von Building Effective Agents zusammen mit Barry Zhang, hat auf einem Event kürzlich einen kurzen Talk mit dem Titel “How to Vibe Code in Prod Responsibly” gehalten. Ich habe ihn zweimal angesehen. Es ist die klarste Aussage, die ich bisher dazu gehört habe, wie sich die nächsten zwei Jahre Software-Engineering tatsächlich anfühlen werden - und das Argument ist nicht das, was die meisten erwarten.

Es geht nicht um Prompt-Qualität, Modellauswahl oder darum, welche IDE gewinnt. Es geht darum, dass Vibe Coding in der Produktion ein Management-Problem ist, und Software Engineers die letzte Funktionsgruppe im Unternehmen sind, die damit konfrontiert wird. Jeder andere Manager der Welt löst dieses Problem bereits. Wir sind einfach spät dran.

Das ist der Artikel, den ich selbst gerne geschrieben hätte. Weil ich es nicht getan habe, hier meine Zusammenfassung: was Schluntz sagte, was ich mitgenommen habe und wie es in den Agentic Stack passt, über den ich in den letzten sechs Monaten geschrieben habe.

Was Vibe Coding tatsächlich bedeutet

Schluntz beginnt mit einer wichtigen definitorischen Präzisierung. Viele Leute, so merkt er an, verwechseln Vibe Coding mit “viel KI einsetzen, um Code zu generieren.” Copilot-Nutzer. Cursor-Nutzer. Engineers, die Claude den Großteil des Diffs schreiben lassen, aber trotzdem jede Zeile reviewen. Das ist kein Vibe Coding.

Der Referenzpunkt ist Andrej Karpathys ursprüngliche Definition: du gibst dich vollständig den Vibes hin, umarmst die Exponentiale und vergisst, dass der Code überhaupt existiert. Der entscheidende Satz ist vergiss, dass der Code überhaupt existiert. Wenn du noch in einer engen Feedback-Schleife mit dem Modell steckst und jedes Stück Code reviewst, betreibst du supervised KI-gestütztes Coding, was gut ist, aber eine andere Sache.

Echtes Vibe Coding ist das, was passiert, wenn die Einheit an KI-Output über das hinauswächst, was du vernünftig reviewen kannst. Und das kommt, ob wir wollen oder nicht.

Das Exponential ist das ganze Argument

Schluntz’ Rahmung des Einsatzes ist die prägnanteste, die ich gesehen habe:

The length of tasks that AI can do is doubling every seven months. Right now we’re at about an hour. You don’t need to vibe code. You can have Cursor work for you, have Claude Code write a feature that would take an hour, and you can review all that code. But what happens next year? The year after? When the AI can generate an entire day’s or week’s worth of work for you at a time, there is no way we’re going to keep up with that if we still need to move in lockstep.

(Sinngemäß: Die Länge an Aufgaben, die KI bewältigen kann, verdoppelt sich alle sieben Monate. Aktuell liegen wir bei etwa einer Stunde. Wenn die KI nächstes Jahr oder übernächstes einen ganzen Tag oder eine Woche an Arbeit am Stück erzeugt, gibt es keinen Weg, im Gleichschritt mitzuhalten.)

Ich habe eine Version dieses Arguments in The Last Bottleneck schon einmal gemacht, aber Schluntz’ Compiler-Analogie ist besser als alles, was mir eingefallen ist. In den frühen Tagen der Compiler haben Entwickler sie benutzt, aber trotzdem den ausgegebenen Assembly-Code gelesen, um den Output zu prüfen. Das skaliert nicht. Irgendwann vertraust du dem Compiler und arbeitest auf der höheren Abstraktionsebene, weil die Alternative ist, für immer auf kleinen Programmen zu bleiben.

Wir stehen beim Code am gleichen Übergang. Die Frage ist nicht, ob wir ihn machen, sondern ob wir ihn verantwortlich machen.

Das alte Management-Problem

Hier ist der Punkt, den ich übersehen habe, bis Schluntz ihn laut ausgesprochen hat: das ist kein neues Problem. Jeder Manager der Welt löst es seit Hunderten von Jahren.

Wie managed ein CTO einen Experten in einer Domäne, in der der CTO selbst kein Experte ist? Wie gibt ein PM ein Feature frei, dessen Implementierung er nicht lesen kann? Wie überprüft ein CEO die Arbeit des Buchhalters, ohne selbst CPA zu sein?

Sie benutzen Abstraktionsschichten, die sie verifizieren können, ohne die Implementierung darunter zu verstehen. Der CTO schreibt Acceptance Tests. Der PM nutzt das Produkt und bestätigt, dass es dem Spec entspricht. Der CEO prüft stichprobenartig Zahlen, die er versteht, in Datenschnitten, klein genug, um sie zu durchdenken, bis das breitere Modell sein Vertrauen verdient hat. Dieses Muster ist so alt wie die Zivilisation, und so handhabt jede große Organisation Arbeit, die keine einzelne Person vollständig inspizieren kann.

Software Engineers sind hier der ungewöhnliche Fall. Bis jetzt ging unser Handwerk davon aus, dass der einzelne Contributor den ganzen Stack herunter gehen und jede Zeile persönlich verstehen konnte. Das war ein Luxus, den die meisten anderen Berufe nie hatten. Das Exponential wird ihn uns wegnehmen, so wie es Assembly-Fluenz vor einer Generation den meisten Entwicklern weggenommen hat.

Die Herausforderung, die Schluntz stellt: “Wie werden wir in Prod vibe coden und es sicher tun? Meine Antwort ist, dass wir vergessen werden, dass der Code existiert, aber nicht, dass das Produkt existiert.” Dieser letzte Satz ist das ganze Spiel. Du musst das Produkt weiterhin kennen, verifizieren und verantworten. Du hörst auf, den Code, der es implementiert, persönlich auditieren zu müssen.

Die Einschränkung: Tech Debt

Schluntz ist ehrlich darüber, wo die Analogie bricht. Die meisten Abstraktionen, die Manager verifizieren, können sie mit externer Evidenz verifizieren. Die Bücher des Buchhalters stimmen. Das Feature des Produkts funktioniert. Der Acceptance Test besteht.

Tech Debt ist die Ausnahme. Im Moment gibt es keinen guten Weg, Tech Debt zu messen oder zu validieren, ohne den Code selbst zu lesen. Du kannst jeden Test bestehen, jedes Feature shippen und trotzdem mit einer Codebasis enden, die unter der Oberfläche still verkalkt, und kein automatisches Signal wird es dir sagen.

Das ist die eine Sache, die vorerst weiterhin Expertenbegutachtung verlangt. Was uns zur nützlichsten umsetzbaren Idee aus dem Talk bringt.

Leaf Nodes und Stämme

Wenn du Tech Debt nicht von außerhalb des Codes verifizieren kannst, musst du klug darin sein, wo du Debt sich anhäufen lässt. Schluntz’ Regel ist einfach:

Leaf Nodes (Blatt-Knoten, also Endpunkte im Abhängigkeitsgraphen) sind die Teile deines Systems, auf die nichts anderes angewiesen ist. End-Features, Polishing, die letzte Meile. Wenn Debt hier landet, ist sie eingegrenzt. Diese sind sicher zum Vibe Coden.
Stämme und Äste sind die Kernarchitektur - Module und Interfaces, auf denen viele andere Dinge aufbauen. Debt häuft sich hier kumulativ an. Die verdienen weiterhin sorgfältiges menschliches Engineering.

Das ist der konkreteste architektonische Rat, den ich aus dem Talk mitgenommen habe. Es ist auch ein nützlicher Weg, eine Codebasis rückblickend zu auditieren: Wenn du den Abhängigkeitsgraphen zeichnest und die Blätter schattierst, hast du gerade gemappt, wo Agenten am schnellsten mit dem geringsten Risiko vorankommen können. Alles stromaufwärts eines viel genutzten Moduls ist ein Ort, an dem du langsamer wirst, sorgfältig reviewst und in Erweiterbarkeit investierst.

Für alle, die ein teamweites Policy zu “wo können wir uns voll auf Claude stützen” setzen wollen, ist das die richtige Form der Antwort. Nicht “Tests oder keine Tests.” Nicht “kritisch oder unkritisch.” Die Frage ist wo im Abhängigkeitsgraphen der Code sitzt.

Der 22.000-Zeilen-PR

Das auffälligste konkrete Beispiel im Talk war, als Schluntz einen Screenshot eines echten GitHub-PRs zeigte: eine 22.000-Zeilen-Änderung an Anthropics produktiver Reinforcement-Learning-Codebasis, großteils von Claude geschrieben. Sie haben ihn gemerged.

Wie passiert das verantwortlich? Vier Zutaten, jede eine direkte Anwendung der obigen Prinzipien:

Tage an menschlicher Anforderungs- und Guidance-Arbeit bevor eine Zeile geschrieben wurde. Schluntz und sein Team agierten als Claudes Product Manager, nicht als sein Tipper.
Konzentration auf Leaf Nodes. Die Änderung lebte in Teilen des Systems, wo zukünftige Tech Debt akzeptabel war, weil nichts darauf aufgebaut werden sollte.
Heftiges menschliches Review auf den erweiterbaren Teilen. Der kleine Anteil, der strukturell war, bekam die Prüfung eines normalen Engineering Reviews.
Stress Tests und designte Verifizierbarkeit. Sie haben das System so gebaut, dass es menschlich verifizierbare Inputs und Outputs hat. Stabilität, ihre größte Sorge, wurde durch Stresstests über lange Laufzeiten gemessen, was null Code-Lesen zur Interpretation erforderte.

Schluntz’ Zusammenfassung des Ergebnisses ist der zitierwürdige Teil:

Ultimately by combining those things we were able to become just as confident in this change as any other change that we made to our codebase but deliver it in a tiny fraction of the time and effort.

(Sinngemäß: Durch die Kombination dieser Dinge konnten wir in diese Änderung genauso viel Vertrauen haben wie in jede andere Änderung an unserer Codebasis, sie aber in einem Bruchteil der Zeit und des Aufwands liefern.)

Lies diesen Satz nochmal. Der Maßstab, den sie an sich selbst gelegt haben, war gleiches Vertrauen wie bei einer von Menschen geschriebenen Änderung. Nicht niedriger, nicht “gut genug für einen KI-geschriebenen PR.” Das gleiche Vertrauen, über andere Verifizierungsmechanismen. Das ist es, wie verantwortliches Vibe Coding in Prod aussieht, und das ist es, wonach ich jedes Team, mit dem ich arbeite, streben sehen will.

Der Effekt zweiter Ordnung

Der Effekt, den Schluntz fast nur beiläufig erwähnt, ist der, der umformen wird, wie Teams Arbeit planen:

Now suddenly when something costs one day of time instead of two weeks, you realize that you can go and make much bigger features and much bigger changes. The marginal cost of software is lower and it lets you consume and build more software.

(Sinngemäß: Plötzlich kostet etwas einen Tag statt zwei Wochen, und du merkst, dass du viel größere Features und Änderungen bauen kannst. Die Grenzkosten von Software sind niedriger, und das lässt dich mehr Software konsumieren und bauen.)

Das ist genau die Dynamik, die ich immer wieder in meiner eigenen Arbeit und bei den Firmen, die ich berate, sehe. Sobald ein Team verinnerlicht, dass eine Änderung, die vorher ein Zwei-Wochen-Projekt gewesen wäre, jetzt ein Ein-Tages-Projekt ist, hören sie auf, ihre Roadmap durch das alte Kostenmodell zu filtern. Dinge, die nie auf der Liste standen, weil sie sich nicht gelohnt haben, sind plötzlich auf der Liste.

Das ist auch der Grund, warum Firmen, die lernen, in Prod verantwortlich zu vibe coden, nicht nur schneller shippen werden als die, die es nicht tun. Sie werden andere Dinge shippen. Größere Refactors. Interne Tools, die niemand gebaut hätte. Experimente, die früher durch Engineering-Kosten blockiert waren.

Das Londoner Startup, bei dem ich bald anfange, war viel in meinem Kopf, während ich das geschrieben habe. Der Unterschied zwischen einem Team mit diesem Muskel und einem ohne wird sich in der Produktoberfläche innerhalb eines Jahres zeigen.

Sei Claudes PM

Der praktische Ratschlag des Talks für einzelne Engineers ist in einem Satz zusammengefasst, den ich noch lange zitieren werde:

Ask not what Claude can do for you, but what you can do for Claude.

(Sinngemäß: Frage nicht, was Claude für dich tun kann, sondern was du für Claude tun kannst.)

Der Mindset-Wechsel geht vom Prompter zum Product Manager. Du bist Claudes PM. Welche Guidance, Anforderungen, Kontext und Constraints bräuchte ein fähiger neuer Engineer in deinem Team, um am ersten Tag bei dieser Aufgabe erfolgreich zu sein? Sammle das, übergib es und lass Claude kochen.

Schluntz’ eigenes Arbeitsmuster ist konkret und nachahmenswert:

15 bis 20 Minuten Kontext-Sammeln, bevor der Agent ausführt. Oft ist das selbst ein Gespräch mit Claude - die Codebasis erkunden, Dateien finden, gemeinsam einen Plan bauen, das Ergebnis als ein einzelnes Artefakt festhalten.
Das Artefakt an Claude in einem neuen Kontext oder als expliziten “Führe diesen Plan aus”-Prompt übergeben.
Den Kontext an natürlichen Haltepunkten kompaktieren, an denselben Momenten, an denen ein Mensch Mittagspause machen würde.

Ich erkenne das wieder, weil es im Wesentlichen der Workflow ist, den ich in Agentic Development Patterns und The Perfect CLAUDE.md beschrieben habe: behandle den Agenten als Kollegen, der eingearbeitet werden muss, nicht als Suchmaschine. Was Schluntz hinzufügt, ist die Rahmung - du bist der Product Manager, nicht der Coder - und das Vokabular der Verifizierbarkeit, das damit einhergeht.

Wo das in meinen Stack passt

Wenn du die Agentic-Development-Artikel auf dieser Seite verfolgt hast, siehst du, wie Schluntz’ Rahmung als die fehlende Meta-Ebene dazupasst:

Ebene	Was sie regelt	Artikel
Warum wir das überhaupt tun	Das Management-Problem, Leaf Nodes, Verifizierbarkeit	Dieser Artikel
Die architektonische Form	Wann deterministischer Code vs. ML vs. LLM-Agenten	Three-Tier AI Architecture
Die Disziplin-Schicht	Skills, Progressive Disclosure, Anti-Rationalisierung	The Skills Framework
Der tägliche Workflow	Kontext-Sammeln, Plan-Artefakte, Worktrees	Agentic Development Patterns
Der Kompounding-Mechanismus	Nächtliche Läufe, parallele Agenten, Review Gates	The Overnight Agent Factory

Schluntz’ Talk ist die Executive Summary des gesamten Stacks. Es ist der, den ich einem CTO oder Head of Engineering in die Hand drücken würde, der diesen Bereich nicht eng verfolgt hat und mich fragt, warum irgendetwas davon für sein Team wichtig ist.

Was ich mitnehme

Drei Dinge, die ich sofort operationalisieren werde:

Leaf-Node-Audits. In jeder Codebasis, die ich anfasse, will ich einen groben Abhängigkeitsgraphen mit schattierten Blättern. Diese Karte wird zum Policy-Dokument dafür, wo meine Agenten maximale Freiheit bekommen und wo sie einen Aufpasser brauchen.
Verifizierbarkeit-zuerst-Design. Wenn ich ein neues Feature scope, frage ich jetzt explizit “wie werden wir diese Änderung verifizieren, ohne den Code zu lesen?” als Design-Constraint, nicht als Nachgedanke. Stresstests, saubere Interfaces, Invarianten und typisierte Contracts werden alle zu tragenden Elementen.
Claudes PM ist mein Job-Titel. Nicht metaphorisch. Die 15 bis 20 Minuten Kontext-Arbeit am Anfang jeder Agent-Session sind die Aktivität mit dem höchsten Hebel in meinem Tag. Es ist auch der Teil, bei dem ich am wahrscheinlichsten abkürze, wenn ich in Eile bin. Damit höre ich jetzt auf.

Das Fazit

Die Branche hat die ersten achtzehn Monate der Agent-Ära damit verbracht, zu streiten, ob Vibe Coding echtes Engineering sei. Es war die falsche Debatte. Karpathys ursprüngliche Rahmung ist eine Arbeitsweise mit echten Grenzen. Schluntz’ Erweiterung - vergiss den Code, nicht das Produkt - ist die Brücke zu produktionsreifer Arbeit.

Der schwere Teil ist nicht, Kontrolle über die Implementierung abzugeben. Der schwere Teil ist, die Abstraktionen und Verifizierungsschichten zu bauen, die dir erlauben, Kontrolle verantwortlich abzugeben. Das ist Engineering-Management angewandt auf das eigene Handwerk. Jeder CTO, PM und CEO der Welt macht das seit Ewigkeiten. Jetzt sind wir dran.

Wenn die Länge an Aufgaben, die KI bewältigen kann, sich tatsächlich alle sieben Monate verdoppelt, werden die Engineers, die weiterhin darauf bestehen, jede Zeile zu lesen, zum Bottleneck in ihren eigenen Teams. Diejenigen, die lernen, ohne Lesen zu verifizieren, die die Blätter vibe coden und die Stämme bewachen, die als Claudes PM agieren statt als sein Tipper, werden Dinge bauen, die sich die erste Gruppe nicht vorstellen kann. Das ist das Exponential in Karpathys “umarme die Exponentiale” - und es ist das eigentliche Thema von Schluntz’ Talk.

Schau ihn dir an, falls du es nicht getan hast. Sechzehn Minuten, die die nächsten zwei Jahre neu rahmen.

Referenzen

Vibe Coding - Eric Schluntz, Anthropic Team - Der Original-Talk
Building Effective Agents - Schluntz’ und Zhangs frühere Einführung in die Agent-Muster, die all dem zugrunde liegen
Andrej Karpathy on vibe coding - Die ursprüngliche Rahmung
The Last Bottleneck - Mein früherer Artikel zum Exponential und zum menschlichen Bottleneck
Three-Tier AI Architecture - Wann deterministischer Code, ML oder LLM-Agenten
The Skills Framework - Progressive Disclosure und Anti-Rationalisierung als Disziplinschicht
Agentic Development Patterns - Der tägliche Workflow
The Perfect CLAUDE.md - Claude einarbeiten wie einen neuen Teamkollegen
The Overnight Agent Factory - Der Kompounding-Mechanismus obendrauf