This is a pretty severe issue I have. Give it a bad codebase, and it'll happily carry on the awful, ignore failed unit tests, omit documentation, not fixing existing problems just to, and I quote, "follow precedence".
It seems these models have been (probably for the better) trained to not rock the boat too much, and keep the work to a minimum. I think we're going to end up get stuck in de-risked "just make it work" sort of mode in the near term, with all the "less good" code that's was generated relative to newer/future models. At some point, these models will need to be trained to just rewrite bad code, without excessive, often forgotten, instructions to do so.
Staying inline with the codebase is the right thing to do. It's down to you to tell it when it's time to re-engineer.
> without excessive, and very often forgotten, instructions to do so.
It forgets, within long sessions. I'm still seeing Opus 5.5 implement workarounds for bugs it created within its own session, even with explicit, and plentiful, instructions and global memories that it's time to re-engineer.
But to your point, yes, multiple rounds are required. My point is that this is going to eventually hold development back.
You can also tell it what kinds of tests to write. (Assuming you're still interested in details of the codebase).
> "AI writes overly complex ccode" - only if you let it. A "do not overengineer it" or "Pareto, 80% result with 20% of effort" go a long long way.
Also, if it wrote a complex solution, tell it write a simple one instead.
In my experience, good AI adjusts pretty well to an existing code base, and produces roughly similar abstractions to the ones it finds.