Vibe Coding Has a Planning Problem. The Fix Is What You Do Before You Type.

Handoffs got cleaner — output still drifted. The missing layer is upstream planning: lock decisions before the agent writes code. Sequel to the vibe-coding handoff article.

Deep Patel

Senior Staff Software Engineer at ServiceNow

engineering-practice

Originally published on LinkedIn under a different title. This on-site version keeps the same thesis, opens on the planning gap, and frames the portfolio run as proof.

Sequel to: Vibe Coding Has a Handoff Problem. The Fix Isn’t Better AI — It’s Better Process.

Most teams still open a chat, describe a feature, and start coding in the same breath. The agent discovers requirements mid-flight. You course-correct as it drifts. Hours later neither of you can say when “done” was agreed — because it never was.

That is not a model failure. It is a planning failure.

In my previous piece I argued vibe coding has a handoff problem, and that persistent markdown memory fixes it. That helped. Sessions became pauseable. Teammates could pick up the thread. And yet output quality stayed uneven: unauthorized assumptions, sprawling chats, the same realignment tax.

The remaining gap sits before the first line of code. When you ask an agent to invent scope and ship it in one session, you have hired a product manager, designer, engineer, and QA reviewer at once — without authorizing any of those roles. Scope gets invented because scope was never locked.

The fix is what you do before you type: separate thinking from building. Grill decisions one at a time. Write a PRD with a measurable test seam. Only then hand the agent a single implement message.

Where the last article left off

A few months back I wrote about the handoff problem in vibe coding: context windows that fill with noise, sessions that can’t be paused, codebases that teammates can’t pick up. The fix was a 3-file method — persistent markdown memory that travels with the project.

That fix worked. My handoffs got cleaner. But I was still frustrated.

Output was still inconsistent. Sessions still sprawled. The agent was still making assumptions I hadn’t authorized. And I kept asking the same question: why — even with better handoffs — was the quality of what came out still so variable? The problem wasn’t downstream. It was upstream.

The real gap: planning and building in the same session

Most AI-assisted development looks like this. You open a chat, describe what you want to build, and start coding. The AI discovers requirements as it goes. You course-correct as it drifts. The session runs long because neither of you agreed on the destination before you started driving.

That’s not an AI limitation. It’s a process gap.

When you ask an agent to plan and build in the same session, you’re not using it as an engineer executing a spec — you’re using it as a product manager, designer, engineer, and QA reviewer simultaneously. And it will make decisions in all four roles, whether you authorized it to or not.

The frustration in long vibe coding sessions — the AI assumptions, the undesirable output, the constant re-alignment — mostly comes from skipping the upstream work. The agent invents scope because scope was never locked.

Proof: the portfolio project

I stress-tested that claim on pateldeepp.dev — the portfolio project throughout this essay.

I sent one sentence into Cursor and stepped back. Nineteen minutes and forty-four seconds later: Astro site, five routes, identity, SEO, Google Analytics, structured content model, eleven built-site tests all green. The agent never paused to renegotiate product intent.

Its closing note was operational, not philosophical: set a few secrets, trigger deploy. My work outside the chat was minutes. I had no prior Astro experience (Node and frontend were familiar). Folder-to-production was about six hours — mostly planning, learning, and review, not typing code.

That outcome is the proof. The rest of this piece is the pipeline that earned it.

The pipeline that made it possible

I’ve been applying an agent-skills pipeline inspired by Matt Pocock’s work at aihero.dev. The pipeline separates thinking from building — completely.

Think of it as product engineering discipline applied to an AI-assisted codebase. Each stage has a single job. No stage bleeds into the next. For this project, I skipped /to-tickets entirely — the spec was precise enough that slicing it into individual tickets added no value. That judgment call is deliberate, not an oversight.

AI-Assisted Development Pipeline — Plan Before You Build. Upstream planning clears fog of war through research and human input before the agent executes implement and code-review.

Stage 1 — Wayfinder: fight the fog of war first

Between “we know the goal” and “we know the path” sits fog: which option wins, which trade-off we accept, which call we make first. That fog is what turns a coding chat into an unplanned product workshop.

Wayfinder clears it before anyone writes application code. One question per turn, each with a recommended answer. You accept, push back, or amend — then the next question. The rule is narrow: close one decision per session, not a design festival.

When the map hit technical unknowns, research did not serialize the human conversation. The planning skills opened background research work; recommendations were waiting when the decision turn arrived. Judgment stays human and synchronous. Investigation can run async beside it.

The output of a Wayfinder session isn’t a document. It’s a locked decision — written down, agreed upon, and closed. When you return to it in a later session, that decision doesn’t need to be revisited. It has already been made.

