In my experience, the biggest problem is that maintainable code necessarily requires extending/adapting existing structures rather than just slapping a feature onto the side.

And if we're not just talking boilerplate, then this necessarily requires understanding the existing logic, which problems it solves, and how you can mold it to continue to solve those problems, while also solving the new problem.

For that, you can't just review the code afterwards. You have to do the understanding yourself.
And once you have a clear understanding, it's likely that the actual code change is rather trivial. At least more trivial than trying to convey your precise understanding to an LLM/intern/etc..

I'll use an LLM to write bulk code, unit tests, other boring stuff.. but, I specifically only have it write code I'm already very familiar with, and even then, I hand-code it every so often, like 1 in every 3 times I'll do it by hand to make sure I'm still able to. If I have to look something up, then I'll stop using an LLM for that task for a long while.

Yeah, a lot of maintainability is about understanding how it works. Architectural decisions are the other half. Someone who's paying attention can do well on both of these even using AI tools.