Vibe coding is not a production strategy

The current discussion around vibe coding has moved into a more interesting phase.

It is no longer just about whether a founder can build a demo with Cursor, Lovable, Replit or another AI coding tool. That question has mostly been answered. Yes, the tools can create impressive first versions. Yes, non-traditional builders can ship more than they could before. Yes, teams can move faster when a good developer uses AI well.

The sharper question is what happens after the first version works.

Over the last day, X has been full of posts about AI-built apps, Replit’s promise to take vibe coding all the way to production, Cursor and Lovable workflows, production-safe prompts, fast deployment and the technical debt that can appear when generated systems grow faster than their design.

That is a useful signal for founders, CTOs and product owners.

The business problem is not “vibe coding is bad”. That is too simple. The problem is that a prototype and a production system are different things, even when they look the same in a browser.

AI can help with both. But it cannot remove the difference.

A working demo is not the same as a dependable product

A prototype has one main job: prove that something might work.

It can cut corners. It can use a simple data model. It can ignore edge cases. It can have manual deployment steps. It can keep observability light. It can live without a clean permission model if only two people are testing it.

That is often the right tradeoff. Early software should answer product questions quickly:

• Does the workflow make sense?
• Do users understand the value?
• Is the data useful enough?
• Is this worth building properly?
• What should be removed before more is added?

AI coding tools are excellent for this phase. They make it cheaper to explore. They reduce the cost of trying an interface, an internal tool, a landing-page workflow, a data import, a dashboard or a small SaaS idea.

But the moment customers, employees or operations start depending on the system, the job changes.

Production software needs to keep working after the demo. It needs to survive new features, bug fixes, changing requirements, onboarding, incidents, data growth, security reviews and the simple fact that someone will have to maintain it six months from now.

That is where many AI-built systems become uncomfortable. They were created at prototype speed, but they are suddenly carrying production expectations.

The hidden debt is usually structural

When people talk about vibe-coded technical debt, they often imagine messy files or ugly code.

That happens, but it is not the deepest issue.

The more expensive debt is structural:

• unclear data ownership;
• duplicated business rules;
• authentication added after the fact;
• authorization logic scattered across screens;
• database tables that match the first UI instead of the real domain;
• no migration strategy;
• no clear module boundaries;
• tests that cover happy paths but not business risk;
• error handling that only works when everything is calm;
• deployments nobody can confidently roll back.

These problems are not unique to AI. Human teams create them too. AI just makes it easier to create a lot of software before anyone has had to slow down and decide what the system really is.

That is the key point: speed exposes missing architecture earlier.

If an app is only a throwaway prototype, that may be fine. If it is becoming the foundation of a product, an internal workflow or a customer-facing process, the team needs a hardening step before the codebase becomes expensive to change.

Production readiness is not a feature in a tool

It is tempting to look for one platform that can promise “from prompt to production”.

The better platforms will certainly help. Good hosting defaults, secret management, rollbacks, database integrations, observability, permissions and deployment workflows all matter. A tool that makes safe defaults easier is valuable.

But production readiness is not a button.

It is a set of decisions:

• What are the critical user journeys?
• Which data must be protected?
• Who is allowed to do what?
• What happens when a payment, import, sync or background job fails?
• Which parts of the system can be changed quickly?
• Which parts need review?
• How will the team know something is broken?
• How does the system recover?
• Who owns the code after it ships?

A tool can support those decisions. It cannot make all of them correctly in isolation, because many of them depend on the business.

For a founder building a private prototype, a rough permission model may be acceptable. For a B2B SaaS product holding customer data, it is not. For an internal Mittelstand operations tool, the highest risk might not be scale; it might be incorrect data, unclear responsibility or a process nobody can audit later.

The right engineering answer depends on the product context.

That is why McDougall Digital tends to start AI-supported development work with architecture and product judgement, not just implementation speed. The goal is not to make AI look impressive. The goal is to produce software that is useful, maintainable and safe enough for the business it serves.

The prototype-to-product checkpoint

Before an AI-built app becomes production software, it deserves a checkpoint.

This does not need to become a slow enterprise process. It can be a focused review, but it should be explicit. The team should look at the system as if it now matters, because it probably does.

Start with the product surface.

Which workflows are essential? Which ones are experimental? Which users exist today, and which users will exist later? Are there admin roles, customer roles, partner roles or internal roles? Are any actions financially, legally or operationally sensitive?

