Vibe Coding gegen Agentic Engineering: Was Googles neues SDLC-Paper behauptet.

Von einem Slogan zu einem Whitepaper

Früh im Jahr 2025 skizzierte Andrej Karpathy einen Programmierstil, bei dem man sich vollständig den Impulsen hingibt, der exponentiellen Entwicklung folgt und aufhört, sich darum zu kümmern, dass Code überhaupt existiert. Der Kreislauf bestand aus der Eingabe eines Befehls, der Akzeptanz desselben, der Ausführung sowie der Rückgabe der Fehlermeldung bei Misserfolg. Der Begriff verbreitete sich sofort, obwohl die Menschen bereits auf diese Weise arbeiteten – es fehlte nur ein Name.

Ungefähr sechzehn Monate später veröffentlichte Google ein 50-seitiges Whitepaper mit dem Titel „The New SDLC With Vibe Coding“, verfasst von Addy Osmani, Shubham Saboo und Sokratis Kartakis. Es ist dicht und gut strukturiert, und seine Botschaft ist schmerzhaft: Vibe Coding eignete sich zwar für Prototypen, doch es belastet allmählich die Produktionsysteme, und viele Teams erkennen dies nicht, weil der Schaden sich schrittweise ansammelt. Die folgenden Abschnitte behandeln die Argumente des Papers, seine klare Trennlinie sowie die Auswirkungen für diejenigen, die 2026 mit KI-Agenten arbeiten.

Warum Vibe Coding funktionierte – und wo es endet

Vibe Coding wurde beliebt, weil es die Hürden senkte. Prototypen konnten in Minuten erstellt werden, Nicht-Ingenieure konnten funktionierende Tools zusammenstellen, und die Zeit zwischen einer Idee und dem lauffähigen Code verringerte sich von Tagen auf Stunden. Das ist wertvoll, und dies abzulehnen ist ingenieurtechnischer Snobismus. Die Hürden selbst waren jedoch nie das Problem – das Problem sind die Grenzen.

Sobald die Entwickler besser wurden, begannen die Teams, diese lockere Gewohnheit des Prompt-Gebens und Akzeptierens auch auf Produktivsysteme anzuwenden – einschließlich Zahlungs-APIs, Authentifizierungslogik, Datenpipelines und Gesundheitswerkzeuge. Das Ergebnis sieht ordentlich aus und besteht in der Regel die grundlegenden Tests, weshalb es in Produktion geht. Einige Wochen oder Monate später versagt etwas auf eine Weise, die teuer und schwer nachvollziehbar ist.

Die Ursache ist strukturell. Vibe Coding wurde entwickelt, um etwas schnell zum Laufen zu bringen, nicht um die Anforderungen an Produktivqualität zu erfüllen – es handelt sich dabei um unterschiedliche Ziele. Die Verwechslung dieser Ziele ist die Ursache für die heutigen Probleme. Das Whitepaper versucht, den Teams das passende Vokabular und Framework zur Vermeidung dieser Verwechslung zur Verfügung zu stellen.

Ein Spektrum mit einem Trennfaktor

Das Paper zeigt ein Spektrum auf, bei dem die Stimmungskodierung an einem Ende und die agentbasierte Ingenieurwissenschaft am anderen Ende stehen. Die meisten Praktiker befinden sich irgendwo dazwischen und können nicht genau angeben, wo genau, was an sich bereits zu einem Teil des Problems ist.

Dieses Spektrum erstreckt sich über drei Dimensionen: wie die Absicht festgelegt wird, wie gründlich die Überprüfung erfolgt und das Risikoprofil. Ein Faktor trennt die beiden Enden voneinander – und es liegt weder daran, welches Modell verwendet wird, wie klug die Anfragen formuliert sind oder welches Tool gewählt wird. Es geht vielmehr darum, wie die Ergebnisse überprüft werden.

Zwei Arten der Überprüfung sind notwendig. Deterministische Tests prüfen, ob eine Funktion für eine gegebene Eingabe das richtige Ergebnis zurückgibt. Trajektoriebewertungen prüfen, ob der Agent die richtige Abfolge von Schlussfolgerungs Schritten zur Erreichung dieses Ergebnisses befolgt hat. Ohne beides handelt es sich um „Vibe Coding“, egal wie ausgefeilt die Konfiguration auch erscheinen mag. Ein poliertes, flüssiges Ergebnis, bei dem die Überprüfung ausgelassen wurde, ist kein Erfolg – es handelt sich dabei um einen gefährlicheren Fehler als einen, der einen Fehler anzeigt, da dieser erst in der Produktion sichtbar wird. Das ist die klare Grenze, und es erklärt, warum viele Teams mit ausgefeilten agilen Arbeitsabläufen immer noch technisch gesehen „Vibe Coding“ betreiben.

