How to Read a Dependency Change an Agent Made

Lockfiles are machine-written and heavily reformatted, so line counts mislead in both directions. A reordering can produce hundreds of changed lines with zero semantic effect. A genuine bump can produce twenty changed lines that add a package with an install script.

Work in records, not lines. For package-lock.json, filter the diff for the lines that name a package and version:

git diff origin/main...HEAD -- package-lock.json \
  | grep -E '^\+.*"resolved"' \
  | sort -u | wc -l

The number that comes back is your review budget. A worked example: suppose the diff shows 212 added lines but only 9 distinct new resolved URLs. You have nine packages to check, not two hundred lines. Set a threshold in your team's review guide, say more than five new resolved packages for a change that claims to add one library, and treat crossing it as a signal to ask the agent to split the change or explain the fan-out.

Four things in a lockfile diff deserve a look every time:

The integrity hash is the strongest single control you have. It pins the exact artifact, and if a version you already had suddenly shows a different hash, the package was republished or tampered with. GitHub's own guidance on reviewing AI-generated code tells reviewers to be vigilant about new packages and to verify that suggested dependencies exist and are maintained, which starts with reading where they resolve from, per GitHub's review guide.

Registry strings are also where slopsquatting shows up. An attacker registers a name that a model might invent, and if the lockfile entry points at a package whose README, owner or first publish date does not match the library the agent described, you have caught it before npm install runs. Metacto's review standards treat dependency provenance as a pre-screening standard for exactly this reason: confirm the package exists on the canonical registry, matches the intended library, is needed at all, and is pinned through the lockfile.

A lockfile tells you what is installed. The resolved tree tells you why. npm ls <package> prints the path from your project to the package, so you can see whether it came from the agent's direct addition or from something else entirely, and the command exits non-zero when the installed tree does not match what the manifest says should be there, as this walkthrough of npm ls explains.

Two outputs matter more than the rest. First, duplicates: if npm ls prints two entries for the same package at different versions, your bundle now carries both, and one of them may be the version with the known problem. Second, paths you did not expect: a package arriving under a build tool you never touched is a change to your toolchain, not to your feature.

For Python, pip show <package> gives you the version, the location, the license line and, critically, the Required-by field, which lists the installed packages that depend on it. pipdeptree --reverse --packages <name> draws the same picture as a tree.

Depth deserves a sanity check of its own. A survey of npm dependency trees compared npm install --dry-run counts across libraries and found enormous variance: some state libraries add a single package, a web framework added 57, and a full application framework added roughly 524. The number is not a verdict on quality, but it is a verdict on how much you are about to audit, and it belongs in the pull request description when it is large.

Here is a rule you can apply without judgment calls, which is what makes it usable on a busy review queue. Suppose the agent's direct addition is one package, and the resolved tree shows it adds more than ten transitive packages for a single utility function. Ask the agent one question: what does the new package do that the standard library or an existing dependency does not?

If the answer is a one-line operation the platform now handles natively, reject the dependency and ask for the inline version. If the answer is a real capability such as a parser, a database driver or an image pipeline, accept it and record the tree size so the next reviewer inherits your analysis. The economics are simple: the time to audit ten packages once, at the moment someone chose them, is far smaller than the time to audit them after an incident when nobody remembers the choice.

The same rule handles the second copy of a package. If npm ls shows two versions of the same library, either unify them with an override in the manifest or accept the duplication with a written reason. A guide to npm overrides documents the syntax, including the dot key that targets the parent package itself and its children separately, and notes that overrides are meant for exactly two jobs: fixing a vulnerable transitive dependency and aligning versions across packages.

License review is the step most often skipped, and it is the one that produces the least recoverable problems, because a license obligation does not go away when you delete the code later. GitHub's review guidance names the concrete failure: introducing a dependency that is incompatible with your project's license, with AGPL in an MIT project and packages with no declared license given as the examples, per GitHub's review guide.

Read the license of the direct addition first, then walk the new children. The children matter because copyleft obligations propagate through the dependency graph, and the agent almost never mentions them. A practical pass:

# Node: every installed package's declared license, sorted by frequency
npx license-checker --summary

# Python: license line for the package you are reviewing
pip show <package-name> | grep -i license

