Primärquelle: Googles Whitepaper als PDF
Agentic Engineering ist Googles Begriff für disziplinierte KI-Entwicklung mit Specs, Tests, Evals und Harness — im Gegensatz zu Vibe Coding, dem prompt-getriebenen Schnellbau ohne Verifikation. Das Whitepaper The New SDLC With Vibe Coding (Addy Osmani, Shubham Saboo, Sokratis Kartakis, Mai 2026) ist die kanonische Day-1-Quelle der 5-Tage-KI-Agenten-Kursreihe von Google (öffnet in neuem Tab).
Steve Baka hostet das Original-PDF hier zum direkten Download: Google — The New SDLC With Vibe Coding (PDF, ~50 Seiten) (öffnet in neuem Tab). Ergänzend: Addy Osmanis Einordnung mit sechs Kernfiguren (öffnet in neuem Tab) und das begleitende YouTube-Masterclass-Video (öffnet in neuem Tab).
Dieser Artikel fasst die für DACH-Dienstleister und Agenturen relevanten Punkte zusammen — mit Steve-Baka-Praxisbezug zu Harness, Human-in-the-Loop, skill.md und Context-/Agent-Readiness.
Was unterscheidet Agentic Engineering von Vibe Coding?
Agentic Engineering ist KI-gestützte Softwareentwicklung mit formalen Specs, automatisierten Tests, Evals und menschlicher Architekturaufsicht. Vibe Coding beschreibt prompt-getriebenes Bauen ohne systematische Verifikation — sinnvoll für Prototypen, riskant für Produktion.
Der Unterschied ist kein anderes Tool, sondern Verifikation: Bei Vibe Coding reicht „läuft irgendwie“. Bei Agentic Engineering prüfen Tests deterministische Teile (Input → Output) und Evals nicht-deterministische Teile (Tool-Trajektorie, Qualitätsrubrik, LM-Judges). Ohne beides bleibt es Vibe Coding — egal wie teuer das Modell ist.
Googles Spektrum-Tabelle (Mai 2026) ordnet Intent, Verifikation, Fehlerbehandlung und Risikoprofil entlang einer Achse. Faustregel aus dem Paper: Wochenend-Prototyp = Vibe Coding; Payment-API in Produktion = Agentic Engineering. Die meiste Alltagsarbeit liegt dazwischen — die Kunst ist die Grenze pro Task.
Warum ist der Harness wichtiger als das Modell?
Ein KI-Agent ist nicht nur ein Modell, sondern Modell plus Harness: Instructions, Tools, Sandboxes, Orchestration, Hooks und Observability. Google schätzt grob 10 % Modell, 90 % Harness — hoch, bis man eine Woche lang fehlende Guardrails debuggt hat.
Öffentliche Benchmarks aus dem Whitepaper: Auf Terminal Bench 2.0 stieg ein Team nur durch Harness-Änderungen (gleiches Modell) von außerhalb Top 30 in die Top 5. LangChain verbesserte denselben Benchmark um 13,7 Punkte allein über System-Prompt, Tools und Middleware.
Praxis für Beratungen: Wenn ein Agent „dumm“ wirkt, zuerst Harness prüfen — fehlendes Tool, vage Regel, kein Hook, vollgestopftes Kontextfenster. Das ist Konfigurationsfehler, kein Modell-Waiting-Game. Steve Baka setzt deshalb Harness-Komponenten (AGENTS.md, Skills, MCP, Eval-Gates) vor Modell-Upgrades — siehe MCP vs. CLI und Prompting ist kein Prozess.
Was ist Context Engineering — und warum entscheidet es über Kosten?
Context Engineering heißt: dem Agenten strukturiert liefern, was ein guter neuer Teamkollege bräuchte — nicht clever formulierte Einzeiler. Google nennt sechs Kontexttypen: Instructions, Knowledge, Memory, Examples, Tools, Guardrails.
Die zentrale Architekturentscheidung ist statisch vs. dynamisch. Statischer Kontext (AGENTS.md, CLAUDE.md, GEMINI.md, globale Regeln) wird jede Runde geladen — zuverlässig, teuer. Dynamischer Kontext (Skills, RAG, Tool-Ergebnisse) wird on demand geladen — effizient, aber leicht vergesslich.
Agent Skills mit Progressive Disclosure sind Googles Antwort auf Skalierung: Metadata beim Start, volle Anleitung bei Task-Match, Referenzmaterial nur bei Bedarf. Für DACH-Teams ist das finanziell relevant: Unstrukturierte 100k-Token-Dumps in jeden Prompt sind bei API-Preisen nicht skalierbar. Context Engineering ist Token-Ökonomie — eng verwandt mit skill.md und llms.txt.
Wie verändert KI den Software Development Life Cycle?
KI komprimiert den SDLC ungleichmäßig: Implementation von Wochen auf Stunden; Requirements, Architektur und Verifikation bleiben menschlich langsam. Der Engpass wandert von Tippen zu Spezifikation und Prüfung.
Requirements werden Gespräch statt Dokumentenübergabe — User Stories, Edge Cases und erste Prototypen entstehen parallel. Architektur bleibt am menschlichsten (Konsistenz vs. Verfügbarkeit, Build vs. Buy). Implementation wird Review statt Schreiben: Surveys nennen 25–39 % Produktivitätsgewinn; METR (Feb. 2026) fand bei erfahrenen Devs auf manchen Tasks 19 % längere Dauer nach Verifikationszeit.
Testing/QA dreht sich: Tests und Evals definieren, was „korrekt“ heißt — inkl. Trajectory-Eval (war der Weg plausibel?) neben Output-Eval. Maintenance gewinnt: „zu riskant anzufassen“-Legacy wird mit Agenten navigierbar. Für Agenturen heißt das: Delivery-Prozesse brauchen neue Review-Checklisten für KI-Code — nicht nur schnellere Texte.
Was ist das Factory Model für KI-Entwicklung?
Im Factory Model liefert der Entwickler nicht primär Code, sondern das System, das Code produziert: Specs, Agenten, Tests, Feedback-Loops, Guardrails. Der Vergleich: Fabrikleiter baut keine jedes Widget von Hand, sondern die Linie mit Qualitätskontrolle.
Erfolg kommt von Erfolgskriterien statt Schritt-für-Schritt-Mikromanagement — dann iteriert der Agent innerhalb der Grenzen. Das Paper verbindet das mit Harness Engineering über alle SDLC-Phasen: Konfiguration (Rules), Laufzeit (Sandbox + Tools), Feedback (Tests/Evals), Beobachtung (Hooks, Traces, Kosten).
Steve Baka übersetzt das für Dienstleister: Nicht „noch ein Chatbot“, sondern Arbeitsoberfläche mit Zustand, Freigaben und Logs — wie in KI-Inbound-Triage. Die Factory ist euer Prozess- und Qualitätsgerüst, nicht das Modell-Du-Jour.
Conductor oder Orchestrator: Welche Rolle übernimmt der Entwickler?
Google unterscheidet zwei Modi: Conductor (Echtzeit im IDE, Feinsteuerung, Pair-Programming) und Orchestrator (async, Ziele delegieren, Ergebnisse reviewen). Beides ist legitim — oft am selben Tag.
Conductor passt zu komplexer Logik, Debugging und unbekannten Codebasen (Copilot, Cursor, Windsurf). Risiko: Der Mensch wird Bottleneck, wenn jede Zeile persönlich dirigiert wird.
Orchestrator passt zu klar spezifizierten Tasks: Bugfixes nach Pattern, Migrationen, Test-Suites (Jules, Background Agents, Claude Code async). Geforderte Skills: Spezifikation, Dekomposition, Evaluation, Systemdesign. Für Agentur-Teams heißt das: Rollen und Freigaben explizit machen — nicht jeder darf alles, auch die KI nicht.
Was ist das 80-Prozent-Problem bei KI-Code?
Das 80-Prozent-Problem: Agenten liefern ~80 % eines Features schnell; die letzten 20 % (Edge Cases, Integration, subtile Korrektheit) brauchen Kontext, den Modelle oft nicht haben. Fehler verschieben sich von Syntax zu falschen Business-Annahmen und „sieht richtig aus, ist es nicht“.
Effektive Teams nutzen KI für gut spezifizierte Blöcke und reservieren menschliche Aufmerksamkeit für Ambiguität, Architektur und Verifikation. Schneller werden heißt nicht alles blind akzeptieren — sondern Expertise dort einsetzen, wo sie zählt.
Für Beratungs- und Audit-Content: Das ist der Grund, warum Steve Baka Evals vor Demos fordert und KI-Audits auf Prozessreife statt Tool-Listen ausrichtet.
Warum kostet Vibe Coding langfristig mehr als Agentic Engineering?
Ökonomisch invertiert KI die übliche Intuition: Vibe Coding = niedriges CapEx, hohes OpEx (Subscription + Prompt-Loops + Wartung + Security-Nacharbeit). Agentic Engineering = höheres CapEx (Schemas, Tests, strukturierter Kontext), niedrigeres OpEx pro Feature.
Token-Burn entsteht durch unstrukturierte Kontext-Dumps und wiederholtes „fix deinen eigenen Müll“. Wartungssteuer trifft, wenn niemand den ad-hoc-KI-Code sechs Monate später versteht. Illustrative Crossover-Kurve im Ökosystem: Nach einem Punkt kann Vibe Coding 3–10× teurer pro Feature werden — abhängig von Lebensdauer und Risiko (vgl. Zusammenfassungen zu Osmanis Paper).
Intelligent Model Routing senkt OpEx: Frontier-Modelle für Architektur und schwere Reasoning; kleine Modelle für Tests, Review, CI-Monitoring. Context Engineering und Routing sind Finanzhebel, nicht nur Tech-Nerdigkeit.
Wo sollten Agenturen und Dienstleister anfangen?
Aus dem Whitepaper — übersetzt auf Steve-Baka-Praxis: 1) AGENTS.md (oder Äquivalent) mit Stack, Regeln, Workflow — bei jedem Agenten-Fehler eine Zeile nachziehen. 2) Skills installieren und versionieren (skill.md-Standard). 3) Einen repetitiven Workflow zum ersten echten Agenten machen — nicht hundert lesen.
4) Tests und Evals vor Code-Generierung — sie sind der Vertrag mit der KI. 5) Jede shipping-Zeile reviewen; Imports und Error-Handling prüfen. 6) Grundlagen-Kompetenz pflegen — KI skaliert Expertise, ersetzt sie nicht.
Für Führung: Context Engineering als Review-Pflicht (wie Code), Bar am Eval nicht am Demo, klare Grenze Prototyp vs. Produktion, Harness als Team-Infrastruktur. Drei durable Principles aus dem Paper: Struktur skaliert, Vibes nicht. KI verstärkt eure Engineering-Kultur — Stärken und Schwächen. Die menschliche Rolle wandert zu Urteil und Richtung. Schlusszeile Google: Generation is solved. Verification, judgment, and direction are the new craft.
