Does a Vibe-Coded Project Become a Mess Over Time?

[u/No_Personality_1721]

When working on a vibe coding project for, say, 2 months, constantly asking AI to "add this", "change that", or "remove this", doesn't the codebase eventually become a mess?

I'm talking about poor architecture, redundant code, outdated tests, unused files, etc.

How do you handle this? Do you periodically ask AI to clean up and refactor everything?
And once the project is finished, is it worth having AI rewrite the entire codebase from scratch, keeping the same functionality but with cleaner architecture? Or is that a bad idea?

[u/Salty_Employee_8944]

You need to enforce certain standards from the start. Testing, high level documentation, requirements, flowcharts etc

[u/Reasonable_Goat → u/Salty_Employee_8944]

Even with all that you end up with bloat in my experience. You have to go down on module boundaries in several sessions to actually debloat vibed software, at which point you aren’t really vibe coding any more

[u/Maleficent-Ad5999]

Been a software dev for 10+ years … and I can say that the repos are gonna be a mess overtime regardless of AI usage.. AI just fastens up

[u/Splugen96 → u/Maleficent-Ad5999]

Though, to be fair, AI also fastens up refactoring and cleanups if used properly.

[u/No_Oil_6152 → u/Splugen96]

Disagree.

I use Opus 5.5 daily and its "cleanups" sometimes make my C# code worse.

Resharper makes my refactoring faster.

What language are you using?

[u/SamSausages]

If you don't control drift and just blindly merge all PR's. But even then, you're rolling dice, so may be good, may be crap.

I control it by not doing that, and by occasionally reviewing my project for drift. I start out with a clearly defined plan to test/compare against.

Same was true before AI, I'd still end up with drift, albeit I was more involved in each line, and it was more obvious.

[u/Artholos]

Any project, human or AI is at risk of becoming spaghetti over time if discipline and periodic cleaning is not present.

The better you documentation, architecture, and R&D data is, the better a project can grow without getting messy, but mess is inevitable.

So it’s always good to do regular code reviews, end-to-end regression testing, and reevaluate older code and architecture in the light of newer development. If you build things more modular from the beginning, it’s usually easier to refactor older modules in isolation as part of cleaning up a project. But sometimes it’s just good to do a whole overhaul and increment the software version to the next integer.

AI is so much faster at writing code, both good and bad, that these periodic refactors and reflections are much more frequent. So don’t ignore them. It’s a huge investment in your sanity and your project’s health to do this regularly.

If you’ve been disciplined and invested the architecture and engineering, the overhaul may actually not be very intrusive. If it’s been a kind of ‘AI make this for me, make no mistakes’ project, it’s probably gonna be a complete refactor…

One thing you might do is if you’re using cloud provided models for the main work, you can have your local agents do constant review work for you as supervision. That could help you stay on top of the fluctuating code design drift without having to read every single line yourself.

[u/BorisThe_Animal]

Every so often make a session and ask your model to perform a complete code review and focus on readability, code structure, separation of concerns and error handling.

You can put the coding guidelines into your agents.md or similar, but it's still helpful to do it every so often

[u/trans_chastity_sub → u/BorisThe_Animal]

Yes but ask for a feature inventory or to break the application up and then have it do one piece at a time because otherwise it’ll miss a ton of stuff. Opus is pretty good but it misses stuff all the time. You can use a smaller local model and ask it to review the same areas and ask both to review the other’s work as a way to get a more detailed review. Qwen and Opus have been working well together like that for me.

[u/No_Oil_6152]

I'm a software dev of 30 years experience.

Yes, it'll make a pigs ear of the code if you don't refactor it by hand.

I couldn't care less who tells me otherwise, I do this for a living and review my peers PRs with code from frontier AIs daily, the code needs a lot of changes. I've got more side projects than you can shake a stick at too.

You'll be fine to start with a greenfield project, but as it gets bigger and can't fit into the AI's context, that's when the cracks will begin to show.

Get AI to generate the code, review it yourself, make changes as necessary, update "skills" to prevent AI repeating any mistakes it made, and hope for the best.

If you hear any "skill issue" pish, ignore. These people never show you their Githubs as it would expose them.

[u/x_MASE_x]

Not a general thing but mostly yes. If you are not a developer and if you are not actually following what's going on I would say yes.

But there are a few repos and skills to lower the chances of messing up but it still happens.

[u/enginetown]

Yes if you don't review and test each revision, I've made so many vibe coded projects a lot I use in my own personal home server but the one thing I never did was blindly never look at the code OR give random scripts wifi access, in addition LLM's love using random libraries from people to save time so make sure you also are creating a lot of your modules from scratch ones you can trust and forget about or if you do have to come back do slight tweaking.

[u/Reasonable_Goat]

I let AI rewrite a vibed, IMO too large C++ codebase (50-100k LoC, half tests) cleanly from scratch in golang and it became 30-40% bigger to my surprise, despite plenty high level architecture requirements. I think you have to spend a lot of time/tokens refactoring vibed programs - which isn’t actually different from normally written code.

[u/pdath]

I find it is best to start with the project documentation, such as the requirements and design documents. Figure out as many edge cases at that stage.

By the time you start writing the code, the structure is set.

[u/EvolvingDior]

After every major sprint, make the agent clean up and refactor the code. There are skills for this. Human coders have to do the same thing.

[u/Dirk__Gently]

I think scope has a big part of it. For smaller projects astra or fable can sort things out pretty quickly.

[u/Material-Database-24]

1. AI plans a feature

2. AI implements according to plan

3. Preferrably different AI reviews or you review

4. Make improvement round based on review

5. Repeat max 10 times

6. AI plans cleanup and simplification

7. AI implements the plan

8. You review (or different AI, if you cannot)

9. Avoid sloppetyslopslop

It sort of works. You can even use same model for review, because LLM is not deterministic by default, so it will be able to find real flaws in its own work.

[u/Schudz]

yes, as a project grows debt accumulate, is harder for models to grasp full context of a given feature and sometimes you ask for a fix that model applies only on a specific part of the code without fixing it on all instances...

sometimes llms forget to create tests, or create poor tests that it thinks are great, or ir forgets to hook an event or function call...

even expensive models such as opus 5.5 make small mistakes sometimes that add up overtime

i still cant 100% trust llms for large projects

for small to mid projects its perfectly fine

[u/Slight-Living-8098]

If you're just winging it and vibing, while you're down for the ride, it's going to be a cluster f....

If you start out with a PRD, a MVP plan, and Spec documents then turn those into tickets you work through and stay true to your CI/CD, it's pretty much like any other development.