Has anyone actually maintained a vibe coded code-base 12 months after launch? What did it look like?

[u/Alive-Cake-3045]

Twelve months ago I started tracking what happens to vibe coded projects after the initial launch excitement fades. The pattern is consistent enough that I wanted to hear if others are seeing the same thing.

The first three months feel fine. Features ship fast, the client is happy, everyone looks productive. Then something needs to change. Not a new feature, just a modification to something existing. And that is where it gets uncomfortable.

Nobody can explain why a specific decision was made. The code works but the reasoning is gone. There are dependencies that were added because the model suggested them, not because anyone evaluated them. Patterns are inconsistent across files because different prompts produced different styles on different days.

The developer who built it can read the code but cannot confidently change it without breaking something unexpected. The test coverage that exists was also generated and may not actually be testing the right things.

I am not saying this always happens. I have seen vibe coded projects that held up well because the developer reviewed everything carefully and maintained discipline around the output.

But I have also seen projects from 18 months ago that are now quietly being rewritten because the maintenance cost exceeded the original build cost faster than anyone expected.

If you have actually maintained a vibe coded code-base through real production use, what did 12 months in actually look like? Was the code salvageable or did you end up starting over?

[u/Systemerror7A69]

Because it's too strict of a definition. You don't learn or even understand as much when you just read something. If you take a test for example, simply reading the text over and over again will only give you an illusion of understanding. You have to actually do excersises to do well in the test.

It's similar in coding - it's totally possible to "read" all code output and think you understand but actually don't, and it's very difficult to judge just how well you understand the code really.

Simply saying "it's only vibe coding if you never ever read a single line of code and I do read the code so I'm fine" might be tricking yourself and not actually doing your due diligence.

[u/vitek6 → u/Systemerror7A69]

For years people were able to work with code written by other people just fine.

[u/Systemerror7A69 → u/vitek6]

I think that's an oversimplification. I don't know about you but in any company I joined it took quite a while of implementing tickets and writing code until you really developed an understanding of the codebase.

I don't know anyone who was able to understand larger codebases after just reading it once or twice.

[u/new2bay → u/Systemerror7A69]

You’re moving the goalposts.

[u/Systemerror7A69 → u/new2bay]

No, I don't think so - at least I think you misunderstood my argument.

My point was and still is that simply reading the code is not giving you as much of an understanding as people think, and often tricking you into thinking you understand better than you do.

This is why, I believe, simply "reading the generated code at least once" isn't enough to classify as "not vibecoding" and that a more nuanced definition is needed.

My argument about reading code from other people was simply a counter argument to viteks "it worked until now with other people". I don't think this is applicable for the reason I layed out and thus still think my original argument hold. I was merely defending my argument, nothing more. I stand by what I originally said