Gerardo B. Galvez IIStill Prompting Your Coding Agent Directly? Here's a Better Vibe Coding Workflow
"Vibe coding isn't the problem. Vibe coding without project control is."
"We're not removing the vibe. We're adding the engineering required to take AI-assisted software projects from idea to controlled release."
A better Coding Agent prompt is not always the solution. Sometimes what the project needs is a better software-development process around the AI.
Vibe Coding Reality
Vibe Coder
Coding AgentOpen Act I source record and interaction archive
1. Direct Prompting & Scope Explosion
It always starts with enthusiasm: "Build me a simple app." But without project boundaries, direct prompting turns a 2-hour prototype into a runaway engineering nightmare.
The Unprompted Architecture Creep
You asked for a plain contact form. The AI Coding Agent enthusiastically installed 14 new npm packages, refactored your database schema, added 3 microservices, and wrote a Redis caching layer you never asked for.
The Casual "Done!" Fallacy
The Coding Agent outputs "All features completed successfully!" — but opening the browser reveals broken layouts, missing API endpoints, and raw 500 errors in the console.
The Forgotten Context Wipe
Your chat context window fills up. You open a fresh chat session or switch language models, only to realize all project rules lived inside the old chat thread. The new agent overwrites working code.
The Endless Retry Loop
A bug appears. You prompt "fix this error" 15 times in a row. The agent makes random guesses, masking symptoms and deleting failing unit tests to make the build pass.
"Hey! Build me a simple contact form. Should take 10 minutes, right?"
"Done! I installed 14 npm packages, refactored your database schema, added 3 microservices, and built a Redis caching layer!"
"Wait... why are there 42 files, 3 broken endpoints, and raw 500 errors in console?!"
Select the vibe coding habits that reflect your current workflow. Be honest — this tool helps identify hidden engineering risks without shaming.
Low Risk — Strong engineering boundaries & durable state.
Moderate Risk — Context leaks & scope creep slowing delivery.
High Risk — High vulnerability to scope explosion & broken builds.
Vibe coding is fast, exciting, and empowering. But without project boundaries, it produces software that works on attempt 1, breaks on attempt 2, and becomes unmaintainable by attempt 3.
2. Direct Prompting vs. Engineered Workflow
The AI Coding Agent is not the primary problem — it operates directly from the available instructions, context, tools, and project state. When scope, durable requirements, project state, acceptance criteria, and independent review are absent, immediate implementation can occur without sufficient project control.
- •Scope Lives in Chat: Opening a new thread wipes memory.
- •Self-Approval: The agent decides when work is done.
- •Unbounded Refactoring: Edits spread across unrelated files.
- •Trial-and-Error Debugging: Blind retries mask underlying bugs.
- •Repository-Native State: Memory lives in durable Markdown files.
- •Independent Review Gate: Reviewer evaluates evidence before gate closes.
- •Bounded Milestones: Changes locked to authorized scope.
- •Evidence-Driven Verification: Tests and builds prove correctness.
Are You Direct Prompting or Engineering?
[Interactive self-assessment diagnostic reserved for Milestone I4. Content remains 100% complete and understandable statically without JavaScript.]
3. The 9-Step Planning Progression
Before writing code or prompting an AI agent, establish a clear engineering roadmap. Planning determines WHAT should be built.
Idea
Raw vision or feature concept.
Engineering Discovery
Inspect repository context & dependencies.
Problem Definition
Identify target user & exact pain point.
Scope Boundaries
Define IN SCOPE vs. OUT OF SCOPE.
Requirements
Specify testable acceptance criteria.
MVP Definition
Select smallest sufficient deliverable.
Architecture
Establish data flow & technical boundaries.
Risks & Security
Identify data safety, privacy & auth gates.
Milestone Roadmap
Break work into continuous phases (I0–I7).
PLANNING determines WHAT gets built (product discovery, requirements, MVP definition). GOVERNANCE controls HOW the project is built (roles, evidence, review gates, change queues). Neither replaces the other.
4. Three Roles & Independent Review Gates
Governance enforces project control during execution. It separates creative vision, technical implementation, and quality verification into three distinct roles.
Owns product direction, business rules, approved scope, protected decisions, subjective visual approval, and release authorization. Overrides agents when necessary.
Owns technical investigation, implementation, debugging, tests, documentation, and returning copy-ready IMPLEMENTATION_REVIEW_PACKETs with status READY_FOR_REVIEW.
Owns independent verification, defect detection, evidence evaluation, milestone acceptance (DONE), and generating exactly ONE next prompt. Never writes code directly.
An agent reporting success is an unproven claim. Independent verification from code diffs, tests, or builds is required before closing gates.
The Coding Agent may transition ACTIVE → READY_FOR_REVIEW, but ONLY the independent Reviewer can close the gate to move READY_FOR_REVIEW → DONE.
Mid-Implementation Change Policy
Got a new idea while the Coding Agent is working? Good idea ≠ implement immediately. Discuss it with the Reviewer, who stages it into one of four revision classes until active work completes:
Routine Change Queue waiting may be bypassed ONLY when evidence indicates material danger such as credential exposure, active security vulnerability, destructive behavior, persistent-data risk, production danger, privacy/compliance danger, a fundamentally invalid requirement, or continuation likely to cause material damage.
"Wait! While the agent is working on Milestone 3, I just had another genius feature idea! Let me prompt it right now!"
"Discuss now. Prompt later. Reconcile against the actual implementation report first."
Staged in Reviewer Change Queue
Executing active authorized scope (Milestone 3) without mid-session interruption or prompt churn.
The Coding Agent is currently deep in active code execution. Suddenly, the Vibe Coder gets a "genius" new feature idea that wasn't in the original scope. What is the correct decision?
"I just had another idea! Let's add this right now while the session is open!"
"Discuss now. Prompt later. Reconcile against the actual report first."
Select any of the 6 failure scenarios below to explore why specific engineering controls exist and their practical effect on AI development.
AI Says It Is Done
Believing an agent claim that work is finished without independent proof.
CODING_AGENT_REPORTED ≠ REVIEWER_VERIFIED & READY_FOR_REVIEW ≠ DONE
An agent reporting completion is an unproven claim; only independent review closes a gate.
Helps catch broken builds and silent defects before a milestone is accepted or released.
6 Core Failure-to-Control Mappings
Learn how governed engineering controls transform common vibe coding failure modes into predictable release outcomes:
Failure: Believing an agent claim that work is finished without independent proof.
Control: CODING_AGENT_REPORTED ≠ REVIEWER_VERIFIED & READY_FOR_REVIEW ≠ DONE
Why: An agent reporting completion is an unproven claim; only independent review closes a gate.
Practical Effect: Helps catch broken builds and silent defects before a milestone is accepted or released.
Failure: Repeatedly prompting "fix this error" causing trial-and-error guessing and test deletion.
Control: inspect → understand → implement → targeted verify
Why: Inspect the actual failure and relevant evidence before changing code, then verify the targeted correction.
Practical Effect: Reduces blind retry loops and makes debugging more deliberate and evidence-driven.
Failure: Re-litigating accepted milestone requirements mid-implementation.
Control: closed means closed
Why: Accepted work remains closed unless a defined reopening condition exists.
Practical Effect: Reduces unnecessary scope churn and repeated re-engineering.
Failure: Reviewer dropping incremental objections one-by-one in an endless feedback loop.
Control: one-pass material finding collection
Why: The Reviewer inspects the current authorized delta and consolidates all reasonably discoverable material blockers in one review.
Practical Effect: Helps reduce avoidable review ping-pong and gives the Coding Agent a consolidated correction target.
Failure: Rejecting working code as broken when only documentation or test evidence was omitted.
Control: implementation defect vs evidence gap
Why: Distinguishes real code bugs from missing verification logs or documentation artifacts.
Practical Effect: Allows rapid targeted evidence conversion without ordering unnecessary reimplementation.
Failure: Losing project memory when chat context clears or language models switch.
Control: repository-native Markdown state
Why: Durable project state lives in version-controlled files (PROJECT_STATE.md), not chat history.
Practical Effect: Helps replacement agents resume from durable project state with less dependence on prior chat history.
5. Gate Execution & Practical Handoff Workflow
The governance gate is complete when evidence matches requirements, independent review accepts the milestone, and continuous roadmap execution advances to the next authorized phase.
CODING_AGENT_REPORTED ≠ REVIEWER_VERIFIED and READY_FOR_REVIEW ≠ DONE. An agent self-reporting success is an unproven assertion. Only independent review of code diffs, builds, and test evidence closes the gate.'I finished the entire feature! 100% complete!' (READY_FOR_REVIEW)
Evidence: No build logs, no test output, and zero visual screenshots attached.
Scenario 1: Agent Claims Success, But Evidence Is Omitted
The Post-Governance Operating Loop
Once your project-specific Reviewer Governance Lock is generated, your ongoing development loop is simple, structured, and repeatable:
"Your Coding Agent is a role, not a model subscription. Your project's continuity should live in the project, not in one AI conversation or one AI model."
When usage limits occur or you switch language models (e.g., from Claude Opus 4.6 to Gemini 3.6 Flash), your project doesn't reset. The replacement Coding Agent reads repository-native Markdown state (PROJECT_STATE.md, requirements, decisions) and resumes implementation from the exact active milestone.
Lightweight, direct prompting can be reasonable for tiny or disposable work. Stronger project governance becomes increasingly valuable as technical and business consequences increase:
Direct Prompting Can Be Reasonable For:
- Tiny standalone scripts & utility functions
- Disposable proof-of-concept spikes
- Quick one-off formatting tweaks
Stronger Control Matters More For:
- Persistent database schemas & user data
- Authentication & row-level security policies
- Multi-milestone client projects & payment integrations
- Production security & infrastructure boundaries
Case Study: Catching Missing Authorization Boundaries Before Release
The Milestone: Implement user authentication and profile updates.
The Coding Agent Claim: "READY_FOR_REVIEW — All auth unit tests pass!"
The Reviewer Finding: In this illustrative scenario, independent inspection reveals that while unit tests pass, the update endpoint omits Row-Level Security checks, allowing user records to be modified across authorization boundaries.
The Outcome: Independent review returns CHANGES_REQUIRED before release. The agent adds database RLS policies. The example demonstrates how an independent gate can prevent a serious authorization defect from reaching production.
Zev Governance Bootstrap v5 Resource
Use the resource below to bootstrap a project-specific Reviewer Governance Lock for your software project.
Zev Governance Bootstrap
Universal Independent Reviewer Governance for Software Projects. Learn the loop visually, then open the exact canonical v5 reference when you are ready.
Goes to the Independent Reviewer.
Holds project-specific review state.
Goes to the Coding Agent for implementation.
VIEW = COPY = MARKDOWN = TXT · v1, v2, and v3 remain available as archives.