I was handed a pile of vibe code. And you might be surprised to learn that it has a ton of bugs.
And tips on how to dissect it and break it up into something manageable?
“Working Effectively with Legacy Code” by Michael C. Feathers
In my opinion, we treat it the same as any spaghetti code
An absolute must have for any software engineer. Whether they think they work wirh “Legacy Code” or not.
Ask AI to do this for you.
You need the problem space to be restricted to a manageable bunch of classes. If that’s not the case, split the problem until you get there.
Make sure you have 100% test coverage on this piece of code and that the tests are actually understandable and documenting the functionality well. You might find that there is unreachable code which should be deleted. Mutation testing may also help find code paths which are untested (and so edge cases you might not have considered).
Until that is true, write tests and/or refactor existing ones. At this point you may find a ton of new bugs there. Better find this now than later and then wonder whether your own changes introduced them. Your new failing tests will document the presence of those bugs.
By now you should have full documentation of what the code is supposed to do via tests. This will be tremendously helpful in understanding the code.
Then go public method by public method, line by line, renaming variables, extracting private methods etc. Your basic run-of-the-mill refactoring of classes, until you fully understand what’s going on in the production code.
For every small refactor, run the tests and commit if they pass. If they fail, you only have a small amount of uncommitted code which you know is the culprit.
Finally, fix any bugs you documented in the test writing stage.
At this point you can add any new functionality to the code.
Depends on the size of the pile. If it’s huge, then you have to use LLM too, with some decent tooling like Claude Code. Let it analyse the code first, and put a summary for you. Then design the proper solution yourself, and either fix it manually, or if it’s too tedious, guide LLM to apply the changes for you. Ofc iteratively and don’t let it apply changesets without your approval. I had a similar task recently, did it like that
Fighting fire with fire. I like it.
- Ask what was the purpose of the code
- Delete all the slop crap
- Make the code from scratch
can confirm. this is the way
Document the features and requirements, then rewrite it with proper architecture and without LLMs.
Cry in the bathroom
I just cry at my desk and tell them it’s because AI is so beautiful
Vibe code it a bit further, then pass it back. If they can hand you slop without second thought, why shouldn’t you?
For work, or for hobby?
Hobby: have AI document what it’s supposed to do, then work through it like the ship of theseus one function at a time replacing it with not bad code.
Work: use it, document the bugs, ninja in and clear them out one at a time until it works. Keep blinders on and ignore anything not directly related to each bug. Same strategy as legacy code.
The problem with this approach is twofold.
- The AI doesn’t know what anything is either. It can annotate faster than you, but if it is all wrong, that doesn’t help.
- The primary reason the code is bad, and something the AI is particularly weak at without a human doing much of the thinking for it is architecture. Working your way through ship-of-theseus-style isn’t going to address the fundamental reason the code is difficult to work with. The architecture.
For work. The code goes like 8 levels of abstraction. I’m trying to figure out how to unravel it.
Even a code flow/branching diagram would help I think
Depending on the language, there might exist an automated tool for generating those kinds of diagrams from code.
Nature of the code? Library, CLI tool, cloud service, API, UI?
My first thought is test suite.
Handed to review, handed to maintain, handed to extend?
Primary maintainer …
The same as taking over any legacy project applies, really.
Start out with some expectation management - the current state of the solution prevents progress from going fast, and your stakeholders need to understand that.
Then get some tests going, such that you can try to defend whatever value the system has, if any.
Finally, start refactoring as much as you can get the space to do. Repeat until the system reaches your desired state.
deleted by creator
I guess despite how intimidating it seems, un-fucking vibe code can be approached just like every other complex programming problem: by breaking it down into smaller problems and solving them incrementally.
deleted by creator
Yeah. I want to do something like this. I was hoping to run a proper dead code analysis first.
But this is a good idea. For how to reduce the code volume. I need to reduce the abstraction layers because there are a bunch of unneeded ones
deleted by creator
Of course! Vibe coding is a popular activity nowadays and *** thinking ***
Start by separating the files by namespace and class. Then, by method. Delete the first method, then the next, and so on. Then rewrite the code by hand as God intended.
Unironically get Opus to get you a base of a flow document based on the code so you can figure it out.
Then of course, you dig in yourself, understanding what Opus said, then fiflling in the gaps.
Edit: I don’t think you need to pay for Cursor to prompt Opus once for this. Just make sure to use Opus, Auto picks the dumbest model available on free tier.