Das Modell ist nicht die Hauptvariable

Das ist vermutlich die wichtigste technische Neubewertung in dem Paper, und viele Entwickler verstehen sie falsch. Wenn ein Agent sich falsch verhält, ist die übliche Reaktion, das Modell dafür verantwortlich zu machen – weil es zu schwach, zu langsam oder zu anfällig für Halluzinationen ist – und anzunehmen, dass ein besseres Modell die Lösung ist. Diese Argumentation ist fast immer falsch.

Das Modell ist nur ein Teil. Der Rest, nämlich Anfragen, Tools, Kontextrichtlinien, Ausführungssandboxen, Unteragenten und Überwachungsfunktionen, bildet die Infrastruktur, und das Verhalten eines Agents hängt viel stärker von dieser Infrastruktur als vom Modell ab. Zwei Datenpunkte im Paper belegen das. Bei Terminal Bench 2.0 schaffte ein Team es, einen Programmieragenten allein durch Anpassungen der Infrastruktur von außerhalb der Top 30 in die Top 5 zu bringen. In einer separaten LangChain-Studie führten Änderungen am Systemprompt, an Tools sowie am Middleware um ein unverändertes Modell zu einer Steigerung der Benchmark-Ergebnisse des Programmieragenten um 13,7 Punkte.

Regeldateien, Tools, Sandboxes, Orchestrierungslogik, Schutzmechanismen sowie Überwachungsfunktionen gehören alle zum Harness, und sein Aufbau liegt vollständig in den Händen des Teams. Der Anbieter liefert den Motor, während das Team darum herum die Produktionsumgebung aufbaut. Ehrlich gesagt sind die meisten Agent-Fehler Konfigurationsprobleme: ein fehlendes Tool, eine unklare Regel, ein fehlender Schutzmechanismus oder ein mit Unrat überflutetes Kontextfenster. Die Schuld fällt auf das Modell, da es die sichtbare Schicht darstellt, obwohl das eigentliche Defekt im Harness liegt. Das Streben nach Modell-Updates und die Vernachlässigung des Harness gleicht dem Einbau eines schnelleren Motors in ein Auto ohne Bremsen.

Kontextengineering ersetzt Prompt Engineering

Die Prompt-Engineering-Disziplin selbst ist größtenteils in Vergessenheit geraten, und an ihre Stelle ist das Context-Engineering getreten. Das bedeutet, Agenten mit umfangreichen, strukturierten Informationen über die Codebasis, Architektur, Konventionen sowie die Absichten, mit denen sie arbeiten, zu versorgen. Der Artikel nennt sechs Context-Typen, die jeder Agent benötigt: Anweisungen, Wissen, Speicher, Beispiele, Tools und Schutzmechanismen. Jeder dieser Typen kann statisch sein und bei jeder Interaktion vorhanden sein, oder dynamisch, also auf Anfrage bereitgestellt werden.

Der statische Kontext ist sehr aufwendig, da jeder Token bei jedem Modellaufruf mitgeschickt wird – unabhängig davon, ob er relevant ist oder nicht. Überschüssige Token verschwenden Ressourcen, schwächen das Signal und können die Leistung beeinträchtigen, indem sie wichtige Regeln im „Rauschen“ verbergen. Der dynamische Kontext hingegen ist günstiger, da er aus RAG-Pipelines, task-spezifischen Auslösern oder Tool-Ergebnissen zum Zeitpunkt des Bedarfs stammt. Die Entscheidung, was wohin gelangt, ist ein zentraler ingenieurtechnischer Kompromiss und keine bloße Konfigurationsanmerkung – daher verdient sie Versionierung, Überprüfung sowie die gleiche Sorgfalt wie andere Designentscheidungen.

Das beste Muster hier sind Agent Skills: strukturierte, portable Pakete mit prozeduralem Wissen, die nur dann geladen werden, wenn eine Aufgabe sie benötigt. Anstatt spezialisiertes Wissen in den Systemprompt zu packen, ermöglichen Skills es dem Agenten, weiterhin ein leichter Generalist zu bleiben und erst bei Bedarf zum Spezialisten zu werden. Ein AGENTS.md, das diese Abgrenzung gut handhabt, könnte wie folgt aussehen:

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

