How to survive taking over a project built with "vibe coding"

We have just inherited a project presented as a revolution because it was developed at an impressive speed thanks to AI? And it is true, it can be impressive. I have seen a sales colleague create a really decent UI in just a few days. But we may then discover a real house of cards. The application works most of the time, but every change seems to break something in a completely different part of the system.

This can obviously also happen with projects developed without AI. Technical debt, poor architectural decisions, and a lack of tests have always existed. But the problem with vibe coding is that it makes it possible to produce huge amounts of code very quickly, sometimes without taking the time to think about the design.

AI can generate large amounts of code, but a production application still requires a consistent architecture, tests, debugging, and a long-term vision.

Let's see how to regain control before the project becomes impossible to maintain.

Diagnosis: signs of a struggling project

We often find the same symptoms in projects that have been developed too quickly, especially when no developer is really in charge.

There are no real automated tests. Or the existing tests verify very little business logic and do not allow the code to be modified with confidence. The smallest change then becomes a risk.

While exploring the project, we sometimes discover several different libraries that perform exactly the same role. Over time, multiple solutions have been added without any real consistency.

Business logic is scattered everywhere: in controllers, UI components, utility functions, or unexpected places. It becomes difficult to know where a modification should actually be made.

Security has sometimes been treated as a secondary concern. We find exposed API keys, insufficient validation, or poorly protected sensitive data. This is a critical issue.

Taken separately, none of these problems is necessarily catastrophic (except security issues). But together, they make the project increasingly difficult to maintain and evolve.

Stabilize before improving

A complete rewrite often seems like the ideal solution, but it is risky and expensive, and impossible to do in many small companies. It is easy to recreate the same problems with a new architecture.

Before anything else, the goal is to make the application predictable: understand how it works, reduce risks, and stop introducing new instability.

Stop the bleeding

The first rule is simple: stop making the situation worse. We temporarily limit new features and focus on what allows the application to keep running.

We identify the critical features: authentication, payments, orders... Their unavailability can have an immediate impact.

We also add a minimum level of observability with logs, then check the main security risks: exposed keys, incorrect token storage, missing validations.

Make the system understandable

It is impossible to fix an application that we do not understand. We start by checking that a new developer can run the project without assistance. If starting the application depends on undocumented knowledge, we document every necessary step.

Then, we analyze the path taken by a request. A simple architecture diagram often reveals unnecessary complexity that had gone unnoticed.

We also take the opportunity to review critical dependencies, especially those related to authentication, payments, or external services.

Build safety nets

The goal is not to immediately achieve perfect test coverage. That would probably take too long and delay getting the project back into a stable state.

We start by writing targeted tests for the most important features. These tests will provide a safety net for future changes. We will not protect against every regression, but at least against the most serious ones.

We also validate incoming data with schemas whenever possible to avoid inconsistent data. We should not continue accepting incorrect data and allow problems to spread.

If business logic is scattered throughout the interface or different parts of the code, we gradually try to move it into dedicated services. The goal is to have a clearly identified place where important logic lives.

Validate data

Many bugs simply come from a missing field, an incorrect type (`"123"` instead of `123`), or an unexpected format. It is important to quickly validate incoming data and only store consistent information to prevent problems from spreading.

Use logs effectively

Logs are often the first source of information when a problem appears in production. However, they are sometimes incomplete, too verbose, or difficult to use.

It is important to have clear logs with enough context to understand the origin of an error: the affected request, impacted user, external call involved, or system state at the time of the problem.

A good logging strategy can significantly reduce the time required to diagnose a bug.

Analyze SQL queries

A properly formatted SQL query can often reveal unnecessary joins, missing indexes, or performance issues.

With quickly generated code, it is easy to introduce queries that work correctly but become catastrophic when the amount of data increases.

Conclusion

Taking over a project created with vibe coding is not necessarily an impossible task. It obviously depends on its scope and usage. The problem is not the use of AI itself. I use it every day, like a large number of developers and non-developers, but rather the lack of safeguards around code generation.

AI is a tremendous accelerator, but it does not replace the experience of a developer capable of thinking about architecture, technical trade-offs, and the consequences of decisions.

The goal is not to throw away the project and start over. Most of the time, we need to gradually regain control, add structure, and make the application more predictable.

Good luck with your next project takeovers 🙂 And there will probably be more and more of them...