Vibe Coding vs AI-Assisted Coding
How I separate blind prompting from a real AI workflow with agentic coding, MCP context, review, and verification.
AI has made coding faster, but it has also made it easier to confuse movement with progress. That is where I draw the line between vibe coding and AI-assisted coding.
The problem with just vibes
I get why vibe coding is tempting. You describe an idea, the model writes a large patch, and suddenly the product feels closer. The issue is that software does not only fail at the happy path. It fails at boundaries: weird data, loading states, auth rules, mobile layouts, stale assumptions, and code nobody wants to maintain later.
If I cannot explain the code, I do not really own it. That is the danger of vibe coding: the developer becomes a passenger. The app might move, but the judgment is missing.
AI can generate code quickly. It cannot decide whether the code belongs in the product, fits the architecture, or is safe to ship. That responsibility still sits with the engineer.
My actual workflow
When I use AI seriously, I do not just throw prompts at a model until the screen looks right. I treat it more like an engineering loop. The agent needs context, tools, constraints, and verification. Otherwise it is just guessing with confidence.
- 01Gather context firstBefore asking for changes, I inspect the existing files, patterns, routes, components, and tests. If the AI does not know the shape of the codebase, the output usually feels pasted on.
- 02Use MCP when the task needs live toolsMCP is useful when the assistant needs controlled access to real systems: GitHub activity, docs, issue trackers, databases, or app-specific context. It is not magic, but it gives the agent better inputs than a static prompt.
- 03Let the agent propose, then constrainI use agentic coding for exploration, scaffolding, refactors, and repeated edits. But I still define the boundaries: what files it can touch, what style to follow, and what behavior must not change.
- 04Review the diff like a normal engineerGenerated code still gets treated like code from another developer. I check naming, edge cases, UX, accessibility, security, and whether the implementation belongs in the current architecture.
- 05Verify before calling it doneThe workflow is not complete until linting, type checks, tests, smoke checks, or browser verification pass. AI speed does not matter if the result breaks the product.
My rule
I let AI help with speed, but not ownership. The agent can search, draft, edit, and suggest. MCP can give it better context. None of that removes the need to understand the code, check the behavior, run the tests, and make sure the implementation matches the product. If the model suggests a cleaner route, great. If it fights the codebase, I cut it.
The best AI workflow is not “let the model code everything.” It is “use the model to move faster while keeping your engineering taste intact.”