Die genaue Syntax spielt eine geringere Rolle als die als Einschränkung kodierte Absicht. Der Agent lernt, was er ist, was er berühren darf, was spezialisiertes Verhalten auslöst und was ohne Genehmigung verboten ist – und all das muss nicht in jedem Kontextfenster enthalten sein. Das ist der Unterschied zwischen einem Agenten, der bei Hunderten von Aufgaben zuverlässig bleibt, und einem, der bereits nach den ersten Dutzend Aufgaben versagt.

Die 80%-Falle

Agenten können etwa 80 Prozent des Codes einer Funktion schnell schreiben. Dieser Anteil wirkt in der Regel ordentlich, übersteht eine oberflächliche Überprüfung und wird ohne Probleme veröffentlicht – so schließt sich die Falle. Die letzten 20 Prozent sind es, bei denen Systeme versagen: Randfälle, Geschäftsregeln, die nur im Kopf der Mitarbeiter vorhanden sind und nicht in Dokumenten festgehalten werden, Integrationspunkte zwischen Services, die von verschiedenen Teams über Jahre hinweg entwickelt wurden, sowie feine Korrektheitsanforderungen, die erst unter echter Last oder echtem Benutzerverhalten zum Vorschein kommen.

Auch die Art der Fehler bei KI hat sich geändert. Frühe Programmierwerkzeuge zeigten offensichtliche Syntaxfehler, die leicht bei der Überprüfung entdeckt werden konnten. Heutige KI-Systeme verursachen hingegen konzeptionelle Fehler: falsche Annahmen bezüglich Geschäftsregeln, plausibel erscheinende, aber unberücksichtigte Randfälle sowie architektonische Entscheidungen, die verborgene langfristige Wartungskosten mit sich bringen. Der Code erscheint korrekt und kann möglicherweise die Testsuite bestehen, doch das Versagen ist strukturell bedingt, tritt verzögert auf und ist in der Regel weitaus teurer zu beheben als zu verhindern.

Deshalb kann die Bewertung der Handlungsabläufe – also die Überprüfung des Schlussfolgerungswegs des Agenten zusammen mit seinem Ausgabeergebnis – in produktiven Agentensystemen nicht weggelassen werden. Bei der Bewertung der Ausgabe wird geprüft, ob die Funktion das richtige Ergebnis zurückgegeben hat. Bei der Bewertung der Handlungsabläufe wird geprüft, ob der Agent das Problem bereits verstanden hat, bevor er etwas ausgibt. Jede dieser Überprüfungen ist wichtig; wenn man sich nur auf die Ausgabe konzentriert, gelangen 20 Prozent der Fälle unkontrolliert weiter. Die Entwickler, die am besten zurechtkommen, beschleunigen ihre Arbeit nicht dadurch, dass sie alles akzeptieren. Sie erreichen Geschwindigkeit, indem sie ihr eigenes Urteilsvermögen dort einsetzen, wo das Urteilsvermögen der KI strukturell am schwächsten ist: bei unklaren Anforderungen, architektonischen Kompromissen und der Richtigkeit an den Systemgrenzen.

Leitungs- und Orchestrierungsmodi

Das Paper beschreibt zwei Betriebsmodi, und der Wechsel zwischen ihnen könnte der praktisch bedeutendste Karriereschritt in der Softwareentwicklung heute sein. Im Leitungsmodus arbeitet der Entwickler direkt in der IDE, beobachtet, wie der Code entsteht, korrigiert ihn und behält eine feine Kontrolle über jede Änderung. Dadurch bleibt die Intuition sowie das Verständnis erhalten, für die Ingenieure ausgebildet werden. Der Nachteil ist die Geschwindigkeit, denn die persönliche Steuerung jeder Interaktion begrenzt die Vorteile der KI.

Der Orchesterierungsmodus befindet sich auf einer höheren Ebene. Entwickler setzen Ziele, übergeben sie an Agenten und prüfen das Ergebnis, ohne den Code Zeile für Zeile verfolgen zu müssen. Die Agenten arbeiten parallel in Hintergrund-Sandbox-Umgebungen, manchmal stundenlang, und liefern Pull-Requests zurück. Der Entwickler schaut regelmäßig nach, bewertet die Ergebnisse und leitet gegebenenfalls um.

Der Leitmodus ist in Echtzeit, interaktiv und basiert auf einem einzelnen Agenten. Der Orchestrierungsmodus ist asynchron, verwendet parallele Agenten und liefert einen Pull Request als Ergebnis. Die meisten Entwickler sind als Leiter ausgebildet, wodurch der Wechsel zum Orchestrierungsmodus eine große Rolleänderung darstellt.

