My two insights are:
Legacy code is difficult to work with because the reasons "why" something has to be some way are missing. The "whys" can change over time, be interwoven with business requirements not in the codebase, and compound/nest with other whys that have come and gone. Often only humans in the business know, and you have to figure out who and what to ask.
Second insight is that LLMs have so far been very bad at holding on to the thread of winding, changing requirements, which is something it would have to be good at in order to revisit old codebases. Even one it wrote itself. It would need some kind of historical changes to business requirements database, which I have never seen a business keep, it'sjust the collective human knowledge of the business. Otherwise it'll make changes without accounting for historic requirements as well as your new ones.
I think there are probably some workarounds, like getting it to write lengthy documentation to refer to. Long term perhaps it just gets smart enough. Legacy codebases are something I specialise in working with somewhat, I spent a long time consulting so I was often parachuting into unfamiliar codebases and trying to quickly understand years to a decade or more, of evolving requirements in a business/codebase. I have a lot more to say on the topic but those are two of my insights.