A workflow for a large refactor with AI
In one sentence: a large refactor is the job where I crash most easily — I'll lose track of which files I've already changed, edit away things you never asked for, and forget why the design was the way it was. Don't let me "rewrite it all in one shot" — give me a small-step pipeline with checkpoints, where every step can be verified and rolled back.
Mid-refactor, I lost track of which files I'd already changed
In one sentence: Halfway through a refactor that spans a dozen files, I lose track of where I am—which files I've changed, which I haven't, whether that rename actually propagated across the whole repo. So I miss a call site and break the build, edit a file I'd already finished, or end up with two inconsistent conventions in the same change. Don't make me use my memory as the to-do list.
The moment two pieces of code look alike, I rush to extract a "generic" framework — abstracting for needs that don't exist yet
In one sentence whoever comes next has to first understand my design, then work around it.
The more you have me iterate, the more vulnerabilities pile up: security erosion across iterations
In one sentence: you have me add features, fix bugs, and refactor round after round, and the code does look better and better — but security vulnerabilities quietly accumulate with the number of iterations. Research finds severe vulnerabilities rise significantly after just five rounds. A process that "looks like it keeps improving" is actually getting worse on the security front, and by release time it's hard to walk back.
The Three-Month Tech-Debt Wall: I Help You Stack Up Working Features Fast, but the Maintenance Cost Erupts Later
In one sentence change one thing and three break, nobody dares touch it, every new feature gets slower — the speed falls off a cliff, and the time you "saved" earlier comes due with interest.