It's not even complexity; raw size suffices to make a codebase hard for the LLM to manage, which is especially bad given the high ratio of LLM lines to ideal lines for any given change. E.g., if a concurrent hashmap is a reasonable primitive, it won't check if any of the existing ones are good fits. It'll instead prefer to implement something simpler but totally broken, or else it'll try and fail to build yet another concurrent hashmap. If you fix that by giving it explicit instructions to use a particular implementation, it'll manufacture extra (incorrect or low-performance) methods out of nowhere rather than solving within the constraints of the existing API -- think things like adding a global lock around the whole thing to make "concurrent" iteration possible when iteration isn't even a primitive the thing you asked the LLM to do requires.

A colleague of mine had the observation that the problem we're seeing is a strong tendency to produce solutions which add extra, undesirable connections in the code, resulting in inordinately complex API boundaries which are hard to properly disentangle.

That's all fixable with enough effort, but it's hard to ignore that experience when somebody comes along and tells you that vibe coding really does suffice by itself, and you can just point a good model and harness at a ticket and a codebase and let it rip.