Your AI Assistant Forgot the Lockfile Again

Your AI assistant forgot the lockfile again

I keep finding the same mess in repos that lean on AI coding assistants. The assistant adds a package, writes the import, and maybe even updates package.json or pyproject.toml. Then it stops. The lockfile is missing, stale, or never got committed in the first place. This is not a cosmetic issue. A lockfile is the one file that turns a vague dependency list into a reproducible, reviewable build.

When the lockfile is absent, every install is a fresh resolution. That means the version your CI runs today may differ from the one a teammate installed yesterday or the one that actually shipped last week. For a blog about AI-assisted development, this gap deserves attention because the tooling makes it easy to add dependencies quickly and easier still to skip the boring follow-up.

Why the missing lockfile is a security bug

A dependency declaration says "I need some version of this package." A lockfile says "I need this exact version, with these exact transitive dependencies, and here are their integrity hashes." Security review relies on the second sentence. Without it, you are reviewing a wish list, not a build.

Missing or outdated lockfiles cause real problems:

• Unpinned transitive dependencies. The package you added may be safe, but its subtree can pull in anything that matches the resolver's output at install time.
• Non-reproducible CI. Two runs on the same commit can install different code. That makes incident response harder and makes "it worked on my machine" a security concern rather than a joke.
• Silent version drift. An old lockfile that is never regenerated means your manifest and your actual installs slowly diverge. The diff you review is not the diff you deploy.
• Missing integrity data. No lockfile, no hashes for many ecosystems. You lose the cheap check that would catch a tampered or swapped artifact.

I see this most often when an assistant is asked to "add package X" and it edits only the manifest. It is a small omission with a long tail.

What the pattern looks like

Here is the shape of the problem in a Node project. The manifest gains a dependency, but the lockfile does not change, or it is absent from the commit entirely.

--- a/package.json
+++ b/package.json
@@
   "dependencies": {
     "express": "^4.18.2",
+    "some-http-helper": "^2.1.0",
     "zod": "^3.22.4"
   }
 }

--- a/package-lock.json
+++ b/package-lock.json
@@
-(unchanged or missing from commit)

On the next clean install, the resolver picks whatever satisfies the range. Your review saw one line. Your build may get a different tree.

The fix is boring and that is the point

Regenerate the lockfile after every dependency change, and commit it with the manifest in the same change. If your assistant edits the manifest, ask it to run the installer and include the lockfile diff. In CI, fail when the lockfile is out of sync. In review, treat lockfile changes as code changes, because they are.

# after any manifest edit, regenerate and commit together
npm install

git add package.json package-lock.json
git commit -m "add some-http-helper and refresh lockfile"

# CI guard: fail if install would rewrite the lockfile
npm ci

git diff --exit-code -- package-lock.json

For other ecosystems the command differs, but the rule does not. Python projects should commit poetry.lock, uv.lock, or Pipfile.lock and install with the locked mode. Go projects should commit go.sum. Rust projects should commit Cargo.lock for applications. Pick the locked install command in CI and make drift a build failure.

One more habit worth adding: after an assistant makes a dependency edit, check git status for an untracked or modified lockfile before you accept the change. It takes seconds and catches the omission early.

AI assistants are good at writing the line that uses a library. They are inconsistent at finishing the operational chore that makes that line safe. That is not a reason to avoid them. It is a reason to put a cheap guard in place and to review the artifact that actually determines what gets installed.

Treat a missing lockfile as a security finding, not a style nit. The dependency list is a request. The lockfile is the receipt, and you want the receipt in version control.

Seaworthy is a security platform that helps teams review dependency and lockfile changes.