Then apply a three-tier rule and write it into your review template so nobody has to renegotiate it per pull request:

Two details catch people. A package with no declared license is not public domain; default copyright means you have no grant to redistribute it. And a license field that does not match the LICENSE file in the repository is a question for the maintainer, not something to resolve by assuming the friendlier of the two applies.

This is the part of a dependency change that executes code on your machine and your CI runners without any of your own code being called. preinstall, install and postinstall scripts in package.json run during npm install, and their equivalents in Python (setup.py with a custom install command, build backend hooks in pyproject.toml) run when a package is built from source.

The word "before" is the whole problem. A malicious or merely careless install script runs with whatever credentials the install step has: your registry token, your CI secrets if they are in scope, your network position inside the build environment. A collection of npm security best practices puts supply chain hardening, safe-by-default package manager options and deterministic dependency resolution in scope for this reason, and the package manager gives you a blunt control: skip the scripts.

# Read what the package would run, without running it
node -e "console.log(require('./node_modules/<pkg>/package.json').scripts || {})"

# Or inspect the tarball without installing it
npm pack <package-name> --dry-run

# Install with lifecycle scripts disabled
npm install --ignore-scripts

Disabling lifecycle scripts for a single CI job is a cheap way to find out whether your build actually needs them. Most projects do not: the packages that legitimately need a postinstall are the ones with native addons that compile at install time, and those will fail loudly rather than silently. If the build breaks with --ignore-scripts, you now have a short, evidence-based list of packages that need scripts, and everything else can stay disabled.

For a package whose script you decide to keep, read it line by line. Look for network calls (curl, wget, fetch against an unfamiliar host), reads of environment variables that look like secrets, writes outside the package directory, and shells invoked with a string built from anything downloaded. A script that downloads a binary and executes it is doing nothing wrong in principle and everything worth a second reader in practice.

A vendored dependency is source copied into your repository rather than fetched by a package manager. It appears in a review as a large block of new files, often thousands of lines, and the reviewer's instinct is to skim and approve. That instinct is the vulnerability.

The narrow question for a vendored drop is not "is this good code" but "is this the code the agent said it is." Three checks answer it. First, compare a hash: if the agent claims the source came from a tagged release, compute a checksum of the vendored tree and compare it with the upstream tarball for that tag. Second, read the license file in the vendored directory and confirm it matches what your policy expects, because vendoring does not change the license, it only changes who has to comply with it. Third, list what was removed: vendored code is often trimmed, and a trimmed copy is a fork you now maintain, which should be a stated decision and not a side effect.

Then look for capability the vendor does not need. A vendored library that opens sockets, spawns processes or writes to the filesystem, when your use of it is a string formatting function, is a larger attack surface than the feature justifies. Ask for the unused modules to be deleted or for the dependency to be fetched normally with an integrity hash. The lockfile is a control you lose the moment code is copied in by hand.

Reviewing dependency changes is repetitive, which makes it a good candidate for automation, and a poor candidate for full delegation. Two useful anchors keep the split sane. Google's review standard says reviewers should approve a change once it definitely improves overall code health, even if it is not perfect, which argues for automating the counting, hashing and license lookups and reserving human attention for the judgment calls, per Google's review standard. And the same guide's list of what to look for names design and complexity as the things reviewers weigh most, which is precisely what a machine cannot assess about a vendored drop, per what to look for in a code review.

The judgment calls that stay human are predictable. Is this dependency needed at all, or does the codebase already have the capability? Is the maintainer real and reachable? Does the license obligation fit how we distribute the product? And for install scripts, is the network call this script makes consistent with what this package claims to do? Those four questions are cheap to answer and expensive to skip, and a checklist in the pull request body makes them visible to the next reviewer. Thoughtbot's guidance on reviewing AI-generated pull requests makes the same point about existing code: agents frequently reimplement something the codebase already has, so the first question about a new dependency is whether an existing one already covers the need.

For teams that want the mechanical pass done before a human opens the file, the workflow fits a coding agent that already has the commands above in its skill set. Quanta Skills is the library those agents install from, and a dependency-review skill can run the lockfile count, the tree query and the license summary and hand back a table like the ones above for a person to sign off.