Your AI Assistant Just Shipped a Lockfile-Free Disaster

I keep seeing the same pattern in code reviews lately. A developer asks an AI assistant to add a library, the assistant edits package.json, and nobody regenerates package-lock.json. The pull request looks clean. CI passes on the author's machine. Then someone else installs, gets a different transitive tree, and a build mysteriously breaks. Or worse, a dependency that was never reviewed ends up in production.

This is not a small style nit. A lockfile is the difference between "we tested this exact dependency graph" and "we tested something vaguely similar." When you let an AI assistant skip that step, you are rolling dice with your build.

What actually goes wrong

Lockfiles (npm's package-lock.json, pnpm's pnpm-lock.yaml, Yarn's yarn.lock, Python's poetry.lock or uv.lock, Rust's Cargo.lock) pin exact versions and integrity hashes for every package in the tree. Without them, installs resolve floating semver ranges at install time. Two machines, two different graphs.

AI assistants are especially good at producing this failure. They often edit only the manifest file because that is the file in the context window. They may not know which package manager you use. They may not run npm install at all. If they do, they sometimes run it in a sandbox and never write the result back. The assistant's job is to make the diff look correct, and a manifest-only diff looks correct.

Outdated lockfiles are a sibling problem. A lockfile that exists but has not been updated in months still pins known-vulnerable transitive versions. The manifest says ^4.17.0. The lockfile says 4.17.0 from two years ago. You are not patched just because your range allows a patch.

Why I think this is worse than it used to be

Before AI assistants, a human who added a dependency usually ran the install command because that is how you check your work. The tooling enforced the habit by breaking the build immediately. Now a lot of dependency additions happen through autocomplete and agentic edits, and the feedback loop is weaker. The assistant declares success. The human skims the diff. The lockfile drifts.

I am not blaming the tools. I am blaming the workflow that treats dependency changes as text edits instead of state changes. A lockfile is state. If you change the manifest, you must change the lockfile in the same commit. This is not negotiable.

The pattern to look for

Here is the shape of the mistake. Notice that package.json changed but the lockfile did not.

# package.json
   "dependencies": {
     "express": "^4.18.2",
-    "lodash": "^4.17.20"
+    "lodash": "^4.17.20",
+    "axios": "^1.6.0"
   }

# package-lock.json  (unchanged, no axios entry)

The fix is boring and that is the point. Regenerate the lockfile with the package manager that owns it, and commit the result.

# pick the one that matches your repo, do not mix them
npm install                 # writes package-lock.json
pnpm install                # writes pnpm-lock.yaml
yarn install                # writes yarn.lock

# then verify nothing is out of sync in CI
npm ci                      # fails if lockfile and manifest disagree

npm ci is your friend here. It refuses to install when the lockfile is missing or out of step with package.json. That single command turns a silent drift into a loud failure. Wire it into CI. Do the same for your ecosystem: pnpm install --frozen-lockfile, yarn install --immutable, poetry install --no-update, cargo build --locked.

Rules I would put in every repo

One, never merge a manifest change without a lockfile change. Make this a review checklist item, not a vibe.

Two, treat lockfile updates as security events. When Dependabot or Renovate bumps a transitive package, read the diff. That is where supply-chain problems show up.

Three, tell your AI assistant the rules. Put a line in AGENTS.md, CLAUDE.md, or whatever your tool reads: "After editing any dependency manifest, run the install command and commit the updated lockfile. Use npm ci in CI." Assistants follow explicit instructions far more reliably than they infer conventions.

Four, do not let the assistant pick your package manager. If the repo has pnpm-lock.yaml, the assistant should run pnpm. Mixing managers creates a second lockfile and a second source of truth, which is how you get a production incident on a Friday.

Five, pin your own toolchain. packageManager in package.json or an .nvmrc removes ambiguity for humans and machines alike.

The uncomfortable part

Outdated lockfiles are a slow leak. Nothing breaks today. Then a transitive dependency publishes a malicious version, and your floating range happily picks it up on the next install because your lockfile was regenerated carelessly or not at all. Missing lockfiles are worse because you have no baseline to diff against. You cannot audit what you never recorded.

The habit is small. The blast radius is not. If your team is adopting AI coding assistants and skipping lockfile hygiene, you are borrowing speed from your future self at a bad interest rate.

Seaworthy builds dependency and supply-chain security tooling for developers who want this class of problem caught before it reaches production.