9.10 When to flake, and when not to

The final lesson of the flakes section answers the question everything has been building toward: when are flakes the right tool, and when do they get in your way? Drawn from real customer projects, you get the honest trade-offs: evaluation caching that developers rarely benefit from, git awareness that helps and hurts, and a design that cannot be parameterized.

In this video

• Why a one-character change to your README can trigger copying a gigabyte repository into the Nix store
• The git index surprise that makes flakes ignore your new files, and who that behavior actually serves
• Why follows is not a substitute for overlays, no matter how often people claim it is
• Flakes as a user feature versus a developer feature, and what that means for monorepos
• The dual-use design: one project layout, built on overlays, that serves flake users, non-flake users and every pinning tool

After this lesson

You can make an informed call for each project: where to provide a flake, where to skip one, and how an overlay-centric layout keeps both doors open without a company-wide policy fight.