Van Vibe Coding naar Agentic Engineering — Google's Nieuwe SDLC onder de Loep
AIGoogle publiceerde in mei 2026 een whitepaper dat de lat voor het AI-SDLC-debat serieus verhoogt: "The New SDLC With Vibe Coding, From ad-hoc prompting to Agentic Engineering" van Addy Osmani, Shubham Saboo en Sokratis Kartakis. Het is dag 1 van een serie (dag 3: Context Engineering, dag 5: Spec-Driven Production Grade Development), en het is het eerste document van een hyperscaler dat het gesprek over AI in softwareontwikkeling niet voert in termen van "sneller" of "meer regels code", maar in termen van structuur, verificatie en systeemontwerp.
Dit is onze meta-review: wat klopt, wat ontbreekt, en wat betekent het voor organisaties die onder BIO2, NIS2 of de EU AI Act opereren?
De centrale these: syntax → intent
Het paper stelt dat de belangrijkste interface in softwareontwikkeling fundamenteel verandert. Niet langer is code schrijven de primaire activiteit, het wordt intentie, architectuur, constraints en kwaliteitscriteria formuleren. AI-agents vertalen die intentie naar werkende software. De rol van de mens verschuift van "primary implementor" naar "system designer and quality arbiter."
De cijfers onderbouwen de urgentie: 85% van professionele developers gebruikt AI coding agents, 51% dagelijks, 41% van alle nieuwe code is AI-gegenereerd. Dit is geen toekomstmuziek, het is de huidige realiteit.
De evolutielijn in Figure 1 (p.8) loopt van autocomplete → inline suggesties → chat-based generation → coding agents → autonomous agents. De boodschap: autonomie van tooling neemt toe, maar daarmee stijgt ook de noodzaak voor verificatie, governance en controle. Dit is exact de paradox die we eerder signaleerden in onze analyse van vibe coding als fenomeen: snelheid zonder structuur is technische schuld op krediet.
Het spectrum: drie volwassenheidsniveaus
Het paper verwerpt de binaire framing ("vibe coding vs. agentic engineering") en biedt een spectrum met drie posities. Dit is een van de sterkste conceptuele bijdragen:
| Dimensie | Vibe Coding | Structured AI-Assisted | Agentic Engineering |
|---|---|---|---|
| Intentie | Casual NL prompts | Prompts met constraints | Formele specs, architectuur, memory files |
| Verificatie | "Lijkt het te werken?" | Handmatige checks | Tests, CI/CD gates, evals, LM judges |
| Scope | Prototypes, scripts | Features in bestaande codebases | Productiesystemen |
| Risico | Hoog | Middel | Lager, mits goed ingericht |
De kritieke cesuur is verificatie. Zonder tests én evals, voor niet-deterministische agent-trajecten, is élke praktijk vibe coding, ongeacht hoe sophisticated de prompts zijn. Een agent die 100 regels perfecte code genereert zonder dat je kunt bewijzen dát het perfect is, is nog steeds een black box.
Governance-implicatie: Dit spectrum is direct vertaalbaar naar beleid. Prototypes mogen vibe coding gebruiken, mits geïsoleerd van productie, zonder gevoelige data en zonder automatische deployment. Businesskritische software vereist agentic engineering: formele requirements, threat model, test coverage, eval coverage, code review, SBOM, secrets scanning, CI/CD gates en audit logging. Voor gereguleerde omgevingen is "vibe coding in productie" simpelweg een control failure. Dit sluit naadloos aan op onze OpenSpec governance-laag voor AI-gegenereerde code.
Context engineering: de kerncompetentie
Het paper stelt, terecht, dat de kwaliteit van AI-output minder afhangt van slimme prompts en meer van de kwaliteit van de context: instructies, kennis, memory, voorbeelden, tools en guardrails. Het onderscheid tussen static context (system instructions, AGENTS.md, CLAUDE.md) en dynamic context (skills, tool results, RAG-documenten, sessiehistorie) is fundamenteel.
Dit is waarschijnlijk het belangrijkste enterprise-inzicht in het document. Context engineering moet behandeld worden als configuratie, architectuur en policy tegelijk. Het hoort niet in persoonlijke prompts van individuele developers, maar in version-controlled repositories met ownership, reviewproces en lifecycle management. We schreven hier eerder uitgebreid over in onze context engineering deep-dive.
Voor enterprise-adoptie betekent dit concreet:
- AGENTS.md wordt een gecontroleerd architectuurartefact, geen persoonlijke cheat sheet
- Prompt- en skill-wijzigingen gaan via pull requests, met review, niet via copy-paste
- Guardrails worden getest zoals code, regressietests op policy-schendingen
- Agent memory krijgt dataclassificatie en retentiebeleid, geen eeuwige retention van gevoelige context
- Tool access wordt beheerd via least privilege, scoped tokens, OAuth2/OIDC, just-in-time access
- Context poisoning, prompt injection en data leakage worden expliciete threat scenarios, geen bijzaak in een threat model
De nieuwe SDLC: wat versnelt, wat niet
Het paper beschrijft een cruciaal realisme: AI versnelt de SDLC niet uniform. Implementatie kan van weken naar uren gaan. Requirements, architectuur en verificatie blijven mens-intensief. De iteraties worden korter, maar de complexiteit van kwaliteitscontrole neemt toe.
Per SDLC-fase:
- Requirements: AI helpt bij user stories, edge cases en API-schema's. Risico: vage requirements worden sneller omgezet in foutieve software. Garbage in, garbage out, maar nu op industriële schaal.
- Architectuur: blijft primair menselijk. AI kan opties genereren, maar trade-offs rond security, compliance, latency, data residency, vendor lock-in en operating model vragen menselijk oordeel. Dit is waar onze architecturale cognitie-analyse op aansluit.
- Implementatie: AI versnelt boilerplate, refactoring, testgeneratie en multi-file changes. Risico: hallucinated dependencies, subtiele business logic fouten, gebrekkige error handling.
- Testing en QA: tests en evals worden de primaire contractlaag tussen mens en agent. Het paper benadrukt het verschil tussen output evaluation (werkt de gegenereerde code?) en trajectory evaluation (hoe kwam de agent tot deze output?). Dit is exact wat we bouwen in onze benchmark factory.
- Review en deployment: AI kan eerste reviewer zijn, maar mag menselijke beoordeling niet vervangen. Security, maintainability en strategische alignment blijven menselijke verantwoordelijkheid.
- Maintenance: AI kan legacy code toegankelijker maken, maar dit vereist sterke testharnassen, anders wordt modernisering een versneller van regressies.
Harness engineering: het operationele hart
Het paper introduceert de harness als alles rondom het model: prompts, tools, context policies, hooks, sandboxes, observability, sub-agents en orchestration. Dit is sterk, omdat het de focus verlegt van "welk model gebruiken we?" naar "welk systeem bouwen we rondom het model?", een thema dat we eerder analyseerden in onze DeepSeek harness-architectuur post.
Een production-grade AI coding capability vereist minimaal:
- Sandboxed execution
- Scoped tool permissions
- Repository-level policy enforcement
- Secrets detection
- Dependency allowlists
- SAST, DAST, SCA en IaC scanning
- CI/CD gates
- Eval harness
- Observability per agent-run
- Token, latency en cost metering
- Audit trail voor agentbeslissingen
- Human approval gates bij high-risk changes
Zonder dit wordt AI-assisted development een shadow engineering praktijk, developers die productiecode genereren via persoonlijke ChatGPT-subscriptions, zonder enige governance. Voor BIO2-auditors is dat een nachtmerrie.
Developerrol: conductor en orchestrator
Het paper onderscheidt twee operationele modi:
- Conductor: hands-on, realtime begeleiding in IDE of terminal. Fine-grained control.
- Orchestrator: asynchroon werk delegeren aan agents, reviewen en bijsturen. Hoger abstractieniveau, multi-agent delegatie.
Dit raakt direct aan talentontwikkeling. De waarde van engineers verschuift naar: specificatiekwaliteit, systeemdenken, architectuurbeslissingen, threat modeling, review van AI-output, debugging van agent trajectories, en beoordelen van "looks correct" versus "is correct."
Traditionele productiviteitsmetingen zoals lines of code worden nog minder relevant. Betere KPI's: cycle time, change failure rate, escaped defects, eval pass rate, security finding density, mean time to verify, en percentage AI-generated code met volledige review en testdekking.
Economie: CapEx vs OpEx
Een van de scherpste inzichten in het paper is de economische analyse:
| Vibe Coding | Agentic Engineering | |
|---|---|---|
| CapEx | Nihil (subscription + prompts) | Hoog (specs, tests, harness, context design) |
| OpEx | Hoog (token burn, maintenance tax, security remediation) | Laag (first-pass success, structurele consistentie) |
| Token economie | Massive unstructured context → dure loops | Dense high-signal context → hoge first-pass rate |
Vibe coding lijkt aanvankelijk goedkoop, maar veroorzaakt later kosten door token burn, onderhoud, security remediation en context collapse. Agentic engineering vraagt vooraf investering, maar verlaagt de marginale kosten van betrouwbare delivery.
Mijn aanvulling: TCO moet minimaal bestaan uit toolingkosten, licenties, tokens, tijd voor context engineering, tijd voor eval-ontwikkeling, security en compliance controls, extra reviewcapaciteit, incident- en defectkosten, model-routingkosten, vendor lock-in risico, en training en operating model change. De passage over intelligent model routing is relevant: gebruik frontier models voor complexe requirements en architectuur, maar kleinere modellen voor testgeneratie, review en CI/CD-monitoring. Context engineering is niet alleen een technische skill, het is een financiële strategie.
De governance-lacune: wat Google niet zegt
Dit is waar het paper tekortschiet, en waar de Nederlandse gereguleerde markt meer nodig heeft. Het document noemt guardrails, sandboxing, observability en zero-trust ontwikkeling, maar werkt die niet diep genoeg uit voor enterprise- of gereguleerde contexten.
Wat ontbreekt:
- Data governance: welke data mag in prompts, context windows, memory en RAG terechtkomen? Onder BIO2 is dit geen vrijblijvende vraag, het is een controle-eis.
- Privacy: hoe voorkom je verwerking van persoonsgegevens, bedrijfsgeheimen of klantdata in agent-context? De AVG kent geen "AI-uitzondering."
- Identity en access: hoe worden agents geauthenticeerd, geautoriseerd en gelogd? Een agent die als 'developer' commits pusht is een accountability-gat.
- Token lifecycle: hoe beheer je OAuth2/OIDC tokens die agents gebruiken voor tools, repositories en cloud resources?
- Supply chain: hoe voorkom je dat agents hallucinated packages, typosquatting dependencies of kwetsbare libraries introduceren?
- Prompt injection: hoe bescherm je agents tegen malafide repo-content, issues, tickets, documentatie of webresultaten? Dit is het OWASP Top 10 for LLM Applications-domein dat we eerder analyseerden.
- Auditability: hoe bewijs je achteraf waarom een agent een bepaalde wijziging heeft gedaan? Voor een NIS2-auditor is "de AI deed het" geen acceptabel antwoord.
- Segregation of duties: mag een agent code schrijven, tests aanpassen én deployen in dezelfde flow?
- Regulatory evidence: hoe toon je aan dat AI-generated code voldoet aan ISO 27001, SOC 2, NIS2, DORA of interne SDLC-controls?
Voor een enterprise-versie van dit paper zou ik een apart hoofdstuk verwachten over secure agentic SDLC, met mapping naar NIST SSDF, OWASP SAMM, OWASP Top 10 for LLM Applications, ISO 27001 Annex A en Zero Trust-principes. Dat hoofdstuk ontbreekt. Het is de governance-laag die het verschil maakt tussen "AI versnelt onze delivery" en "AI versnelt onze productie van technische schuld."
Risicoregister voor adoptie
Op basis van het paper en mijn eigen analyse, dit is het risicoregister dat elke organisatie zou moeten hanteren bij AI-SDLC-adoptie:
| Risico | Impact | Waarschijnlijkheid | Mitigatie |
|---|---|---|---|
| AI genereert foutieve maar plausibele code | Hoog | Hoog | Verplichte tests, evals, code review, property-based testing |
| Secrets of gevoelige data lekken via prompts/context | Hoog | Middel | DLP, context filtering, secret scanning, no-production-data policy |
| Agent krijgt te brede toolrechten | Hoog | Middel | Least privilege, scoped tokens, OAuth2/OIDC policy, JIT access |
| Hallucinated dependencies | Middel/Hoog | Hoog | Package allowlists, SCA, dependency pinning, artifact signing |
| Vibe prototypes worden per ongeluk productie | Hoog | Hoog | Environment boundaries, release gates, policy-as-code |
| Evals meten het verkeerde | Middel/Hoog | Middel | Rubrics, golden datasets, periodic calibration, human sampling |
| Kosten lopen op door token burn | Middel | Hoog | Dynamic context, model routing, caching, cost observability |
| Accountability wordt onduidelijk | Hoog | Middel | Human owner per agent-run, audit trails, approval gates |
| Context rot en prompt drift | Middel | Hoog | Versioning, PR-review op prompts/skills, scheduled eval regression |
| Security review schaalt niet mee met PR-volume | Hoog | Hoog | AI-first review triage, risk-based review, mandatory human approval voor critical paths |
Praktische adoptieroadmap
Een verstandige enterprise-aanpak faseer ik als volgt:
Fase 1, Controlled experimentation. Start met niet-productiekritische workflows: testgeneratie, documentatie, refactoringvoorstellen, code explanation. Maak AGENTS.md verplicht per pilot-repo. Verbied productiegegevens in prompts. Meet kwaliteit, doorlooptijd, defecten en reviewlast.
Fase 2, Structured AI-assisted development. Introduceer formele context engineering. Versioneer prompts, rules, skills en evals. Voeg SAST, SCA, secrets scanning, dependency policies en CI/CD gates toe. Definieer welke AI-output altijd menselijke review vereist.
Fase 3, Agentic engineering platform. Bouw een gedeelde harness: sandbox execution, tool registry, identity layer, model routing, telemetry, eval service, policy-as-code en audit logging. Maak agents onderdeel van het SDLC-platform, niet van individuele developer tooling.
Fase 4, Production agents en multi-agent workflows. Pas MCP of vergelijkbare tool-access standaarden toe, maar alleen met expliciete security boundaries. Introduceer agent-to-agent workflows pas wanneer observability, evals en access controls volwassen zijn. Zorg dat elke productie-agent een service owner, threat model, eval suite en rollbackplan heeft.
Conclusie
De hoofdboodschap van het Google-paper is sterk en bruikbaar: generation is solved, verification, judgment and direction are the new craft. Het paper stelt terecht dat structuur schaalbaar is en vibes niet. Voor productieomgevingen zijn specificaties, tests, evals, guardrails en menselijke architectuurcontrole geen optionele extra's, maar de kern van het nieuwe SDLC-model.
Mijn eindbeoordeling: waardevol strategisch document, vooral als startpunt voor leiderschap en engineering-transformatie. De grootste waarde zit in de mental models: het spectrum, context engineering, het harness-model, de factory-gedachte en de verschuiving van developer naar conductor en orchestrator.
Voor enterprise-adoptie, en zeker voor de Nederlandse gereguleerde markt onder BIO2, NIS2 en de EU AI Act, moet het worden aangevuld met een harde governance- en securitylaag: Zero Trust voor agents, secure SDLC-controls, privacy-by-design, supply-chain beveiliging, identity governance en auditability. Zonder die laag versnelt AI vooral de productie van technische schuld. Met die laag kan agentic engineering uitgroeien tot een serieuze next-generation delivery capability.
Het Software 3.0-paradigma is niet langer een theoretische exercitie, Google's paper maakt het operationeel. De vraag is niet óf je organisatie AI in de SDLC adopteert. De vraag is of je het doet met een harness, of zonder.
Addy Osmani, Shubham Saboo & Sokratis Kartakis, "The New SDLC With Vibe Coding, From ad-hoc prompting to Agentic Engineering," Google, mei 2026. Dag 1 van een serie; dag 3 (Context Engineering) en dag 5 (Spec-Driven Production Grade Development) zijn aangekondigd maar nog niet beschikbaar.
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten, direct in uw inbox.
Security & AI Operating Model
Advisory met executiekracht
Van BIO2 en NIS2 tot EU AI Act, embedded in uw operating model, niet als extern project. Maandelijks opzegbaar, met assessments als bewijsvoering.