Your AI assistant forgot the lockfile, and that's a problem

Your AI assistant forgot the lockfile, and that's a problem

I reviewed a pull request last week that added a new dependency to a Node project. The change was clean, tests passed on the author's machine, and the AI assistant that generated the code had even written a cheerful commit message. There was just one issue. The package-lock.json file was untouched. The assistant had added the package to package.json and moved on, as if the lockfile were optional decoration.

It is not. A missing or outdated lockfile is one of the quietest ways to break a build, hand an attacker a window into your supply chain, and make every developer's machine a slightly different universe. And yes, I am annoyed. This is a basic hygiene issue that AI tools keep reintroducing because they optimize for the immediate diff, not for the health of your repository over time.

What a lockfile actually does

A lockfile records the exact versions (and often the integrity hashes) of every dependency and transitive dependency your project resolved at install time. Without it, npm install, yarn install, pip install, or cargo build may pick newer minor or patch releases whenever they run. That sounds harmless until it is not. A new patch version can change behavior, drop a transitive dependency, or pull in a different maintainer's package entirely.

When an AI assistant edits package.json and skips the lockfile, you get a split brain. The manifest says one thing. The last known good state says another. CI might pass today because the registry happens to serve a compatible version, and fail tomorrow when a transitive dep publishes a breaking change. This is how builds become flaky and how security scanners report vulnerabilities you cannot reproduce locally.

The supply chain angle

Lockfiles also pin integrity hashes. If your lockfile is missing, your package manager trusts the registry to return the same tarball it returned last time. Usually it does. But if a maintainer's account is compromised, or if a package is republished with different contents under the same version (which some ecosystems technically allow), you have no way to detect the swap. A lockfile with hashes turns that silent substitution into a loud failure.

I have seen teams argue that lockfiles are noise in code review. That argument falls apart the moment a malicious or broken transitive dependency lands on a Friday afternoon. The lockfile is the only record of what you actually shipped.

What the pattern looks like

Here is a typical AI-generated change that forgets the lockfile. The assistant edits the manifest and stops.

--- a/package.json
+++ b/package.json
@@
-    "express": "^4.18.0"
+    "express": "^4.18.0",
+    "left-pad": "^1.3.0"

No change to package-lock.json. The fix is not magical. Install the dependency with your package manager so the lockfile updates, then commit both files together.

# Correct workflow: update manifest and lockfile in one step
npm install left-pad@^1.3.0

# Verify the lockfile changed and is in sync
git diff --stat package.json package-lock.json

# In CI, fail fast if the lockfile is out of date
npm ci

The npm ci command is the important one. It installs strictly from the lockfile and errors if package.json and the lockfile disagree. If your CI uses npm install instead, you are quietly allowing the lockfile to be ignored. Switch to npm ci (or yarn install --immutable, pnpm install --frozen-lockfile, pip install --require-hashes, and equivalents) and make that the default.

For Python, the equivalent discipline means committing a fully pinned requirements file or a lockfile from a tool like pip-tools, poetry, or uv. For Rust, Cargo.lock belongs in version control for applications. For Go, go.sum is not optional. The principle is the same across ecosystems: if you want reproducible installs, you must commit the resolved state.

Why AI assistants keep making this mistake

AI coding tools are trained on diffs, and the training data is full of human commits that edit manifests without lockfiles. The model learns that pattern. It also has no concept of your CI pipeline, your deployment cadence, or the fact that a missing lockfile entry is a security event rather than a formatting nit. When you ask for a dependency, the assistant gives you the smallest visible change. The invisible change (the lockfile) is exactly where the risk lives.

You can work around this by adding an explicit instruction to your assistant's system prompt or project rules: always update the lockfile and run the install command. Some teams add a pre-commit hook that rejects commits where package.json changed but package-lock.json did not. That hook catches humans and AI assistants alike. It is blunt and effective.

A short checklist

• Commit lockfiles for applications. Always.
• Use frozen or clean install commands in CI, not the default install command.
• Reject pull requests that change a manifest without updating the lockfile.
• Review lockfile diffs, even if you skim them. Look for new transitive dependencies and integrity hash changes.
• Teach your AI assistant the rule in writing, because it will not infer it.

None of this is glamorous work. It is the kind of task that feels like overhead until the day it saves you from shipping a compromised package or debugging a build that only fails on Tuesdays. The AI assistant that generated your code will not remember this tomorrow. Your lockfile will.

If you want to check whether your projects follow these habits, Seaworthy scans repositories for missing or outdated lockfiles alongside other dependency-hygiene signals.