What if the code sucks, because it was vibe coded by an LLM over a dozen disparate sessions?

If it performs the overall function but the code is a mess, then you can ask the model to describe parts of it, the structures and what the structures are for. When it shows you something that is messed up, suggest a better framing for the same thing and ask the model to implement the better framing without regressing on already passing tests.

I'm going through this right now on a very difficult to implement task, the original was python and very verbose. But had facilitated a rust implementation that produced byte identical outputs. Then I asked it for what data was being passed around, placing restrictions on what passed between interfaces I could tell it what parts should be immutable and what parts should have no presence outside it's local context. Placing those limitations while having a exemplar of what it should be doing gives it little choice but to make better code if it meets the conditions set while at the same time not regressing.

I say things like 'this field is a implementation detail in a declarative data structure, it should not exist here.

This can mean hours of work with no observable change in program function, yet it is directly addressing the limitations that prevents it from being used in larger tasks.

Then that's the point. You know the code sucks, the guy who vibecoded it either didn't know or didn't care. That's the added value.

Claude, make this codebase less ass

Then fix it using the llm