Vibe Coding vs AI-Assisted Coding
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.
Vibe coding
Prompting until something appears to work, then moving on without fully understanding the tradeoffs, edge cases, or architecture.
AI-assisted coding
Using agents, MCP, and structured context to speed up the work while still owning design, review, tests, and final judgment.
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.
1. Gather context first
Before 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.
2. Use MCP when the task needs live tools
MCP 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.
3. Let the agent propose, then constrain
I 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.
4. Review the diff like a normal engineer
Generated 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.
5. Verify before calling it done
The 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.
Agentic coding
Good for multi-step edits, refactors, UI iteration, and reading through a codebase.
MCP
Good for giving the assistant live, scoped access to external tools and project context.
Human review
Still the final gate for product fit, maintainability, and whether the change should exist.
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."