Last night I was working through the practice exams for an architect-level AI certification, and I got two scenarios “wrong” in a way I want to talk about — because I’m still not convinced I was wrong.
The first scenario: an agent flags a piece of content as inappropriate, and the user requests an overturn. Who reviews the request? The exam’s preferred answer was to spin up another agent to review it. My answer was a human — every time, for sensitive calls like that. The second scenario: an agent that speaks both Postgres and Snowflake SQL keeps misformatting queries and submitting them. The exam wanted a rule telling the agent to format queries correctly at submission time. My answer was a hook that intercepts anything tagged as Snowflake SQL and reformats it automatically — enforcement that runs whether or not the agent remembers the rule.
I’ve deployed HIPAA-compliant architecture on Snowflake at scale, so those two questions weren’t theory to me. But I’ll concede the exam writers their judgment calls, because who’s right is genuinely debatable — and the debate is the point. Both disagreements are the same disagreement: does discipline live in the prompt, where it’s a suggestion, or in the system, where it’s enforced?
That question is the entire difference between vibe coding and agentic engineering. And if you’re a business owner paying for AI work, it’s the difference between buying a demo and buying a system.
The two terms, in plain English
Vibe coding is describing what you want to an AI and accepting what comes back. It feels like magic, and for prototypes it often is. The failure mode is just as fast: something breaks in week three, nobody knows why, the fix breaks two other things, and the “almost working” project quietly dies. If you’ve paid for an AI pilot that went nowhere, there’s a decent chance this is what you actually bought. The industry numbers say you’re not alone — most generative AI pilots never show measurable impact on the profit and loss statement. The models aren’t the bottleneck. The missing discipline is.
Agentic engineering is everything that surrounds the model: the specification written before the first prompt, the plan a human approves, the sub-agents delegated narrow jobs, the hooks that enforce the rules mechanically, the tests that decide what “done” means, and the memory that keeps hard-won lessons from evaporating between sessions. The agent still writes the code. The engineering decides whether the code survives contact with reality.
Same model. Opposite outcomes.
A story from the trenches
Not long ago, we brought in a principal-level contractor on a build. Six weeks of paid work later, I rejected the entire deliverable and rebuilt it myself with an agentic workflow — faster than the original timeline. That’s not a boast about being smarter; the contractor is a fine traditional engineer. It’s a statement about leverage: one engineer with a disciplined agentic process now out-produces small teams working the old way. I’ve watched it hold up head-to-head, and it’s why our builds are priced in weeks, not months.
The talent landscape shifted in 2026
The leverage story has a flip side, and it’s about people, not tooling. The talent landscape shifted under everyone’s feet in 2026. Agentic coding harnesses have become the norm inside serious engineering organizations, and the managers running them are starting to recognize what that does to the skill hierarchy.
For thirty years, seniority meant recall: the engineer who knew the framework internals, the deployment incantations, the obscure failure modes earned through scar tissue. That knowledge still has value — it just isn’t the scarce resource anymore. An agentic workflow absorbs a new framework the way it absorbs anything else: a research pass, a review of the technical documentation, and it’s implementing fluidly in something released last week. Frameworks change daily now. Nobody’s recall keeps pace with that, and nobody’s needs to.
What’s scarce instead is architecture — and not in the old sense of memorizing which services fit together. It’s knowing which frameworks actually deliver a best-in-class solution for the problem in front of you, and how a system should fit together so it can be tested, enforced, and operated. Line-by-line code review matters less than it used to; system-level judgment matters more than it ever has.
So the real technical skill of 2026 and beyond isn’t encyclopedic knowledge of a stack. It’s applying creativity and business logic to solutions — maximizing return on investment, minimizing spend, and delighting clients. The engineers who thrive treat frameworks as interchangeable and judgment as the product.
What the discipline actually looks like
I use AI coding agents exclusively in my work, and I’ve deployed serious production systems at rates that would have been unimaginable two years ago. None of that is because I’m better at prompting. Here’s the machinery, translated:
Start with a contract, not a prompt. I’m building a voice companion for an elderly woman with early dementia — three previous attempts by others had failed by over-engineering. Before any code, my process produced a discovery questionnaire, then a 2,400-line machine-readable requirements contract: 23 requirements and 89 acceptance criteria, an architecture document, immutable decision records, and build phases whose exit criteria a test can check. The blend is spec-driven development and test-driven development. The owner-facing translation is blunt: if your builder can’t show you the acceptance criteria before they start, you’re funding a vibe.
Sub-agents protect the orchestrator’s judgment. Focused work gets delegated to sub-agents capped at roughly 150,000 tokens of context. That cap isn’t parsimony — it’s what lets the orchestrating agent keep the whole project in its head, adjudicate fairly between partial results, and stay faithful to the obligations set at the start. A general contractor who never hangs drywall keeps the blueprint in view.
Hooks are building codes, not suggestions. This is the Snowflake disagreement in practice. You can tell an agent a rule — format these queries this way, never touch those files — and the agent will mostly comply. “Mostly” is where production incidents live. Instead, hooks intercept the agent’s actions before and after tool calls and enforce the rule deterministically: formatting is normalized automatically, hard file-access boundaries simply cannot be crossed. The rule executes whether or not the model has a good day.
Memory, versioned like code. Left alone, agents relearn the same lessons expensively. My agents stage what they learn as they work; a consolidator agent then reviews the staged learnings and merges them into a distributed memory with project, global, and sensitive scopes — scoring each memory by relevance and deprecating stale ones. Before starting a task, an agent does a quick pass over that memory system and pulls the entries that semantically match the work in front of it. Institutional knowledge, but for a team of agents.
Skills are specialized tools, scoped tight. Purpose-built skills are some of the highest-leverage pieces in the workflow — but only when scoped narrowly to the task they serve. And honesty demands a caveat on rule files: configuration that loads at the outset of a project is useful, until a senior architect’s personal rules silently override the project’s and the code review turns into a negotiation. Tooling friction is real; anyone who tells you their setup has none is selling something.
Context is a budget, not a buffer. This one I relearned the expensive way this week. The same question asked against 111 million tokens of accumulated session context consumed 3.5% of my weekly usage allowance; asked against 3.2 million tokens, under 1%. I forgot to compact after a phase that ran ten hours, and I ate the cap for it. Context management is cost management. Compaction, delegation, and tight scope aren’t housekeeping — they’re the difference between an affordable workflow and an embarrassing one.
The human approves the plan. My full pipeline runs requirements-synthesizer, research agent, architecture agent, orchestrator, test-writer, implementer, verifier, consolidator — and a human approves the phases, the architecture decisions, and the plan before work proceeds. Which loops back to that first exam scenario. When a sensitive decision needs review, the reviewer is a person. Not because agents couldn’t handle it, but because some accountability can’t be delegated. Human-in-the-loop isn’t a limitation of the system. It is the system.
What this means if you’re the one paying
You don’t need to care about hooks or token budgets — that’s my job. But you should be able to ask three questions of anyone selling you AI development, and get concrete answers:
- Show me the spec before you build. What are the requirements, and what are the acceptance criteria that decide “done”? Vague answers here mean you’re paying for exploration, not delivery.
- When the agent produces something wrong, what catches it? “I’ll review the code” is a hope, not a control. Look for mechanical enforcement: tests, hooks, validation gates.
- How do you keep the meter from running away? Context and usage costs are real engineering constraints now. A builder who can’t explain their cost discipline will invoice you for their learning curve.
This is also, not coincidentally, what our audit inspects. The question an AI Automation Audit answers isn’t “can AI do this work” — it usually can. It’s whether the process, data, and discipline around the work will let it survive production.
Vibe coding produces demos. Agentic engineering produces systems. The models are the same either way — which is why the gap between the two is entirely engineering, and entirely your choice as a buyer.
This is the first in a series on how production agentic systems actually get built. Next up: the workflow, end to end — from requirements contract to verifier.