No. The natural instinct is to bump everything to today's latest and pin that, and it is wrong twice. First, the latest version is unaged, so none of your cooldown safety applies. Second, you are silently upgrading dozens of transitive deps in the same commit, mixing "pin discipline" with "upgrade everything" - so if anything breaks, you cannot tell whether the pinning broke it or the upgrade did.
The opposite mistake is just as easy: pinning to versions you think are right, from training data, a tutorial, or vague memory, instead of what is actually running on production right now.
Pin to the exact versions currently serving production. They are proven-good, because they are handling live traffic this second, and they are already aged, because they were resolved at your last build weeks or months ago. That aging is the same safety the cooldown gives you, for free.
Capture them mechanically, not by hand. On a Python backend, run pip freeze inside the live container and paste the result into requirements.txt. On the frontend, read the existing lockfile (or pnpm import against it). Now your pinning commit is a zero-behavior-change lock rather than a hidden mass upgrade, which also means it is safe to ship on a Friday.
Upgrades then become a separate, deliberate decision: one package at a time, named in the commit, aged before adoption. Related: https://www.tigzig.com/agents-faq/how-do-i-pin-dependencies-so-they-stay-pinned. Full item: https://www.tigzig.com/security/supply.
← All Agents FAQ