Google just published a report I really enjoyed: "The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering", signed by Addy Osmani, Shubham Saboo and Sokratis Kartakis.
I read a lot about AI and software, and most of it is either hype or doom. This report is neither. It's a calm, structured framework for what is actually happening to the way we build software, and it puts precise words on things I've been doing daily for the last 18 months as a Product Engineer.
Here are the lessons that stuck with me, and how each one maps onto real work.
The real shift: from syntax to intent
The biggest change in software isn't a new language or framework. It's the move from writing code to expressing intent, and trusting intelligent systems to turn that intent into working software.
For decades, the developer's interface to the machine was syntax: braces, semicolons, the exact grammar of a language. That era is ending. The report cites a striking figure for early 2026: around 85% of professional developers regularly use AI coding agents, and a large share of new code is AI-generated.
I felt this shift concretely the day I coded a web crawler in three days, a project that would have taken me two to three weeks before. The bottleneck was no longer typing. It was deciding what to build and how to verify it was right.
The spectrum: vibe coding vs agentic engineering
This is the part of the report I'd hand to anyone confused by the buzzwords.
"Vibe coding," the term Andrej Karpathy coined in early 2025, went viral and then lost meaning. It got applied to everything from a senior engineer implementing a well-specified feature to someone accepting whatever the AI spits out. So Karpathy himself later introduced "agentic engineering" to describe the disciplined end of the spectrum.
The report's framing is that these aren't two camps. They're two ends of a spectrum, and the differentiator is not whether you use AI. It's how much structure, verification and human judgment surround the AI's output.
- Vibe coding: minimal scaffolding, aimed at speed. You prompt, you accept, you ship. Great for exploration and throwaway prototypes.
- Agentic engineering: explicit constraints, tests, and feedback loops, with humans owning architecture, correctness and quality.
The report has a line that nails the stakes: telling a CTO your team is vibe coding the payment system should raise alarm bells. Telling them you practice agentic engineering, with AI implementing under human-designed constraints while test coverage guards correctness, is a completely different conversation.
That distinction is exactly why I'm careful about how I describe my own work. When I built two MCP servers for my SaaS, or when I ship features on Begonia.pro, the AI writes most of the code, but inside a structure I designed and review. As the report puts it: "Structure scales, vibes don't."
Context engineering is the real skill
The quality of AI-generated code depends less on clever prompts and more on the quality of the context you give the model.
The report calls this context engineering, and breaks the context an agent needs into six types: instructions, knowledge, memory, examples, tools, and guardrails. Then it draws a line that matters in practice:
- Static context is always loaded: system instructions, rule files like
AGENTS.mdorCLAUDE.md, persona definitions. Reliable, but expensive: every token is present in every interaction. - Dynamic context is loaded on demand: skills triggered by the task, tool results, documents fetched at runtime. Efficient, because you pay only when the information is needed.
The most powerful pattern they describe is Agent Skills: portable packages of procedural knowledge an agent loads only when the task calls for it. The agent stays a lightweight generalist and flexes into a specialist on demand.
The question stops being "how do I trick the AI into writing good code?" and becomes "what would a new teammate need to know to do this well, and how do I encode that?" That's a far healthier way to think, and it's why I treat my rule files and project docs as seriously as the code itself.
The new software lifecycle: specification becomes the bottleneck
AI compresses the software development life cycle, but unevenly. Implementation that used to take weeks now takes hours, while requirements, architecture and verification stay human-paced.
Once typing code on the keyboard is no longer the bottleneck, something else becomes the constraint: the quality of the specification. The clearer the intent you hand the AI, the better the code that comes out. The developer's job shifts from primary implementer to system designer and quality arbiter, and the leverage moves upstream, to defining precisely what should be built.
This is exactly how my day looks now. I spend more time on the spec than on the code: creating structured notes in Markdown with AI, framing the problem, the users, the scope and the known trade-offs, rather than a 10-page PRD. The implementation comes next, driven by the AI ​​that I manage and review. Getting those specs right is the highest-leverage thing I do.
Conductor and orchestrator: two modes of working
I found this topic in the report genuinely useful for explaining my work to non-technical clients.
The report describes two modes developers move between:
- Conductor: real-time, in the IDE, watching code appear, guiding with prompts and corrections. Fine-grained control, single-file scope. Best for exploratory coding, debugging tricky logic, learning an unfamiliar codebase.
- Orchestrator: asynchronous and higher-level. You define goals, hand them to agents working in the background, and review the output. Goal-level control, multi-file scope. Best for well-specified features, migrations, test generation.
Most developers move fluidly between both, depending on the task. On Begonia.pro, the Local SEO SaaS I build solo, I switch between the two on the same codebase: I conduct when I build a tricky feature or chase a bug, staying in the IDE and reviewing each change; I orchestrate when I hand a well-defined task to a background agent and review the result later. The skill isn't picking a side; it's knowing which mode the task deserves, and noticing when conducting every keystroke has quietly become a bottleneck.
The 80% problem: where human judgment stays
Anyone who thinks AI now does the whole job should sit with this one.
Agents can rapidly generate roughly 80% of the code for a feature. The remaining 20% (edge cases, error handling, integration points, subtle correctness) demands deep contextual knowledge models often lack. And these errors are harder to catch precisely because the code looks right and may even pass basic tests.
The developers who navigate this best adopt a specific posture: they use AI for what it's good at, the rapid implementation of well-specified work, and reserve their attention for what it struggles with: ambiguous requirements, architectural trade-offs, correctness verification. They don't get faster by accepting everything. They get faster by focusing their expertise where it matters.
This is the whole game, honestly. Knowing the AI wrote something is easy. Knowing whether it's right is the job.
The economics: vibe coding's hidden debt
For founders and engineering leaders, the cost argument is the one that lands.
At first glance, vibe coding looks almost free: a subscription and a few prompts. But the report argues it hides a compounding operational cost: a "token burn rate" from dumping unstructured context and repeatedly asking the model to fix its own unverified mistakes, plus a maintenance tax when unstructured, AI-generated "spaghetti" has to be reverse-engineered six months later.
Agentic engineering flips the equation: a higher upfront investment (designing schemas, building tests, structuring context) in exchange for a dramatically lower cost to ship and maintain each feature. The report frames context engineering as not just a technical skill but a financial lever, and adds intelligent model routing on top (use big models for hard reasoning, cheap fast models for deterministic tasks).
Translation for anyone commissioning software: the cheapest-looking option upfront is often the most expensive over the product's life. Structure isn't bureaucracy; it's how you keep the marginal cost of the next feature low.
What this means if you're building a product
The concluding sentence summarizes the entire report in one lesson: AI amplifies your engineering culture. It multiplies both your strengths and your weaknesses. Teams with strong testing, clear architecture and healthy review get dramatically more out of AI than teams without.
For a solo founder or a product team, the practical implications are concrete:
- Invest in the spec before the code. The bottleneck is intent, not typing.
- Treat context as infrastructure. Rule files, tests and guardrails are assets that keep paying back.
- Keep a human owning correctness. Especially on the 20% that looks right but isn't.
- Match the mode to the task. Conduct when you need control, orchestrate when the task is well-defined.
This is exactly the discipline I bring as a Product Engineer: AI in the workflow and in the product, but inside a structure that's designed, tested and reviewed, not vibe-coded and hoped for. If you want to open your SaaS to AI agents with an MCP server, or ship an MVP without trading speed for a maintenance nightmare, that's the work.
Your turn
Google's report names a shift many of us have been living through without the vocabulary for it. The terms (agentic engineering, context engineering, the factory model, the 80% problem) describe the new reality of software development and are here to stay.
And you? Where does your team sit on the spectrum between vibe coding and agentic engineering, and is the boundary explicit, or are you shipping prototypes by accident?
📌 If you have a product to build, an existing SaaS to connect to AI, or simply want to bring more structure to how you use these tools, discover my Product Engineering services.