Your vibe-coded app works. Now you need to be able to trust it.

Technical debt did not arrive with AI assistants. You can already inherit a poorly documented codebase, take over a contractor’s work, or discover decisions nobody fully owns any more.

What vibe coding sharpens is something more specific: you can produce far faster than you build a mental model of the system.

In more traditional development, part of that understanding is built by writing the code. When you ask an agent for authentication, a customer area and a payment system, you can get a convincing demo very quickly without having answered questions like:

• where are permissions actually checked?
• can a user reach another organisation’s data by editing a request?
• what happens if a webhook arrives twice?
• can a migration leave existing data inconsistent?
• which third-party services were added along the way?
• what happens if a model call takes thirty seconds, or costs a hundred times more than expected?

None of this means your prototype is bad. These questions were simply outside what it was built to answer.

GitHub makes the same point in its Copilot documentation: generated code can look valid while being incorrect or vulnerable, and must be reviewed and tested before it is merged (GitHub Docs).

A prototype sets out to check that a use is worth existing. In production you also have to guarantee the product keeps working as conditions get less favourable: more users, more data, a third-party service down, a mistake in an operation, a version change.

Those guarantees are not absolute. An internal tool used by five named people does not carry the risk profile of a public multi-tenant SaaS. The NIST Secure Software Development Framework works the same way: practices are meant to be adapted to context, risk tolerance, resources and cost.

When you take over an application you barely know, the first instinct is usually to open the repository and look for what seems messy. That is not the best starting point.

Start instead by understanding:

• who uses the system, and in which roles;
• where the sensitive data lives;
• which external services are involved;
• which work happens asynchronously;
• which actions are expensive, irreversible or hard to replay;
• where the level of trust changes.

That last one matters most. In threat modeling, OWASP recommends mapping data flows, external actors and trust boundaries — the points where data moves from somewhere you control what happens to somewhere you no longer do — before reasoning about threats at all.

Take a SaaS application with a frontend, an API, PostgreSQL, Stripe and an external LLM. The repository shows you modules. A risk map shows you something else: the points where data moves from the browser into the API, from a user to a tenant’s records, from your backend to Stripe, or from your database to an external model.

Those boundaries are where it becomes worth asking which checks actually run and which assumptions are implicit. An 80-line function is rarely a risk in itself. An implicit authorization rule can be.

Once you understand the system, reading the whole codebase at the same intensity is rarely the best use of the time available.

It is more useful to start from the invariants: the properties that must stay true.

In a B2B SaaS:

In a payment system:

For an external integration:

From there you can build the controls that genuinely buy confidence. For tenant isolation, an explicit test matrix is usually more useful than an abstract coverage target:

Broken access control is still the first category in the OWASP Top 10 2025, and OWASP publishes a dedicated guide to authorization regression testing.

The same logic applies to idempotence: Stripe documents explicitly that the same webhook event can be delivered more than once, and recommends recording the events you have already processed (Stripe Docs).

So the question is not "do we have enough tests?" but which important properties are we able to defend?

A codebase can be imperfect without being dangerous. Conversely, a very tidy application can hide a critical business assumption that has never been tested.

For each sensitive area, look at least at five things:

Likelihood counts, but it does not decide on its own: on a security invariant, reach usually wins, because a small but non-zero likelihood applied to every one of your customers is still unacceptable.

Before production we almost always look at authorization, tenant isolation, secrets, migrations, data integrity, idempotence, external dependencies, backups, variable costs and observability.

Non-critical duplication, inconsistent conventions, mediocre naming or purely cosmetic refactors can usually wait.

The OWASP Top 10 2025 also puts Software Supply Chain Failures in third place, which is reason enough to take dependencies and the build chain seriously on a quickly assembled prototype.

Once the priority risks are identified, choosing guardrails becomes much simpler.

The rewrite question comes up almost every time you take over a prototype. Our position is not "never rewrite".

Two Vezero engagements show the two possible answers.

Moving to production does not mean dropping Cursor, Claude Code or other agents. What changes is the nature of the instructions you give them.

While prototyping:

Once the system is critical:

In the first case you are asking the tool for a feature. In the second you are asking it for a change under constraints.

GitHub recommends a similar approach: use tests and automated analysis, check that the change respects the project’s architecture, and give the AI sources of truth such as documentation or the repository’s conventions (GitHub Docs).

There is no universal production readiness score. But for a given scope, you should be able to answer three questions:

They map exactly onto the three guardrails above: prevent, see, recover.

If you can answer them for your critical areas, and those answers are tested rather than assumed, your product can be ready even if the code still has rough edges. Conversely, a spotless repository is not enough if nobody can answer them.