Vibe Coding oder Agentic Engineering? Googles Whitepaper zum neuen Software-Lebenszyklus

Im Mai 2026 hat Google ein Whitepaper mit dem Titel „The New SDLC With Vibe Coding" veröffentlicht — geschrieben von Addy Osmani (Chrome-Team, Autor von „Beyond Vibe Coding"), Shubham Saboo und Sokratis Kartakis, erschienen als Teil der Agents-Whitepaper-Serie auf Kaggle. Auf 51 Seiten vermisst es, wie KI-Agenten den Software-Lebenszyklus (SDLC, Software Development Life Cycle) umbauen — von der Anforderungsanalyse bis zur Wartung. Diese Seite fasst die Kernideen zusammen und ordnet ein, was das Paper leistet und wo man es mit Vorsicht lesen sollte.

Das Spektrum: von Vibes zu Disziplin

Als Andrej Karpathy im Februar 2025 das Vibe Coding beschrieb — sich „ganz den Vibes hingeben" und vergessen, dass der Code überhaupt existiert —, traf er einen Nerv: Viele arbeiteten längst so, es fehlte nur das Wort. Binnen Monaten wurde der Begriff allerdings auf jede Form KI-gestützter Entwicklung ausgedehnt und verlor an Trennschärfe. Anfang 2026 schob Karpathy selbst den Gegenbegriff nach: Agentic Engineering für das disziplinierte Ende des Spektrums.

