Assistants perform well on new code in common frameworks and poorly on the old systems that consume most maintenance effort. The gap follows from what the models learned and what old code contains.
Why the training data skews new
Published code is dominated by current frameworks, recent idioms and the languages people write tutorials about.
Older systems are proprietary and unpublished by definition, so the patterns they use are thinly represented regardless of how much of the world runs on them.
The result is an assistant fluent in the conventions of the last few years and approximate about anything older.
What is missing from the code itself
Long-lived systems encode business rules that exist in no document, added in response to events nobody currently working there remembers.
An unusual conditional that looks like a mistake is frequently a correct handling of a real case, and nothing in the file records which.
An assistant reading that code sees an anomaly and suggests removing it, which is exactly the wrong recommendation and a confidently made one.
Why the absence of tests is decisive
Assisted refactoring is safe in proportion to the test coverage that would catch a mistake.
Legacy systems typically have thin coverage, which is part of why they are difficult to change and why they were left alone.
Generating tests first is the standard advice and runs into its own problem, since tests generated from current behaviour lock in the bugs along with the rules.
How the context problem gets worse
Old systems are large, interconnected and organised by conventions that predate the current structure of the language.
Relevant code is spread across files with unhelpful names, and retrieval mechanisms that rely on naming and imports find much less of it.
The assistant is therefore working from a smaller and less representative slice of the system than it would get in a modern repository.
Where assistance still pays
Explanation is the strongest use, since asking what a function does is answerable from the code itself and saves a maintainer substantial reading.
Translating between languages, generating documentation for undocumented modules and writing characterisation tests that record current behaviour are all bounded tasks with checkable output.
The pattern is to use the assistant to understand the system rather than to change it, and to keep the changes small, tested and made by someone who has read enough to know which anomalies are load-bearing.