Your AI assistant won't save you from a missing lockfile

Your AI assistant won't save you from a missing lockfile

I keep seeing the same pattern in code reviews. A developer asks an AI assistant to add a library, the assistant writes a clean npm install some-package or pip install some-package line, and everyone moves on. The code works on that person's machine. Then CI fails, or worse, it succeeds with a different version than anyone expected. The culprit is almost always the same: no lockfile, or a lockfile nobody updated.

This is not a small thing. A lockfile is the only part of your dependency setup that records exactly what you shipped. package.json says you want "approximately version 4.2.0." package-lock.json says you actually got 4.2.7, with these exact transitive dependencies, from this exact registry. Those are very different promises.

AI assistants are optimized for the happy path

When you ask an AI coding assistant to add a dependency, it optimizes for making your code run. It does not reliably check whether your repo has a lockfile committed, whether that lockfile is current, or whether your CI uses npm ci versus npm install. It will happily generate a requirements.txt edit without generating a requirements.lock or a poetry.lock. It will add an import and a version range and call it done.

That is not a reason to ban AI assistants. It is a reason to stop treating them as a substitute for dependency hygiene. They are autocomplete with opinions, not a supply chain auditor.

The three failure modes I see most

1. No lockfile at all. The repo has a manifest and nothing else. Every install resolves fresh. Two developers on the same team can get different transitive trees on the same day. Reproducible builds are a story you tell in a slide deck.

2. A lockfile that is not committed. It exists locally, so the person who ran the install is fine. Everyone else, including CI, resolves from scratch. This is the worst version because it looks like hygiene while providing none.

3. A lockfile that is stale after a manifest edit. Someone bumps a version range in package.json, runs the tests, and never runs an install to refresh the lock. The lockfile still pins the old tree. CI with npm ci either fails or, worse, quietly installs something inconsistent with the manifest.

Here is the pattern I want you to recognize. An AI assistant produces the first block. You should produce the second.

# What the assistant often suggests
npm install left-pad

# What actually keeps your build honest
npm install left-pad
# then commit BOTH files
git add package.json package-lock.json
git commit -m "add left-pad and refresh lockfile"

For Python, the same idea with a tool that separates direct deps from the resolved set:

# requirements.in holds direct dependencies
pip-compile requirements.in
# commit requirements.txt, which is the lockfile
git add requirements.in requirements.txt

The tool does not matter. What matters is that the resolved set is written down and reviewed.

Why CI should use the lockfile, not ignore it

If your CI runs npm install, it will happily update the lockfile in the runner and then throw that work away. You get a green build that proves nothing about what your users will get. Use npm ci, which refuses to proceed when the lockfile and manifest disagree. Use pip install --require-hashes -r requirements.txt or poetry install --no-update depending on your stack. A failing build because of a stale lockfile is a gift. It is the cheapest possible time to find out.

I will go further. A repo without a committed lockfile is not ready for production, no matter how clean the code looks. This is not a controversial position. It is the same category of mistake as committing secrets or skipping migrations. It is boring, and that is the point.

What to do when your AI assistant adds a dependency

Treat the assistant's output as a draft of the manifest change only. Then:

1. Run the install command yourself so the lockfile updates.
2. Read the lockfile diff. New transitive dependencies are the interesting part, not the one you asked for.
3. Commit both files together. Never let them drift.
4. Make sure CI uses the frozen or clean install mode.
5. Add a check that fails when the lockfile is out of date, so this does not depend on anyone remembering.

That last step is the one people skip. A pre-commit hook or a CI job that runs the install in check mode turns a habit into a guarantee. Habits decay. Checks do not.

The broader lesson is that AI assistants make the easy part easier. Writing the import statement was never the hard part. Knowing what you actually deployed is the hard part, and no assistant will do that for you unless you ask, and sometimes not even then.

If you want a second set of eyes on dependency and lockfile practices across your repos, Seaworthy reviews exactly this kind of gap.