There is a category error running loose in our industry right now, and it is costing teams real money.
The error is treating vibe coding and agentic engineering as the same activity performed at different levels of enthusiasm.
They are not the same activity.
They have different units of work, different failure modes, different artifacts, and, this is the part that matters, different economics when you point them at a production payment system that moves other people's money.
I build distributed systems for a living.
Lately most of that has been payment infrastructure, which is the least forgiving place I know of to be wrong.
Over the last while I have converged on a workflow that is roughly two-thirds spec-driven development and one-third loop engineering, implemented as three Claude Code skills that hand off to each other.
This post is that workflow, plus the things it broke that nobody warned me about.
The distinction, stated sharply Vibe coding Agentic engineering Optimizes for Time-to-first-output Time-to-verified-increment Unit of work A file, a function, "the thing I asked for" An independently testable vertical slice Where intent lives In a prompt that scrolls away In a durable, reviewed artifact Verification Visual, manual, by you Automated, delegated, adversarial Context Hoped for Engineered from a source of truth Characteristic failure Shipping something you can't explain Caught by the loop, not by you at 2am Vibe coding is a legitimate mode.
I use it constantly for spikes, throwaway scripts, and exploring an unfamiliar API.
It is a terrible mode for anything with an idempotency requirement.
The rest of this post is about the second column.
Spec-driven development plus loop engineering Two ideas are doing the heavy lifting here, so let me define them the way I actually use them.
Spec-driven development means intent lives in an artifact that outlives any single agent session.
Not in a prompt.
Not in your head.
Not in a Slack thread.
In a document an agent can re-read at the top of every run, that a human reviewed and approved, and that changes through a visible edit rather than a vibe shift.
Loop engineering means deliberately designing the feedback loop the agent operates inside.
What can it execute?
What tells it that it is wrong, quickly and unambiguously?
Where must it stop and escalate to a human?
A model without a tight loop is a very expensive autocomplete.
A model with a tight loop is a colleague who never gets bored of running the test suite.
Neither is a prompting trick.
Both are systems design applied one level up from the code.
The workflow: three skills, one handoff chain
- , turn a vague intent into a specification Every feature and every non-trivial bug starts here.
I give it a rough prompt.
Sometimes embarrassingly rough, a sentence and a link to a Sentry issue.
The skill then does four things: Extrapolates the prompt into candidate requirements Reads the actual codebase to ground those requirements in what exists Asks me clarifying questions Emits a full PRD, user stories, outcomes, explicit out-of-scope, and posts it to GitHub Issues Step three is the entire value proposition, and it took me a while to see that.
The clarifying questions convert ambiguity into a decision at minute three instead of a defect at week six.
When I write "add retry logic to the settlement webhook," a vibe-coded session gives me retry logic. comes back and asks: Idempotent on the provider's key, or ours?
What happens to ordering when attempt two lands before attempt one?
Does a poisoned message go to a DLQ, or block the partition?
Is partial settlement a valid terminal state?
I did not know the answer to two of those.
That is the point.
The gap between "what I asked for" and "what I meant" is where production incidents are manufactured, and a specification pass is a machine for finding that gap early.
The out-of-scope section is load-bearing I want to be emphatic about this one.
Agents are enthusiastic.
Given a settlement w