Vibe Coding vs What I Actually Ship in Production

Someone always shows up with a Lovable demo

Every few weeks, an agency owner or founder DMs me a link.

It is usually a Lovable project, sometimes Bolt.new, occasionally something built on Base44. The UI looks great. Auth works. There is a Stripe checkout button. The builder is excited because they went from idea to clickable product in an afternoon without hiring a developer.

Then they ask the question that pays my bills: can you make this production-ready for my clients?

I open the repo, or they export to GitHub and send access. Within twenty minutes I know which category the project falls into. Not because I am gatekeeping. Because I have rebuilt this exact shape of software enough times to recognize where the foundation ends and where the vibes begin.

That is the real split in 2026. Not "AI vs no AI." Three different ways of building, three different outcomes, and a vocabulary that is changing faster than most buyers can track.

Vibe coding was named for a reason

In February 2025, Andrej Karpathy coined "vibe coding" on X. His framing was deliberately casual: you describe what you want, the model writes the code, you accept the output, you run it, you paste errors back into the chat if something breaks. You "fully give in to the vibes" and, in the purest version, forget that the code even exists.

Merriam-Webster listed it as slang and trending by March. Collins made it Word of the Year for 2025. IBM's explainer calls it intent-driven development: less syntax, more outcome.

The tools that rode that wave are not subtle about it.

Lovable targets builders who want a full-stack React app from plain language. Describe the product, get frontend + Supabase auth + database scaffolding, sync to GitHub, deploy. Their own positioning puts them squarely in the vibe-coding category. It works. I have seen agencies use it to mock up client portals before a sales call.

Bolt.new (built on StackBlitz WebContainers) runs the whole dev environment in the browser. You chat, it edits files in real time, you iterate in conversation. More code-visible than Lovable, still optimized for speed over architecture review.

Base44 went further into fully managed territory: backend, hosting, auth, payments, analytics, all inside one environment. Maor Shlomo built it as a side project, hit profitability fast, and Wix acquired it for $80M in cash in June 2025. That deal is the market telling you vibe-coded products have real commercial value. It is also the market telling you the value was distribution and speed, not a codebase you can hand to an enterprise client and walk away.

I am not dunking on these tools. I use AI to write most of my code now. The issue is category confusion. A vibe-coded demo is not a multi-tenant SaaS. It is not a white-label product with per-client isolation. It is not an integration bridge into Dentally, Exact, or whatever PMS a UK dental agency actually runs. It is a fast answer to "does this idea feel real?" That is a legitimate job. It is just not the job my partners hire FusionSync for.

What I see when the demo hits production

The pattern repeats.

Phase one is pure vibe energy. The founder or agency owner prompts their way to a working UI. Login flows. A dashboard. Maybe webhooks stubbed out. They show it to a client. The client says yes. Everyone is happy.

Phase two is the first real constraint. Multi-tenancy. Per-client data isolation. A CRM that is not Supabase's default schema. An n8n workflow that has to survive restarts. A voice agent that needs LiveKit rooms, not a mocked button. The AI that built v1 does not know v1 anymore because the context window moved on and nobody wrote down the architecture decisions.

Phase three is the rebuild conversation. Sometimes they come to me before phase three turns into a rewrite-from-scratch. Sometimes they burn two months first.

Karpathy himself moved on by early 2026. He started calling pure vibe coding passé for professional work and replaced it with agentic engineering: humans as architects orchestrating agents like Claude Code and Cursor, with specs, diff review, evals, and security oversight baked in. The vibe era was real. The professional era needs structure around the vibes.

That matches what I see in my inbox. The tools democratized the first 20% of software. The last 80% is still engineering.

Traditional engineering is the floor, not the ceiling

Before any of this, I built the way everyone my age was taught to build.

You model the data first. You draw the boundaries between services. You write tests before you trust a deploy. You document the integration contract so the next developer (or future you) does not have to reverse-engineer a webhook payload at 11pm.

That discipline is why FusionSync can white-label fulfilment for agency partners: CRM Bridge into Exact and Dentally, GHL pipelines, n8n automation, custom Next.js product layers, per-client rollout. None of that survives on "paste the error back into chat."

Traditional software engineering is the concrete foundation in the image at the top of this post. Reliable. Maintainable. Slow when you are starting from zero.

The mistake is thinking you must choose between that foundation and AI speed. You do not. The third column in that image is what changed my daily workflow.

The space evolved in layers, and I felt each one

If you have only watched from the outside, it looks like "AI coding got better." From inside the repo, it was a stack of primitives arriving in sequence.

Layer 1: Better autocomplete (2023 to 2024)

Copilot-style tab completion. Helpful. Not transformative for architecture. You still typed every prompt. You still held the whole system in your head.

Layer 2: Agentic IDEs (2024 to 2025)

Cursor and peers turned the editor into a collaborator that could search the repo, edit multiple files, and run terminal commands. I wrote about the moment the IDE became the bottleneck, not the model and moved my agent off the laptop entirely: Telegram message in, pull request out, AGENTS.md as the contract.

That was the first time "AI-assisted" stopped meaning "faster typing" and started meaning "delegate a bounded task to something that can touch the filesystem."

Layer 3: MCP (2025)

