When the AI says “use the latest version,” that’s the riskiest one

AI coding assistants routinely surface advice along the lines of "add the latest version" or "upgrade to current". Stack Overflow's accepted answer from 2017 says the same thing: "always use the most recent version of the library". There's a folk wisdom in the developer ecosystem that latest = best, and it shows up everywhere AI assistance is trained on developer-forum text.

In 2026, latest is the version with the least vetting time.

Where the advice comes from

The "latest version" rule originally meant "don't pin to a 5-year-old vulnerable version of OpenSSL." It was about fixing security bugs in libraries. That was correct advice in an era where:

The threat was bugs the maintainer hadn't yet fixed
The fix was the maintainer's next release
The supply-chain attack surface was effectively zero (the malicious-package incident rate was so low it didn't appear in threat models)

It is still correct advice for established libraries on a long-stable major version. It is terrible advice for a brand-new release of any library, because:

The threat now includes malicious versions published by compromised maintainer accounts
The fix is the previous version, not the next one
The exposure window for a malicious version is hours to days — exactly the window after a release

The riskiest version of any package is the one published in the last 72 hours.

The cooling-window argument

Look at the lifecycle of a recent npm hijack:

T - 30 days: Original maintainer adds an attacker as a co-publisher.
T - 0: Attacker publishes malicious v3.2.1.
T + 2 hours: First developers install v3.2.1 via npm install package@latest or via an AI assistant suggesting package with no version pin.
T + 6 hours: First security researcher notices the malicious payload.
T + 12 hours: Package is unpublished or yanked.
T + 18 hours: Threat feeds start listing the package.
T + 24 hours: Most dependents catch up; rotation begins.

Inside the first 24 hours, you can be hit. After 72 hours of community vetting on a new version, the probability drops a lot. After a week, it's near zero for that specific version.

That's the case for cooling windows: don't install any version newer than N days. Wait for others to find out.

Concrete policy for vibe coders

If you're shipping AI-assisted side projects, three pragmatic rules:

1. Pin major versions in package.json. Use ^1.2.3 (compatible with 1.x), not * or latest. The AI will sometimes suggest unpinned; correct it. Same for pyproject.toml.

2. Generate and commit lockfiles. package-lock.json, yarn.lock, pnpm-lock.yaml, uv.lock, poetry.lock. Lockfiles freeze the exact versions of every transitive dependency. Without them, npm install re-resolves on every machine and can pull in fresh malicious versions.

3. Use a cooling window in your gate. Most supply-chain defenses now ship cooling-window functionality: refuse to install any version younger than X hours/days. The default in Veln is configurable; common settings are 24h for individual devs and 72h for production deploys.

Combined, these three turn latest = riskiest into a non-issue, because:

^1.2.3 means npm only upgrades within 1.x (no surprise major bumps)
Lockfile pins the exact transitive set you tested
Cooling window means even if you do install a new version, it's not the brand-new-just-published one

When the AI insists on the latest

If your AI assistant outputs npm install package@latest, edit it. The shortest correct version is whichever was current last week. You can usually find it on the npm page under "Versions" — pick the second-newest, or the most recent that's at least 7 days old.

Better: tell the AI in your prompt or in a project-level rules file (most modern AI coding tools support one — check your tool's documentation for the exact filename) to never use @latest and never use unpinned versions. AI assistants are happy to follow that rule if you ask.

The setup-once version

Two commands:

veln onboarding
veln wrapper on

Inside that flow, you'll be asked to set cooling windows. Pick 24h for new versions and 72h for newly-seen packages (a default that catches almost all slopsquats and most hijacks). From then on, the gate refuses anything younger than the threshold. The AI keeps suggesting whatever it wants; the gate refuses the suggestions that are too fresh.

The honest bit

Cooling windows don't catch attacks that ride dormant for weeks before the malicious version is published — by then the package is old enough to clear the window. They don't catch zero-days in legitimate libraries. They do catch the high-frequency, fast-window attacks: slopsquats, immediate post-hijack publishes, freshly registered typosquats. That's the bulk of what an AI-assisted workflow exposes you to, and cooling windows fix it without making your AI assistant any less useful.