Agentic Engineering: not whether you use AI, but how
- Agentic Engineering
- Vibe Coding
- Harness
- Context Engineering
- SDLC
I came across a blog post by Addy Osmani this week and then read the Google whitepaper behind it: “The New SDLC With Vibe Coding”, by him together with Shubham Saboo and Sokratis Kartakis. It describes how AI is reshaping software development, from casual “vibe coding” to disciplined “agentic engineering”. And it says out loud what I have been telling clients for months.
The shift is real, just not the one the hype means
I have lived through three major technology shifts. Each time, the claim was that everything changes now. Usually part of it was true and the rest was show. This one is real. But the core isn’t “AI writes the code now”. The core is the move from syntax to intent: I describe what should be built, and the judgment about whether it holds up stays with me.
According to the paper, by early 2026 around 85 percent of developers already use AI coding agents regularly, more than half daily, and a substantial share of new code is AI-generated. That matches my own day in the team.
The difference isn’t the AI, it’s the verification
The best idea in the paper, for me: the difference between a toy and production isn’t whether you use AI, it’s how much structure and verification surrounds the output.
The authors draw a spectrum. At one end, “vibe coding”: prompt in, take the result, glance at whether it runs. At the other end, “agentic engineering”: clear specs, automated tests, reviews, AI as the engine inside guardrails, the judgment over architecture and correctness with a human.
The single biggest difference between the two ends is how outputs get verified.
That is exactly my “substance over effect”. A weekend prototype may be pure vibe coding. A payment system may not. The skill is knowing, for each task, where the line sits.
Context beats a clever prompt
The part closest to my heart: the quality of AI code depends less on the clever prompt than on the context the AI gets. The paper calls it context engineering, and that is exactly how I work.
The AI gets no magic words from me, it gets what a new colleague would need: clear rules in versioned files like AGENTS.md, the architecture, the conventions, examples, hard limits. What is always loaded and what is fetched on demand is an architecture decision, not a detail. Tests verify the deterministic parts, evaluations the non-deterministic ones. Without both, it stays vibe coding, however clever the prompt sounds.
What it means in practice
For me, this changes the role, not the standard. I type fewer lines and make more decisions: what pays off, what stays out, where to draw the line, how it gets verified. That is what 37 years are good for. Not for typing fast, but for the judgment of whether something will still hold up in five years.
AI doesn’t make that judgment redundant, it makes it more important. Skip it, and you produce a lot of code very fast that no one understands later.
A good read, clear language, and finally a term for the difference that counts. If you are weighing where AI genuinely helps your product and where it only looks good: that line is exactly my work.