No one knows if this is AI related, but it's easy to imagine that where changes written by AI fail in production, if AI can't find the solution (which will be common as AI access to production systems is typically reduced), then the devs won't either, or at least it will take them some time.

Perhaps the velocity is the problem, not that AI inherently produces worse code (you just need one bad or just inexperienced engineer have their PR slip through to have bad human written code in you code base). When the velocity is high, there's less time to battle test each change and new code piles up on the old one. When the velocity is low, shitty code fails in production, but people are aware of what was recently changed and can find and fix the problems.

Same thing, now, just faster: one bad engineer can now ship a million lines

Well, yes. My point was more that even if the quality was better, the speed of change is a problem. In particular in mature systems, I should add.

For some reason people seem to think that just because AI exists now, code no longer needs testing thoroughly.

Yep, and having a ton of AI written unit tests pass is not the same as running incident free in production for a month.

The status updates have a pretty strong "LLM-driven agent failing to debug a complex system" feel to them. I hope it's not the case, but I could imagine a scenario in which inexperienced engineers - or experienced ones who have lost touch with the codebase - are deferring to LLMs to drive the troubleshooting and fix here.

They sound exactly like frustrating conversations I'd have with a cheap model and an overextended context window.

Maybe the error itself isn't event AI related, but the engineers that knew how to fix it were let go

The bigger issue with having your systems written by AI, is that nobody knows how the system works anymore and can't pinpoint where the likely failure points are.

Ugh. My sarcasm detector is down. Shouldn't have hosted on MS servers.