But again, how much of that time is spent writing code?

I've done rewrites, replatforms, a bunch of times. The actual programming is not the tricky part, but instead (1) picking apart the legacy system, understanding what to build, (2) orchestrating the work to shift transactions from service A to service B without breaking anything.

Teams and especially developers love to think they can skip that phase and just crack on with the programming, invariably what happens is the same as described above: intoxicating velocity followed by a hard stop when you realise you haven't solved problems (1) or (2) above

Most of a software project's lifetime will be spent as a maintenance challenge. i.e. How do we add the 237th feature without adding to the performance problems that already exist. Hence, the desire to rewrite the codebase to incorporate the abstractions of all 236 features.

I don't see AI helping with this. From my experience, it seems like the opposite. It can help you write the code after you've deconstructed the problem yourself and know how to keep it in check.

I reckon a lot of re-writes tend to take "them 5x as long as they had hoped" and "isn't even any easier than the old code" exactly because writing the code wasn't the problem in the first place.

It's business logic, edge cases and other small necessary details that accumulated over time which make the code 'messy'. Once you've integrated all those in the new system, it likely looks equally messy. And discovering and implementing all those extra requirements is probably what took you the longest.

Not to say this applies to all re-writes or that AI tools can't help the process