The two failure modes
Vibe coding and micromanaging are opposite errors with the same cause: no explicit decision about who is responsible for what.
Watch enough engineers work with agents and you see two distinct bad patterns. They look like opposites. They are not.
Failure mode one: vibe coding
Vibe coding is accepting agent output without reading it. The diff is treated as opaque. Tests pass, the app loads, ship it. It is genuinely fine for a throwaway prototype, a script you will run once, or a spike you intend to delete.
It stops being fine the moment the code has a second reader. The cost does not arrive as a bug on day one. It arrives three weeks later as a codebase nobody — human or agent — can navigate, because nothing was ever named consistently, the same helper exists four times, and the abstractions were invented fresh in each session.
Failure mode two: micromanaging
The opposite reflex: specify every line, correct every choice, re-prompt until the output matches what you would have typed. You spend more effort steering than you would have spent writing it, and you get a worse result, because half the context window is now full of your corrections and the agent is deep in what Module 02 calls the dumb zone.
Micromanaging usually comes from a real observation — the agent made a bad call — and the wrong response to it. The right response is almost never a longer message. It is a smaller task, a better standing instruction, or an automated check that catches the bad call without you.
The common cause
Both are what happens when nobody decided where the line is. The useful question before any session is not "how do I phrase this" but:
What is the agent deciding? (implementation, naming within conventions, mechanical edits) What am I deciding? (architecture, dependencies, public API, data model, trade-offs) What checks the result? (types, tests, lint, a second agent, my eyes on the diff)
Answer those three and the failure modes mostly stop happening on their own. Vibe coding is line three left blank. Micromanaging is line one left blank.
Watch out
The frame shifts with the code, not with your mood. Agent-decides-more is correct for a well-tested internal module with strong conventions. Agent-decides-less is correct for auth, billing, migrations, and anything with a blast radius. Deciding this per-task is judgement; deciding it per-session because you are tired is how incidents happen.
Try it
Take the task at the top of your queue. Write the three lines above for it, out loud, before you open an agent. Notice how much of the work is now already specified.
Takeaways
- Vibe coding is skipping verification; micromanaging is skipping delegation. Both come from an undefined boundary.
- The fix for a bad agent decision is rarely a longer prompt — it is a smaller task, a standing rule, or a check.
- Draw the agent-decides / you-decide / what-verifies line per task, based on blast radius.
An agent keeps choosing the wrong error-handling pattern. What are the three possible fixes, in order of preference?
First, a standing instruction in your project brief so it never has to guess (Module 05). Second, an automated check — a lint rule or test — that fails when the pattern is wrong (Module 04). Third, and last, correcting it in the session. The third fixes one diff; the first two fix every future diff.
A course by Pieter Zandbergen