Vibe Coding Makes You the Agent’s Assistant. Three Habits to Take Back Control.
Most people building with Claude Code don't realize who's actually in charge.
Daniel Williams has 33,000+ subscribers on his newsletter Claude Code for Non-Coders — one of the sharpest reads on how AI coding agents actually work in production. His post below tackles something most vibe coders don’t realize until it’s too late: the moment you stopped driving.
At a Glance
In this piece, you will learn:
Why vibe coding quietly turns you into the agent’s assistant — not the other way around
The “discernment cut”: how to decide what stays yours and what goes to the agent
Three concrete habits that keep your judgment inside every decision the agent makes
This post is prepared with Guest Author — Daniel Williams. Writer of Claude Code for Non-Coders. If you also want to write for Creators AI — send us email here
Vibe coding promises that anyone can build anything. Hand the agent your idea, get a working product. That is the pitch.
What actually happens when you do it long enough is that the polarity reverses. The agent writes the function. You test it. The agent proposes the schema. You approve it. The agent picks the library, and you install it without realizing you have just inherited three indirect dependencies you did not choose. Mid-build, you stopped being the builder. You became the reviewer of the agent’s decisions. Vibe coding made you the agent’s assistant.
Three habits take that back. Each is a different decision about what gets handed to the agent and what stays yours to make.
The reverse-centaur trap
Cory Doctorow has a term for this pattern. The reverse-centaur. The original centaur came from the chess world: a human plus an AI playing together, with the human driving strategy and the AI handling tactical depth. Each piece did what it was best at. The human led.
The reverse-centaur flips it. The AI does the work. The human polishes, sanity-checks, and clicks “approve.” The strategic decisions, the architectural decisions, and the “is this even what we want to build” decisions all flow upstream from the AI’s defaults. Human labor is for the downstream cleanup.
Vibe coding, when it works smoothly, makes you a reverse-centaur. You feel more productive because output is happening faster. You are more productive in the short-term sense. But your role in the process has been reduced to reviewing and signing off on choices you did not make. The schema your data model is built around. The function signature that is going to leak through the rest of the codebase for the next year and force fifteen downstream changes the first time you finally have to revise it.
Top consulting firms are selling reverse-centaurs to clients right now, marketing the result as productivity. The vibe-coding version is the same shape, just smaller. You are the principal who cannot explain a decision your contractor made because you were not in the room when i t was made. Except that the contractor is the agent, and the room is the prompt context window.
The discernment cut
The way out is not less AI. It is a clearer cut about which work to give the agent and which work to keep.
The principle I operate from, on every build I ship:
We automate tasks that enhance human flourishing. We resist automation that encroaches on human judgment.
The first sentence says yes to automation. The second says no to a specific kind: the kind that replaces your judgment instead of supporting it. Together, they are a discernment cut.
A concrete version. Writing boilerplate is friction. Deciding the architecture the boilerplate lives inside is a judgment. Running database migrations is friction. Deciding what data model fits the business is a judgment. Repeatable, structurally bounded work with a single right answer most of the time goes to the agent. Contextual, irreversible work with multiple defensible answers stays with you.
If you cannot articulate, in one sentence, why the agent is the right one to do a particular task, you have not made the cut yet. Vibe coding defers the cut and accepts whatever defaults the agent surfaces. Operating discipline makes the cut before any prompt gets typed.
The three habits below assume you have already made the cut. The habits without the cut just make you better at building the thing that is eroding you.
If you’re new to Claude Code and want the practical foundation first: Claude Code Tips: for Dev and Non-Dev Tasks
This and many other practical posts on building with AI are available exclusively to our subscribers.
Habit 1: Write a contract before you task the agent to build.
Vibe coders prompt the agent. Operators write a contract first, then task.
Here is the actual sequence I use. I sit down and write what I want in my own words. The problem the change is solving. The outcome I am aiming for. What “done” looks like, with measurable thresholds I can describe. What is explicitly out of scope? I start in my own words because I have a particular outcome in mind, and I want it to be the foundation on which everything else builds. The customer, the project history, the mistakes, and the fixes, what is load-bearing two repos away: those live in the agent’s project context if I have done the configuration work Habit 3 covers. The contract adds my outcome on top of that.
Then I bring the agent in. I hand my draft and ask it to stress-test the spec. What is underspecified? What edge cases will break this? What assumptions do I have hidden inside the goals? The agent catches things I missed. I revise. The contract is the artifact of that thinking. My judgment leads at every step; the agent helps refine.
When the contract is locked, I use Claude Code’s /goal command to drive the build. The contract becomes the agent’s brief, success criteria, and boundary all at once. Every “what about X?” the agent might raise mid-build has already been answered or is explicitly out of scope.
A real example. Local Memory, the MCP server I ship for persistent agent memory across sessions, has 21 of these contracts in docs/feature-contracts/. LMG-020 names a destructive write operation, the existing safety gate at the REST layer, the gap at the MCP layer, and the breaking change, all before any code was written. A trimmed view of the contract itself:
# Feature Contract: Validate Auto-Fix Confirmation Gate
**Contract ID:** LMG-020
**Priority:** P1 — MCP `validate(auto_fix=true)` runs destructive fixes with
no confirmation gate. The REST layer gates this path correctly; the MCP
layer does not.
**Source:** Manual testing, 2026-04-26
## Strategic Context
`validate(auto_fix=true)` is a destructive write operation. The REST layer
correctly requires `X-Confirm-Auto-Fix: true` before applying fixes. The
MCP layer has no such gate.
Three problems compound each other:
**Problem 1** — MCP has no confirmation gate for the destructive path.
**Problem 2** — `suggested_actions` in both layers omit `dry_run=false`.
**Problem 3** — MCP tool description teaches an incomplete invocation.
## Breaking Changes
MCP `validate(auto_fix=true, dry_run=false)` without `confirm_auto_fix=true`
will now return an error.
The agent had nowhere to drift to. Every “what about X?” question that might arise mid-build was already answered in the contract or named as out of scope.
The vibe-coding version is “make validate safer.” The agent picks something. You hope it is the right thing.
Before your next session, write the contract. Use the agent to refine it. Lock it. Then run /goal to task the build.
Share this with a builder who’s been vibe coding a little too comfortably.
 | A guest post by
|