AI makes rewrites faster to start and faster to fail.
www.neverrewrite.com
Lately, I have been engaged in a bit of cleanup work for clients' projects that have been "coded" on vibes through the now-popular process called vibe coding. (You guessed well...)
Normally, the major concerns are the overall brittleness or stability, the code quality, and the long-term maintainability of the projects.
In the beginning, I did not have a mental framework for how to approach the tasks at hand, but I think now I have cracked the code.
Sure, computer science knowledge about, for example, the various phases of the SDLC, comes in handy. But getting to the zenith of knowing what to apply and when to apply it is not intuitive.
So, here we go.
1. Start with an audit
Before doing anything, create a list of what is working, what's not working, what should be working but is actually not working as expected, and what can be improved. Communicate this to management and negotiate buy-in.
This sort of software audit will be a benchmark against which the success or failure of the rewrite will be measured. This not only establishes the scope of what you will be doing but also saves your arse in case something goes unexpectedly during the course of the refactor.
2. Define standards right away.
I have interfaced with projects where there is, for example, a huuugeee... CSS file with custom classes, a sprinkle of Tailwind CSS classes midway, a component library like ShadCN further along the road, and, to top it all off, custom components.
Obviously, my mind is always like, "WTF! Mouse click, click, click. Oh no, click, click, click." Like, it's unfathomable why anyone would let an LLM loose and end up with such a shabby job.
3. Consolidate logic into packages.
Related software components should live in the same locations for easy reference and reusability. Making stuff easier to find will save you a fair amount of mental bandwidth. For example, knowing where all your defined types live will save you tonnes of time.
A silly anecdote: Can time really be measured in tonnes (away from the metaphoric use of the word)?
4. Have "taste" for great software
I know that "taste" is, in and of itself, a subjective construct.
In this context, I use "taste" as an inference to the art or science of caring about the quality of your output as an individual and putting in the effort to ensure that your work is a reflection of your intended outcomes.
"Taste" could also mean that you do not want to commit the same felonies (read as more AI slop). You need to care about every metamorphosis that your codebase or product is undergoing.
For example, you can know more about a person by looking at how the codebase they touched is linted.
From that simple task, you can deduce whether they care about the quality and aesthetics of their output.
I have a mouthful to say about taste. But I will stop here.
5. Freeze further development in the vibe-coded project
If you are working with a non-technical team or individual, freezing further feature additions to the slop should be a priority. This is mainly because teams or individuals most often do not have the technical chops to follow the footprints of the LLM agents. This stems from the fact that LLMs are "rogue" in nature and have a way of overreaching — aka performing actions that they have not been instructed to take.
There will be friction, and it is your job as a professional to push back and explain the significance of freezing development.
6. Better start afresh
New beginnings are intimidating, but sometimes they are the only way out.
As I would come to learn, putting aside the code and using it primarily for reference is a huge productivity booster.
Since it's a clean slate, you are not grappling with past decisions, no entangled code to fight, and no type system to argue with.
This does not mean that the end product will be different from what is currently available. Rather, because you are entirely focused on code quality and feature stability, you can make the necessary refactors without being bogged down by what is already broken.
The bottom line
As AI slop cleanups or rewrites promise better stability, clarity, and a clean state of things (the code, database structure, and maintainability), setting up measurable metrics, for example, improved latency, will help manage stakeholder expectations along the way.
In any case, you are bound to encounter friction if, in the middle of the refactor, you fail to deliver on a metric you committed to, e.g., a reduction in P99 latency. Managing these expectations is your job as a trained professional.
Top comments (0)