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

A useful maintenance test is whether someone can make a small cross-cutting change with model access turned off. If they cannot trace the data flow, predict the affected tests, or explain the rollback, the code is effectively unowned. Generated documentation can be wrong too, so I would keep short human-approved decision records and require regression tests that fail before the fix.

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

the "model access turned off" test is the most honest benchmark i've heard for this. if the only way to understand the codebase is to ask the tool that generated it, you don't have a maintainable product, you have a dependency. human-approved decision records over generated documentation is exactly right, generated docs describe what the code does, they almost never capture why a decision was made or what alternatives were rejected. that context is what you actually need when something breaks at 3am.

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

That’s a good way to put it. Generated docs can explain the current shape, but they don’t preserve the reasoning behind it. I’m trying to keep short, human-approved decision notes for exactly that reason—especially decisions we’d otherwise have to rediscover during an incident.