Die erforderlichen Fähigkeiten unterscheiden sich ebenfalls. Leiter verlassen sich auf umfassendes Wissen über Sprache und Syntax, schnelles Debuggen, ein Gespür für die Codebasis sowie die Interpretation von Fehlern in Echtzeit. Orchestratoren benötigen präzise Spezifikationen, die Aufteilung von Aufgaben, eine schnelle Bewertung der Ergebnisse sowie ein Systemdesign – das bedeutet, die Einschränkungen, Tests und Feedbackschleifen so zu gestalten, dass die Agenten auch ohne engmaschige Überwachung zuverlässig funktionieren. Viele erfahrene Entwickler sind geübte Leiter, und das Orchestrieren fühlt sich unangenehm an, weil es wie ein Verzicht auf Kontrolle erscheint. Manchmal ist das tatsächlich der Fall, weshalb Infrastruktur genutzt und eine Bewertung der Abdeckung sowie ein Kontextengineering vor einer Ausweitung des Orchestrierens vorhanden sein sollten. Delegieren ohne Überprüfungsmechanismen ist keine Ingenieurarbeit – es handelt sich dabei um „Vibe Coding“ in großem Maßstab.

Eine Wirtschaftsfrage

Das Paper betrachtet die Debatte um Vibe-Coding gegenüber agiler Ingenieurkunst als eine Frage der Kosten und nicht der Methodik. Vibe-Coding kostet anfangs fast nichts: keine Spezifikationsdisziplin, keine Evaluierungsinfrastruktur, kein Harness-Design und keine Wartung von AGENTS.md. Dennoch entstehen schnell versteckte Betriebskosten durch den Verschwendung von Tokens aufgrund unstrukturierter Kontexte, eine zunehmende Anzahl an Fehlern durch unüberprüfte Ausgaben sowie Entwicklertempo, das durch Fehler verloren geht, die automatisierte Evaluierungen eigentlich erkennen sollten.

Agile Ingenieurkunst erfordert eine echte, frühzeitige Investition in strenge Spezifikationen, Evaluierungsinfrastruktur, Harness-Design sowie Kontextarchitektur. Danach sinken die Grenzkosten pro Funktion stark, da jede neue Fähigkeit des Agenten denselben Harness, das gleiche Evaluierungssystem und dieselbe Kontextarchitektur wiederverwendet.

Für einen Entwickler, der an einem Prototyp oder einem Nebenprojekt arbeitet, ist Vibe Coding eindeutig kostengünstiger. Es muss kein Produktionsystem geschützt werden, und die anfallenden Verpflichtungen erreichen niemals gefährliche Ausmaße. Teams erreichen den Wendepunkt früher als erwartet. Fünf Ingenieure, die drei Monate lang mit Vibe Coding arbeiten, können leicht dazu kommen, dass ein Drittel ihrer Kapazität durch Debugging und Nacharbeiten aufgebraucht wird – etwas, was eine systematische Überprüfung verhindert hätte. Aggressive Infrastruktur lohnt sich, sofern sie bereits vor Erreichen des kritischen Punkts eingeführt wird.

Was die Studie klärt und was nicht

Dieser Artikel ist keine Verkaufspräsentation. Es handelt sich um ein Rahmenwerk-Dokument – und eines, das praktischer ist als die meisten, da seine Hauptbehauptungen überprüft werden können. Der Harness-Effekt ist real und messbar, wie die zitierten Benchmarks zeigen. Das 80%-Problem existiert tatsächlich und wird immer deutlicher, je schwierigere Aufgaben die Agenten übernehmen müssen. Zudem findet bereits in jeder ernsthaften, großangelegten Ingenieurdienstleistungsorganisation der Wandel vom Leiter zum Orchestrator statt.

Beabsichtigt offen gelassen wird offenbar, wo sich ein bestimmtes Team auf diesem Spektrum befinden sollte. Dies hängt von Faktoren wie den Risiken, der Teamgröße, dem Zeitdruck und der technischen Reife ab – Faktoren, die kein Rahmenwerk vorschreiben kann. Der Artikel liefert Vokabular und ein mentales Modell, doch die Entscheidung bleibt bei den Menschen, was vermutlich die ehrlichste Haltung ist, die möglich ist.

Die Struktur skaliert, die Eigenschaften jedoch nicht. Entwickler, die das jetzt begreifen, bauen auf völlig anderen Grundlagen als diejenigen, die es auf teure Weise im Produktivbetrieb lernen müssen.