Then look at the data model.

Does it reflect the actual business domain, or only the first screen that was generated? Are relationships clear? Are there audit needs? Can records be migrated? Is customer data separated properly? Are retention and deletion expectations understood?

Then inspect the application boundaries.

Can a developer explain where the business logic lives? Are frontend components making decisions the backend should enforce? Are third-party integrations wrapped cleanly, or are they scattered through the product? Can risky areas be tested without clicking through the whole app?

Then check operations.

How is the app deployed? Where are secrets stored? What logs exist? What alerts exist? Can the team reproduce a production bug? Can it roll back? Is there a staging environment that is close enough to be useful without exposing real customer data?

Finally, check the delivery process.

Can AI still help safely? Which tasks are good candidates: tests, refactoring, documentation, small feature slices, migration planning, internal tools? Which tasks need tighter human review: auth, billing, data deletion, permissions, production infrastructure?

This checkpoint is often where the biggest gains are found. Not because everything needs to be rewritten, but because the team can separate useful prototype code from fragile assumptions.

What to refactor first

The worst response to a successful AI prototype is usually a vague rewrite.

Rewrites feel clean, but they often destroy learning. The prototype contains product knowledge: which workflow mattered, which screens were confusing, which data users cared about, which shortcuts were acceptable and which ones were not.

A better approach is selective hardening.

Refactor the parts that will carry future change:

• the data model;
• authentication and authorization;
• API boundaries;
• business rules;
• background jobs;
• payment, billing or invoicing logic;
• customer data flows;
• deployment and configuration;
• observability around critical paths.

Leave disposable parts disposable. A rough admin screen can often wait. A temporary import script might be fine if it is clearly marked and not part of the core product. The goal is not aesthetic purity. The goal is to reduce the risk of expensive change.

AI can help here too, especially when it is given clear constraints. It can summarize the existing architecture, identify duplicate logic, write characterization tests, propose smaller module boundaries, generate migration notes and prepare focused pull requests.

But the direction should come from engineering judgement. Otherwise the same tool that created the sprawl may simply rearrange it.

The German-market version of this problem

For many German businesses, the challenge is not chasing the loudest AI trend. It is using modern tools without creating operational or compliance debt.

That applies to founder-led SaaS companies, internal Mittelstand tools, product teams modernizing old workflows and CTOs trying to increase delivery capacity without losing control.

An AI-built prototype can be a very good starting point. It can make an idea tangible. It can help stakeholders react to something concrete. It can reduce the cost of discovering that a feature is not worth building.

But when that prototype starts handling customer data, employee workflows, reporting, scheduling, billing, inventory, support or compliance-relevant processes, the standard changes.

Clients will not care that the first version was generated quickly if the system loses data, exposes permissions incorrectly, cannot be changed, or fails silently during a business-critical process.

They will care that the software behaves reliably.

That is the useful middle ground: use AI to move faster, then apply enough architecture, testing and operational discipline to make the speed durable.

A practical readiness checklist

If your team has an AI-built prototype that might become real software, ask these questions before calling it production-ready:

1. Can we explain the architecture in plain language?
2. Do we know which workflows are business-critical?
3. Is the data model aligned with the real domain?
4. Are authentication and authorization enforced in the right place?
5. Are customer data, secrets and environment variables handled deliberately?
6. Do tests cover the paths where failure would hurt the business?
7. Can we deploy, monitor and roll back with confidence?
8. Are third-party integrations isolated enough to change later?
9. Is there a clear owner for future maintenance?
10. Do AI-generated changes go through reviewable pull requests?

If several answers are unclear, the next step is not necessarily to stop. It is to harden the foundation before adding more surface area.

That is usually a much smaller job than waiting until the codebase is tangled around real customers.

Where McDougall Digital helps

McDougall Digital works in exactly this space: AI-supported software development for serious products.

That can mean reviewing an AI-built prototype before it becomes a customer-facing product. It can mean restructuring the architecture so the next six months of features do not make the codebase harder to operate. It can mean adding the right tests, deployment process, observability and security boundaries. It can also mean setting up an AI-assisted delivery workflow where agents help with implementation while humans keep ownership of product and architecture decisions.

The point is not to slow the team down. The point is to keep speed from turning into invisible debt.

Vibe coding is a useful way to start. It is not, by itself, a production strategy.

The teams that get the most from AI will not be the ones that generate the most code. They will be the ones that turn fast learning into dependable systems.