upvote
Personal experience:

AI tends to add new wheels for a new feature in a large codebase, because finding, understanding, and generalizing the existing code to integrate a new feature will likely break existing features, cost more effort (and token) to implement and test. Human reviewers also tend to like these code since they are clean, easy to review, and get the job done, especially when they are not familiar with existing codebase.

The issue is that wheels like these accumulate in the codebase, and they inevitably entangle. When an upstream specification changes, when a new feature that works with many existing features are introduced, all these wheels need to be revisited, and in many cases they are not because the new test cases do not cover all the paths. The code base got larger and more complex, and contains more bugs than the unit tests can cover, especially when unit tests are often "bent" to fit the wrong behavior unnoticed.

reply
I’ve had multiple occurrences (with the latest models) of AI reading a poorly named db column and assuming it was one thing when it was another that resulted in a problem. It does not know when to stop or when to continue with determining what is true.
reply
-
reply
Yep.

The worst part about this is that if you aren't watching it, the AI will "solve" this with a thousand assert_3_plus_5_equals_8() test cases that just further clutter the workspace and the context window. Churn baby churn.

reply
I haven't had this issue since like last year with frontier models. What are you using?
reply
All the models do this. I'm literally right now watching Opus 5.5 duplicating code even after telling it to fix duplication.
reply
The models are pretty good at finding code duplication and eliminating it though, and it's usually part of my AI review process at this point

If you let it go buck wild on a massive change, there are those times where it sort of paints itself into a corner but rewrites are cheap (for now), so it's just not that big of a deal, imho

reply