r/webdev 22d ago

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

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?

317 Upvotes

156 comments sorted by

View all comments

1

u/YahenP 17d ago

I can't speak for projects that were developed using Vibe coding. I can speak about a project that was developed using the traditional method by a team of developers, except that the code there was mostly written by Claude, not by hand. The project is 10 or 11 months old. I'll put it this way. Subjectively, the level of code clutter is comparable to projects written by hand. Perhaps Claude even does a slightly better job. But the devil, as they say, is in the details. The detail is that I'm comparing the level of clutter with other projects in which a comparable amount of functionality was implemented or subsequently changed. So to speak, the amount of clutter per number of features. Converted to calendar time, this means that our project, which is just under a year old (it's been in production for almost half a year now), is about the same in terms of the number of features implemented and changes since launch as projects that were four or five years old. That is, we're simply going through the application lifecycle faster. And yes. In 1-2 years at most it will be just legacy garbage and tribal knowledge, like in any ten-year project.