Architects will recognize the payoff as ubiquitous language (DDD). Shared terms stop drifting across sessions. On this project, phrases like “External post,” “Project,” and “done for SEO” meant one thing because Wayfinder tickets locked them into a domain doc every later session read first. Ten focused sessions in a day — pages, blog model, featured work, analytics placement — all decisions, zero feature code.

Stage 2 — /to-spec: a PRD written by you, not handed to you

Once the Wayfinder map is closed, /to-spec converts the shared understanding into a single implementable PRD — the kind of document a developer would normally wait weeks to receive from a product owner.

The spec captures decisions already made (not new ones), requirements explicitly out of scope, and — critically — a test seam: the exact surface where automated acceptance tests will run.

For this project, the test seam was simple and honest: assert against what a real visitor sees after a production build. Routes exist. Navigation links resolve. Content appears. GA4 injects. The agent was not asked to invent what good looked like. It was handed a measurable definition.

The spec is the bridge between human understanding and autonomous agent execution. Without it, the agent improvises. With it, the agent executes.

Stage 3 — /to-tickets (optional in this case): slice only if needed

/to-tickets breaks the spec into individual, self-contained vertical slices — one ticket per implement session. For this project, I skipped this step entirely. The spec was precise enough that slicing it into smaller tickets would have added process with no benefit.

That judgment call matters: the pipeline is a tool, not a religion. Skip what doesn’t add value.

Stage 4 — /implement: trust the upstream, build the downstream

The implement prompt is almost boring: build this issue.

By design the stage refuses to renegotiate product. Closed tickets stay closed. Clarifying questions should already be exhausted. The agent loads the PRD, finds the test seam, grows tests against that surface, typechecks, reviews, and commits.

Autonomy here is not vibes — it is permission earned upstream. Mid-flight invention stops because the contract already exists: a locked PRD plus acceptance you can observe on a built site. That is what made a ~20-minute unattended run possible on the portfolio project.

Stage 5 — /code-review: automated quality gate

After implementation commits, code review runs as a structured check — not a gut-feel pass. It examines the diff against the spec (did the agent build what was agreed?) and against standards (does the code meet project conventions?), flags material findings, and closes the loop before merging.

All gates passed. No Astro knowledge required on my end.

Key takeaways

1. The process is model-agnostic. I ran the entire project in Cursor’s “auto” mode. No model selection. No preference settings. Claude Code vs Cursor, Claude Opus vs Codex — it didn’t matter. When your upstream planning is solid, the model is largely interchangeable. The spec is the constant. The model is the execution engine. Teams spending energy on model selection debates are solving the wrong problem.

2. Planning can be parallel — research sub-agents don’t wait for you. When the wayfinder session hit technical fog — best content model for the blog, GA4 integration pattern, SEO checklist — it didn’t stall. Research agents were kicked off automatically as part of the planning process, running async in the background. By the time the decision arrived, the recommendation was already waiting. This is the pattern: the decision requires human judgment, the research runs autonomously. You never have to pause a planning session waiting for an answer.

3. Autonomy is earned, not assumed — and the engineering principles that earn it are older than AI. The nineteen-minute autonomous run didn’t happen because AI has become magical. It happened because the session followed principles that are decades old: understand requirements fully before building, lock scope before starting, measure acceptance against observable outputs, review before merging. These are not new ideas. What’s new is that AI agents will follow them — with extraordinary precision — when you give them the conditions to do so.

Strong software engineering principles are not less important in the AI era — they are the multiplier. A capable model with a weak process accelerates your chaos. A capable model with a strong process amplifies your best work.

What this means if you lead engineering teams

The nineteen-minute implementation session was not impressive because the model was smart. It was impressive because the upstream work was done correctly.

Accuracy came from process quality, not model luck. Product intent was grilled and written down. Scope was closed tickets, not improvisation. Acceptance was a built-output seam — not “looks good to me.”

If your team is getting inconsistent output from AI coding sessions, the question worth asking is not “which model should we use?” It is “how clearly have we defined what done looks like before the agent starts?”

Start here

Before your next feature, run one planning session. Do not write any code. Use /wayfinder or /grill-me-with-docs — or simply ask the agent to challenge you, one question at a time, each with a recommendation — until every ambiguity is resolved and every decision is written down. Then spec it. Then implement.

The planning session will feel slow. The implementation session will feel like magic.

Once you have separated thinking from building, you will wonder how you ever asked the AI to do both at the same time.

If you are already applying structured planning to AI-assisted development, I would love to hear how. What does your upstream process look like?

pateldeepp.dev is live. The repo is private — but the process is the real artifact.