the problem we're seeing is a strong tendency to produce solutions which add extra, undesirable connections in the code

… 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.