Das Paper behandelt beide als Endpunkte einer Skala, nicht als Entweder-oder. Der entscheidende Unterschied ist nicht, ob man KI einsetzt, sondern wie viel Struktur um ihren Output herum steht. Beim Vibe Coding ist Verifikation optional („scheint zu laufen"); beim Agentic Engineering greifen zwei Mechanismen ineinander: Tests prüfen die deterministischen Teile des Systems, Evals die nicht-deterministischen — hat der Agent die richtigen Schritte gewählt, die richtigen Werkzeuge benutzt, ein Ergebnis in der geforderten Qualität geliefert? Das Paper ist hier kategorisch: Ohne beides bleibt es Vibe Coding, egal wie ausgefeilt die Prompts sind.

Wichtig ist die Entwarnung gleich dazu: Vibe Coding ist kein Schimpfwort. Für Prototypen, Wegwerf-Skripte und Wochenendprojekte ist es die angemessene Arbeitsweise. Die eigentliche Kompetenz besteht darin, für jede Aufgabe zu wissen, wo auf dem Spektrum sie hingehört.

Context Engineering: die eigentliche Fähigkeit

Die Qualität KI-generierten Codes hängt nach Darstellung des Papers weniger von cleveren Prompts ab als von der Qualität des bereitgestellten Kontexts. Context Engineering heißt diese Praxis, und sie umfasst sechs Kontext-Typen: Instruktionen, Wissen, Gedächtnis, Beispiele, Werkzeuge und Guardrails.

Die zentrale Design-Entscheidung dabei: Was gehört in den statischen Kontext (immer geladen — Regel-Dateien wie AGENTS.md oder CLAUDE.md, System-Prompt, Persona), und was wird dynamisch erst bei Bedarf nachgeladen (Skills, Dokumente, Tool-Ergebnisse)? Statischer Kontext kostet in jeder einzelnen Interaktion Tokens; zu viel davon verwässert das Signal, zu wenig lässt den Agenten wichtige Regeln vergessen. Das Paper behandelt diese Grenze als Architektur-Entscheidung erster Klasse, die versioniert und im Review geprüft gehört.

Die schönste Umformulierung des Themas liefert das Paper gleich mit: Die Frage ist nicht „Wie überliste ich die KI, guten Code zu schreiben?", sondern „Was müsste ein neues Teammitglied wissen, um produktiv beizutragen — und wie kodiere ich dieses Wissen in einer Form, die die KI nutzen kann?"

Der Harness: was das Modell umgibt

Der stärkste Abschnitt des Papers räumt mit einer verbreiteten Intuition auf: dass das Modell das System sei. Neues Modell, besserer Agent; altes Modell, schlechterer Agent. Diese Zuschreibung führe zu falschen Investitionen. Ein Agent besteht aus dem Modell und dem Harness — der umgebenden Software aus Regel-Dateien, Werkzeugen, Sandboxes, Orchestrierung, Hooks und Observability. Und dieses Verhalten werde vom Harness dominiert, nicht nur vom Modell darunter.

Das Paper belegt das mit Benchmark-Zahlen: Ein Team verbesserte einen Coding-Agenten auf Terminal Bench 2.0 von außerhalb der Top 30 in die Top 5 — ohne Modellwechsel, nur durch Änderungen am Harness. Eine LangChain-Studie hob den Score eines Agenten um 13,7 Punkte allein durch Anpassungen an System-Prompt, Werkzeugen und Middleware. Die Alltagsversion dieser Beobachtung formuliert das Paper so: Wenn ein Agent etwas Falsches tut, ist der erste Reflex, das Modell zu beschuldigen — häufiger liegt die Ursache aber in einem fehlenden Werkzeug, einer vagen Regel, einem fehlenden Guardrail oder einem mit Rauschen gefüllten Kontextfenster. Die meisten Agenten-Fehler sind, ehrlich betrachtet, Konfigurationsfehler.

Der neue Lebenszyklus und das Fabrik-Modell

Die KI-Beschleunigung wirkt ungleichmäßig auf die SDLC-Phasen: Implementierung, die Wochen dauerte, schrumpft auf Stunden — Anforderungen, Architektur und Verifikation bleiben hartnäckig menschen-getaktet. Architektur nennt das Paper die am stärksten menschlich bleibende Phase, weil es dort um Abwägungen geht (Konsistenz gegen Verfügbarkeit, Bauen gegen Kaufen), die Geschäftskontext verlangen. Am meisten unterschätzt sei dagegen die Wartung: Legacy-Code, den nur seine ursprünglichen Autoren verstanden, lässt sich mit Agenten-Hilfe wieder gefahrlos anfassen, migrieren und modernisieren.

Als verbindendes Denkmodell dient die Fabrik: Der primäre Output des Entwicklers ist nicht mehr der Code, sondern das System, das Code produziert — Spezifikationen, Agenten, Quality Gates, Feedback-Schleifen. Ein Fabrikleiter montiert nicht jedes Werkstück selbst; er entwirft die Fertigungsstraße und sichert die Qualität. Dazu passen die zwei Arbeitsmodi, zwischen denen Entwickler wechseln: der Conductor (Dirigent), der im Editor in Echtzeit mitliest und lenkt, und der Orchestrator, der Ziele definiert, an Agenten delegiert und asynchron Ergebnisse prüft — was andere Fähigkeiten verlangt: Spezifikation, Zerlegung, Bewertung, Systemdesign.

Erfreulich ehrlich ist das Paper bei den Produktivitätszahlen. Es zitiert Branchenumfragen mit 25 bis 39 Prozent Produktivitätsgewinn — und direkt daneben die METR-Studie, nach der erfahrene Entwickler mit KI-Assistenz auf bestimmten Aufgaben 19 Prozent länger brauchten, weil Verifizieren und Korrigieren Zeit kostet. Dazu passt das „80-Prozent-Problem": Agenten erzeugen schnell rund 80 Prozent eines Features; die restlichen 20 — Randfälle, Fehlerbehandlung, Integrationspunkte — verlangen Kontextwissen, das den Modellen fehlt. Die Fehler von heute sind dabei selten Syntaxfehler, sondern konzeptuelle: falsche Annahmen über Geschäftslogik, die „richtig aussehen" und einfache Tests bestehen.

Die Ökonomie: verdeckte Schulden

Für Engineering-Leads dürfte das Kapitel zur Kostenrechnung das interessanteste sein. Vibe Coding wirkt billig — ein Abo, ein paar Prompts —, versteckt aber laufende Kosten: Token-Verbrauch durch Fix-mich-nochmal-Schleifen, Wartungssteuer auf strukturlos generierten Code, Sicherheitslücken, die erst in Produktion auffallen. Agentic Engineering dreht das Verhältnis um: hohe Anfangsinvestition (Testsuiten, Kontextstruktur, Evals), dafür drastisch niedrigere Kosten pro Feature danach. Context Engineering wird so zum finanziellen Hebel, und intelligentes Modell-Routing — teure Frontier-Modelle für Architektur, günstige kleine Modelle für Testgenerierung und Review — senkt die Betriebskosten weiter.

Einordnung

Was das Paper gut macht: Es liefert Vokabular und mentale Modelle statt einer Tool-Liste, die in sechs Monaten veraltet wäre. Die Unterscheidung Vibe Coding / Agentic Engineering, das Fabrik-Modell und vor allem die Harness-These sind brauchbare Denkwerkzeuge — auch für Gespräche mit Entscheidern, wie das Paper selbst anmerkt: Wer dem CTO erzählt, das Team „vibe-code" das Zahlungssystem, löst zu Recht Alarm aus; dasselbe Team mit dokumentiertem Harness, Testabdeckung und Evals führt ein anderes Gespräch. Positiv fällt auch die Bereitschaft auf, unbequeme Evidenz zu zitieren (METR) statt nur Erfolgsmeldungen.

Wo man mit Vorsicht lesen sollte: Es ist ein Google-Paper, und das merkt man. Die hauseigenen Produkte — Agent Development Kit, Agents CLI, Jules, das A2A-Protokoll — bekommen prominente Auftritte, die im Kern Produktplatzierung sind. Die eingängigen Statistiken („85 % nutzen regelmäßig KI-Agenten, 41 % des neuen Codes ist KI-generiert") stammen aus Vendor-Blogs, nicht aus begutachteten Studien — als Größenordnung plausibel, als Zahl nicht belastbar. Und die Begriffsgeschichte wird stark auf Karpathy zugeschnitten: Peter Steinberger etwa nutzte „Agentic Engineering" in bewusster Abgrenzung zum Vibe Coding schon im Juli 2025 — nachzuhören in der Podcast-Chronik, die ein früherer Artikel hier nachzeichnet.

Interessant ist der Abgleich mit der Empirie: Was das Paper konzeptuell beschreibt, deckt sich auffallend genau mit dem, was der c't-Schwerpunkt zur KI-Softwareentwicklung an Zahlen und Praxisberichten dokumentiert — bis hin zur selben Pointe, dass die Disziplin (Spezifikation, Review, Tests) über den Nutzen entscheidet, nicht das Werkzeug. Das Paper erfindet wenig; sein Wert liegt darin, verstreute Praxis zu einem benennbaren Rahmen zu ordnen.

Am Ende bleibt der eine Satz, der die 51 Seiten trägt und der sich als Prüfstein für die eigene Arbeit eignet:

Quellen

• The New SDLC With Vibe Coding — das Whitepaper auf Kaggle (Osmani, Saboo, Kartakis, Mai 2026)
• Andrej Karpathy: Vibe Coding — der Ursprungs-Post, Februar 2025
• Addy Osmani: The 80% Problem in Agentic Coding
• METR: Uplift Update — Measuring the Impact of AI Coding Tools (Februar 2026)
• Auf pyground: Vom Hype zur Handarbeit: Ein Jahr KI-Coding im Spiegel eines Podcasts und So viel Code wie nie: Wie KI die Softwareentwicklung verändert