They build their games on daily basis, this has nothing to do with shader compilation. A development build isn't any different than a final one here.
Let's help
@Remij understand this part better, as more explanation can help.
Let's start with this: at this point in the thread, everyone should understand the "shader stutter" is a byproduct of raw shader code which must be compiled to most effectively use the user's graphical environment, and this compile happens automatically when the shader is first encountered. Once the shader is compiled, the completed result
can be cached either by the game or the driver or a combination of both. It can also be completely uncached, which results in the same jitter / stutter / pseudo-random frame drops during gameplay.
When we're talking about developers testing their code,
@DegustatoR is mostly correct, in that a high-quality dev shop will usually see individual developers compiling their own code and testing it, either in isolation or as a compiled version of their entire checked-out code branch (eg to test their code against the entire codebase.) This is even before the QA team gets ahold of it, as a way to ensure the dev isn't submitting broken code and simply shoving it onto the QA team to figure out how it's b0rked. In one of my prior roles as a development manager, we would absolutely admonish those devs who submitted code which they had not at least "unit tested" themselves. That certainly doesn't mean the code is 100% good, it just means it doesn't outright fail and, at some foundational level, meets all the functional requirements set forth without bombing the entire branch build. (WHICH ONE OF YOU JERKS BROKE THE BUILD?!?! /Bruce Y, our build lead -- don't get that guy angry lol)
Alright, so the devs are testing their snippets of code on their own worstations or maybe a QA environment they've checked out from the lab. Chances are high that workstation has seen a thousand different versions of that same code, and chances are REALLY high they haven't been playing any other games on those same workstations. As such, if the driver is doing it's standard job, then the shaders are already cached and the stutter will not show up.
Let's say the dev build is promoted to a release candidate (RC) build. The QA team lods up the final build on forty different QA workstations, and they begin automated regression for functionality and also play testing. If we're really in RC, then I wager the actual devs load up the game on their own workstations too. Everyone plays the game for days, weeks, maybe months while trawling for buggies.
Unless everyone completely wiped and reloaded their workstations from bare metal, chances are incredibly high every single workstation had cached copies of the shaders from a zillion prior code builds. They'll never see it.
"But why don't they completely reimage every workstation after every build?"
Unless that's the sort of work you do for a living, completely reloading an OS and all the requisite toolchains and binaries and drivers and yadda yada is immensely time consuming. Also consider, these cannot be 100 identical workstations. By necessity and design, all the QA machines NEED to be different hardware specs to test out all the facets of the game engine. You'll need AMD and Intel CPUs, you'll need AMD, NVIDIA and Intel GPUs, you'll need SATA spinners and SATA flash drives and NVMe flash drives, you'll need boxes with 4GB of ram and boxes with 16GB of ram and boxes with 32GB of ram. You'll want boxes with external sound cards and internal sound cards. You'll want rigs with 16:9, 16:10, 21:9, 32:9, and 4:3 monitors. This isn't an environment where someone (who doesn't do this for a living) can just "slap out" a standard image across all the boxes and call it done.
My prior software dev org specifically focused on completely hands-free OS reloads across a limited set (roughly a dozen) of hardware platforms. We wrote probably fifty thousand lines of code to manage and package the unique drivers we needed (unrelated to the PC itself), the application installs (most of which were never intended to be hands-free or support any programmatic configuration) and it took us almost a year to get
really good at it.
So yeah, these test workstations have seen that code, dev QA and prod, and are highly likely never to stutter unless individual shader code is updated. And by the time an RC build hits the test bench, those workstations have all seen that shader code.
