Agentic Engineering Is Not Vibe Coding: The Three-Skill Loop I Use to Ship Distributed Systems Samuel Mutemi Samuel Mutemi Samuel Mutemi Follow Aug 2 Agentic Engineering Is Not Vibe Coding: The Three-Skill Loop I Use to Ship Distributed Systems #webdev #ai #programming #automation 2 reactions 1 comment 11 min read Where Does Truth Live?
A Field Guide to Agentic Engineering Methodologies Samuel Mutemi Samuel Mutemi Samuel Mutemi Follow Aug 4 Where Does Truth Live?
Verification — tests check whether you got it.
Correction — a loop closes the gap.
This post is what happened when I stopped running those as three separate practices and wired them into one system.
The layers were the easy part.
The hard part is where they join, and there are exactly two joints.
The Real Problem: I Was the Wiring Running three methodologies "concurrently" looked like this: The spec lived in GitHub Issues.
The tests lived in the repo.
The loop lived in a skill that re-ran an agent until a task list emptied.
All three were real.
The connection between them was me, noticing things.
I noticed that a failing test meant a PRD assumption was wrong.
I noticed that slices five through nine came from a version of the spec that no longer existed.
I noticed that an agent had "fixed" a failing test by making the test weaker.
That's not a system.
That's three components and an operator, and the operator is the part that doesn't scale.
Each layer had a trigger, an input and an output.
None of them had a defined interface to the layer next door, so the interface defaulted to my attention.
So the goal isn't: "Adopt all three." It's: Give the handoffs between layers a name, a trigger and an artifact, so they happen without me.
The Flow The system looks like this: Two loops.
The difference between them is the whole design: The inner loop fixes the code.
Runs unsupervised, on a retry budget, allowed to act.
The outer loop fixes the spec.
Runs on escalation, no retry budget, allowed only to propose.
Changing the spec means changing intent, and intent isn't something an agent gets to change by itself.
A loop that can edit its own target will move the target instead of solving the problem.
Every time.
The rest of this post is those two joints.
Joint One: Your Tests Can't Just Be a Copy of Your Spec Part two ended on this claim, and it's harder than it sounds: A feedback loop with a bad sensor is worse than no loop, because it converges, confidently, at machine speed, on the wrong thing.
The obvious move is to generate your tests from your spec.
That's the spec-driven pitch, and it works.
But it buys you exactly one thing: It catches the code disagreeing with the spec.
Now notice what it can't catch.
If the spec is wrong about the real world, a test generated from that spec is wrong in the same direction.
It passes.
Green checkmark.
Everyone goes home.
Safety engineering has a name for this: common-cause failure.
Two backups don't help if they share a design flaw, which is why aircraft use sensors built on different physical principles instead of just duplicating one.
Your spec-generated test suite is one channel, and its design is the spec.
What Can the Test Actually Catch?
What went wrong Example Can a spec-generated test catch it?
Code doesn't match the spec PRD says retry 3 times, code retries once Yes.
This is its job Spec contradicts itself Requires strict ordering on a queue that doesn't guarantee it Yes, cheaply Spec is silent Says nothing about ordering, so the agent picks one No.
No test exists for an unstated rule Spec is wrong about the world "The provider's charge endpoint is idempotent." It isn't No.
The test asserts the same falsehood Spec is right, the requirement was bad Flawless build of the wrong feature No, and no test ever will Rows three and four are where money gets lost.
The fix isn't