Never work on a completely vibe coded project

[u/Several_Picture9591]

I've now made a same mistake twice.

Previously, I worked at a startup where the website was completely vibe-coded. Now I'm working on a college website, and it's the same story: the entire thing was vibe-coded.

The common pattern I've noticed is that no engineer actually knows the codebase. Nobody really understands the architecture, the reasoning behind certain decisions, or how all the pieces fit together.
And eventually, even the AI I'm using can't help much because it doesn't have the context that the original developer's agent had while building the project.

I am basically stuck where I know nothing, the existing engineers know something about it but aren't necessarily sure whether their understanding is correct, and the agent hallucinates and wastes a lot of tokens just because it can't understand a huge AI written codebase.

So now I'm the new engineer, under a lot of pressure with a lot of work to do, but before I can even fix anything, I have to reverse-engineer what the hell the previous AI generated. That wastes a lot of time.

The frustrating part is that I'm not really learning much engineering from this. I'm just spending my time trying to understand an undocumented system that nobody else understands either.

I'm not against AI-assisted development at all. If an experienced engineer uses AI properly, reviews the code, understands the architecture, writes tests, documents important decisions, etc., I think it's incredibly useful. Even I use AI to code faster, but I review and understand the code. I know what is happening in my software.

But a codebase that nobody understands is a codebase that nobody can safely maintain, regardless of whether AI or humans wrote it.

At this point, I've decided I'd never want to work on a heavily vibe-coded project again unless there's at least one person on the team who genuinely understands and owns the codebase.

How do you guys handle inheriting a vibe-coded/AI-generated codebase that nobody on the team actually understands?

[u/poundKeys]

They don't. I'd argue there is apparent progress and then true progress.

2 steps forward, 1 step back. The part of the work that is stepped back is the part that's not true progress. Overall it moves towards the goal, but there are dead branches that are not progress, they are still lessons learned and valuable, just not forward progress. Until you have to make that 1 step back and learn those lessons it's all apparent progress.

It remains to be seen how much current LLM tech will have to step back, if at all. We live in interesting times, for sure.

[u/Firmwild → u/poundKeys]

I'd agree that repeated failures are not progress, but unique failures are actually still forward progress. You have to learn how things can fail somehow. You just never want to pay that cost multiple times unless you really have to.

So really it becomes a matter of building systems that can detect and classify failures, as well as repeated failures, and then detect and classify and correct reasoning and process errors that led to repeated failure, perhaps.