After a long stretch of I just ask codex to:
Audit the code base and event changes and describe the data model and all related and possibly overlapping functions.
Plan a new redesign that is simpler, has less code, more reuse and cleaner design,
Execute the refactor
Review the code and asses new code and reaudit
… repeat
You can queue these up in codex and it will just go about its way reducing your tech debt way faster than an engineer could.
I think this might work for smaller codebases, but the main point of my article isn't really about vibe coding. Vibe coded apps are typically smaller anyway, so refactoring isn't that big of an issue there.
When we're talking about actual software that has been around for a while and has accumulated serious tech debt, it's not so easy. I've definitely worked on apps where your described approach doesn't lead to anything viable. It's just too much for an AI to grasp when you have years of accumulated complexity, dependencies, and business logic spread across a large codebase.
Regarding vibe coders specifically: I think people who can't code themselves often don't really know what "cleaner design" or "more reuse" actually means in practice. They can certainly learn, but once they do, they're probably not vibe coders anymore.
With AI generation of code or text, I have found that quality improvements have to be run multiple times, successively, until the achieved quality reaches my expectations. Prompts must also be refined before letting it run multiple times.
This is so not a problem.
After a long stretch of I just ask codex to: Audit the code base and event changes and describe the data model and all related and possibly overlapping functions.
Plan a new redesign that is simpler, has less code, more reuse and cleaner design,
Execute the refactor Review the code and asses new code and reaudit
… repeat
You can queue these up in codex and it will just go about its way reducing your tech debt way faster than an engineer could.
I think this might work for smaller codebases, but the main point of my article isn't really about vibe coding. Vibe coded apps are typically smaller anyway, so refactoring isn't that big of an issue there.
When we're talking about actual software that has been around for a while and has accumulated serious tech debt, it's not so easy. I've definitely worked on apps where your described approach doesn't lead to anything viable. It's just too much for an AI to grasp when you have years of accumulated complexity, dependencies, and business logic spread across a large codebase.
Regarding vibe coders specifically: I think people who can't code themselves often don't really know what "cleaner design" or "more reuse" actually means in practice. They can certainly learn, but once they do, they're probably not vibe coders anymore.
With AI generation of code or text, I have found that quality improvements have to be run multiple times, successively, until the achieved quality reaches my expectations. Prompts must also be refined before letting it run multiple times.
In my experience codex fails at that kind of task in many cases.
I think it’s unlikely it will succeed at that task with a real world , old, large codebase.
Now, the next release might work !
You know nothing Jon Snow....
Who is going to tell them? (vibe coders)
And who's going to tell the managers?
Who is going to tell the consumer?