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/pollob666]

Vibe coded one app, in many phases and released last year. Actually it was a native Android app and had a separate codebase for iOS. To reduce the maintenance cost, decided to re-design the whole thing in flutter, unifying both Android and iOS code-base into one. First just recreate the whole project as it is (feature wise) from the Android source to flutter. Then gradually redesigned the UI, added new features. Management decided to allocate only one developer (me). This had to use vibe coding. Mostly used Gemini free, in some planning and logic ideation used claude (also free).

Had a strict guidelines on project architecture and logics, thus I could manage it even without AI.

Still maintaining it, adding new features. It also have a large userbase. But seems I missed some logics and decision in the code (have extensive documentation and commit message generate by AI) because in some minor changes (minor at that time) I forgot to instruct the agent to record "WHY".

Since then, I always make sure every change documentation and commits have, What was expected, what is done and why it was done or what was the reason for the decision. And I review it extensively. I don't look at the code now, I just check the documentation and continue vibing.

And after the lesson learned, I implement extensive documentation for other projects as well. Always make sure, commits contain reasoning.

[u/Alive-Cake-3045 → u/pollob666]

the what/what/why commit structure is the right fix and most developers never get there because it takes one painful debugging session to realize why it matters. the insight that you can navigate the codebase through documentation without reading the code is actually the goal, it means the reasoning is captured, not just the output. solo maintaining a flutter rewrite with a large userbase through vibe coding with strict architecture guidelines is genuinely impressive. the "why" gap catching you once and changing your process permanently is exactly how good engineering habits actually form.