7 Warning Signs Your Codebase Was Vibe-Coded (and What Each One Actually Costs You)

Most founders can't personally read their own codebase closely enough to know how much debt is sitting inside it, and that's fine, that's not the job you hired an engineering team for. But there are symptoms visible from outside the code itself, in how the product behaves, how the team talks about it, and how confidently anyone can answer a direct question about it. Here are seven of the most reliable ones, roughly ordered from cheapest to most expensive to leave unaddressed.

1. Nobody can explain why a feature was built the way it was

Ask any engineer, including the founder, why a specific piece of logic exists in its current form, and if the honest answer is "that's what the AI suggested and it worked," that's a sign the decision was never actually made by a person, just accepted. This costs little by itself today. It compounds badly later, when that logic needs to change and nobody can say what it depended on or why.

2. The same feature seems to be implemented in more than one place

If pricing logic, permission checks, or formatting rules behave slightly differently depending on which screen you're on, that's not a visual bug, it's a sign the same problem was solved independently multiple times across separate prompt sessions that had no memory of each other. The fix cost rises the longer it's left, because every new feature built on top inherits the inconsistency.

3. Test coverage exists but doesn't test anything that would actually break in production

Tests that exist purely to pass, checking that a function returns a value rather than that it returns the correct value under real conditions, give false confidence that's arguably worse than no tests at all, because they make a broken deploy look safe. This is a quiet, expensive one: the cost shows up later as a production incident nobody saw coming because "the tests passed."

4. Error handling only covers the happy path

If every demo works flawlessly but the product breaks in unpredictable ways the moment a user does something slightly unexpected, bad input, a slow network, two actions in quick succession, that's a strong signal the code was shaped by prompts describing what should happen, not what actually happens at the edges. This is moderately expensive to fix and gets more expensive the more of the product is built on the same unvalidated assumptions.

5. Dependencies were chosen for familiarity, not fit

A pile of popular packages, several doing overlapping jobs, often means an assistant reached for whatever was most common in its training data rather than what the project actually needed. Individually cheap to fix. Collectively, a bloated, harder-to-secure dependency tree that costs real time every time one of them needs a security patch.

6. Nobody has ever deliberately deleted code

Codebases that only ever grow, that never have a pull request whose entire purpose is removing something that turned out to be unnecessary, usually aren't being edited with real understanding, they're being added to. This is a cultural signal as much as a technical one, and it's one of the more expensive patterns to reverse once a team has gotten comfortable never saying no to new code.

7. The person who "built" the MVP can't answer a basic architecture question on the spot

This is the costliest sign on the list, because it means the fix isn't just technical, it's a knowledge gap with no easy source to recover it from. If the founder or the original builder can't sketch, from memory, how the core system actually fits together, that understanding doesn't exist anywhere, and rebuilding it requires someone new reading the whole codebase from scratch rather than just asking the person who wrote it.

None of these seven signs are fatal on their own. What makes a codebase expensive is how many of them are true at once, and for how long nobody checked.

None of this means the product was built wrong, or that vibe coding was a mistake. It means the gap between a working demo and a properly load-bearing system has to be closed deliberately, by someone looking for exactly these signs, rather than left to surface on its own. If more than two or three of these sound familiar, that's less a verdict than a starting point for a conversation about what a proper takeover and audit would actually involve, and it's worth reading about the specific security patterns worth checking first before deciding how urgent that conversation is.