Tips on dissecting vibe code

1. Ask what was the purpose of the code
2. Delete all the slop crap
3. Make the code from scratch

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.

“Working Effectively with Legacy Code” by Michael C. Feathers

In my opinion, we treat it the same as any spaghetti code

Document the features and requirements, then rewrite it with proper architecture and without LLMs.

Cry in the bathroom

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

Of course! Vibe coding is a popular activity nowadays and *** thinking ***

Handed to review, handed to maintain, handed to extend?

Nature of the code? Library, CLI tool, cloud service, API, UI?

My first thought is test suite.

You could try the Mikado Method. It is good for disentangling code with a mess of complex interdependencies.

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.

Ask AI to do this for you.

If possible, you could try to get the requirements and design to those and write something new.

If that's not possible, I would start flow-charting. I always do it by hand in whatever tool you have handy. Some languages have tools that can do this for you (Go and Java and I think PHP to name a few) if it's that big of a mess. From there, find your inputs and outputs and go back to the "rewrite it" part.

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.