The Model Context Protocol mattered more than another model release. MCP is a wire format for giving agents tools outside the repo: databases, APIs, workflow engines, credential stores.

I wired n8n into the writing room through n8n-mcp so the same Telegram agent that edits markdown could also create workflows, call Google Search Console, and publish posts. The agent stopped being a code generator and became an operator with a service catalog.

Before MCP, every integration was a custom script the agent might run. After MCP, integrations are discoverable tools with schemas. That is an architecture shift, not a feature bump.

Layer 4: CLI agents and headless harnesses (2025 to 2026)

Cursor shipped a CLI agent. Claude Code went mainstream. The agent no longer needs a GUI. It needs a git checkout, a rule file, and a trigger.

My harness is boring on purpose: Docker Compose, a Python Telegram bridge, pinned MCP packages, entrypoint scripts that render secrets at boot. Boring is the point. The CPU-era argument applies here too: own the orchestration layer, rent inference, keep state on hardware you control.

Layer 5: Loop engineering (2026)

This is the term catching fire right now, and it is the most honest description of what senior builders are actually doing.

Gergely Orosz traced the origin: Boris Cherny (Claude Code) and others stopped writing one-off prompts and started designing loops. Triggers. Cron jobs. /goal commands that run until a verifier says stop. Andrew Ng framed three nested loops: an inner agentic coding loop (write, test, fix), a developer feedback loop (review, steer, update spec), and an external feedback loop (users, production data, market).

Loop engineering is not "prompt better." It is design the machine that prompts for you: stopping conditions, test suites the agent must pass, budget caps, git worktrees for parallel agents, NOTES.md files that survive context compaction.

I live in this layer now. When I DM the writing-room bot "fix the partnership bridge copy on the homepage," I am not vibe coding. I am kicking off a loop with:

• A spec (AGENTS.md, branch rules, TypeScript check gate)
• Tools (shell, edit, grep, n8n MCP)
• Verification (yarn ts:check, lint)
• A stopping condition (PR opened, checks green)

The model writes the code. I designed the harness that makes the code shippable.

Layer 6: Knowledge that compounds (parallel track)

Not every loop is about shipping features. Some loops maintain context.

Karpathy's LLM Wiki pattern argues that RAG rediscovers knowledge on every query, while a compiled wiki compounds it. I run an Obsidian + Claude Code setup for competitive intel: raw sources in, interlinked markdown out, persistent graph instead of ephemeral chat context.

That is architecture evolution too. The agent is not smarter because the model got bigger. It is smarter because the memory substrate moved from chat history to files, MCP tools, and loops.

AI-assisted software engineering is the third column

Here is how I define the thing in the skyscraper image, without the marketing adjectives.

AI-assisted software engineering means:

1. You own the architecture. Multi-tenant boundaries, integration maps, data models. The AI proposes; you accept or reject against a spec.
2. You own the harness. MCP servers, CI gates, agent rules, deployment pipelines. The loop is code-adjacent infrastructure.
3. You own the verifier. Tests, type checks, linters, eval datasets. The agent does not get to declare victory without evidence.
4. You delegate execution. Implementation, boilerplate, refactors, workflow wiring. That is what the model is for.

This is what Karpathy now calls agentic engineering. It is what Boris Cherny means when he talks about designing loops instead of writing prompts. It is what I sell to agency partners who need software they can resell, not a demo they have to explain away.

Vibe coding gets you the shack in the infographic. Fast, fun, falls over when the weather changes. Traditional engineering gets you the stone building. Solid, slow to extend. AI-assisted engineering gets you the skyscraper because the foundation is engineered and the construction crew never sleeps.

What this means if you run an agency

If you are an agency owner with paying clients, the playbook I would actually recommend:

Use Lovable or Bolt for sales demos. Let a prospect see their vertical in a UI before they sign. That is a legitimate use of vibe coding.

Do not sell the demo as the product. The moment a client pays, you need tenant isolation, observability, integration bridges, and someone who can fix production at 2am without re-prompting a chatbot.

Partner for the harness, not the typing. FusionSync's model is white-label fulfilment: you keep the client, we build the stack, integrations, and per-client rollout. Phase 1 is often a free POC on GHL + n8n to prove the workflow. Phase 2 is rollout when someone pays. Phase 3 is owned software when the volume justifies it.

The agencies that win are not the ones with the prettiest Lovable screenshot. They are the ones with a repeatable path from demo to production.

The bottom line

I build with AI every day. I also rebuild vibe-coded projects every month. The difference is not the model. It is the layer around the model.

• Vibe coding (Lovable, Bolt.new, Base44) is for proving an idea feels real. Karpathy named it. The market funded it. It is not a production architecture.
• Traditional engineering is still the floor: data models, tests, integration contracts, security. Skip it and you pay twice.
• AI-assisted engineering is the current professional standard: MCP tools, CLI agents, loop design, verifiers, and harnesses that turn models into shippable systems.

The vocabulary will change again. "Loop engineering" might sound like a buzzword in six months. The underlying shift will not: builders are moving from prompting to designing systems that build.

If you run an agency and your clients are asking for software you cannot deliver in-house, message me on WhatsApp. Bring the vertical, the client count, and whether you already have a Lovable demo or a real requirements doc. I will tell you honestly which phase you are in and what a production path looks like.