What can go wrong with incremental and parallel builds, and how do you guard against it?

Incremental builds can be silently wrong when the dependency graph is incomplete or stale. The classic case is missing header dependencies (a header change not triggering recompiles, fixed with -MMD), but there are others: a deleted source file whose stale .o is still linked in, a generated file whose generator changed but isn't a prerequisite, or a changed compiler flag that Make doesn't track as a dependency, all leave you running code that doesn't match the current sources. Parallel builds (make -j) compound this: with -j8 Make runs independent rules concurrently for speed, but if your dependencies are under-specified, two rules that actually depend on each other can run in the wrong order or simultaneously, producing intermittent, hard-to-reproduce failures, and a build that "works" serially can break under -j. The guards: generate complete dependencies automatically (-MMD -MP), declare .PHONY correctly, make sure every rule's prerequisites truly list everything it reads, and treat -j failures as a signal of missing dependencies rather than flaky tooling. Most importantly, run a clean build from scratch in CI on every commit, because a clean build can't be fooled by stale artifacts and proves the committed sources actually build, incremental builds are for developer speed, the clean CI build is the source of truth. So you rely on incremental builds locally for speed but verify correctness with clean, dependency-complete, CI-enforced builds.