Simple, contrived example: if I create an open-world game with open-world design, I can complete quests in any order. Maybe I can start doing a quest, and then decide to stop doing it halfway through, or maybe I can switch quests halfway through.
The test case matrix for this is now: every quest x every other quest. If some quest spawns a timer that will do something in 3 minutes, and something else forgets to stop it when I switch quests, that's a bug. Maybe the timer spawns some NPC, and it should stop when I switch quests. Or maybe the timer will reset some world state, and should fire immediately once I switch quests. But maybe not always -- if I complete the quest but the game internally 'switches quests' to the next one in the cycle, I don't want to despawn the NPC.
Is this code? Not really engine code, it's more like data, or scripting? It's not really the code that's reusable between games, and between engines; it's custom-built for the game's flow itself. That's where, in my experience, a good majority of "AAA bugginess" happens.
Every engineer knows interacting mutable state tends to make code buggier. Well, a game simulating a virtual world is essentially a huge ball of deeply interacting mutable state by design.
The real hell comes when you think you're working on one and it's actually the other; you either burn time on an overcomplicated solution or invent a maintenance nightmare.
Just like any other development, you need to make guesses about what will change and what will stay the same and your efficiency depends on the accuracy of those guesses.
I've never been in the gaming industry, but what I've heard from some developers is that writing very dirty throwaway code is the norm, since most of it is thrown away anyway when the game is done. Which leads to the buggy mess we get even from many triple A games, and a never ending cycle of re-writing the same things for each game, even within the same studio.