Estimating a Dependency Change Before an Agent Installs

The procedure is the same in every ecosystem:

1. Start from a clean tree with the committed lockfile.
2. Run the package manager's dry-run resolution and capture the would-be lockfile to a separate path.
3. Diff the two files.
4. Classify each changed package as direct (listed in the manifest) or transitive (pulled in).
5. Record the version delta: patch, minor or major.

For npm you can write the candidate lockfile without touching the working one:

# resolve into a scratch copy, then diff
cp package-lock.json /tmp/lock.before.json
npm install --package-lock-only --ignore-scripts
cp package-lock.json /tmp/lock.after.json
git checkout -- package-lock.json
diff -u /tmp/lock.before.json /tmp/lock.after.json | grep '^[+-]' | wc -l

The --package-lock-only flag updates only the lockfile and skips lifecycle scripts, so nothing executes. For Python, poetry lock --no-update style workflows or a pip-compile run into a scratch output achieve the same thing, and Pants users generate lockfiles explicitly with pants generate-lockfiles (Pants lockfile docs).

The classification step is where teams usually skip work and pay for it later. Count four numbers per run:

A package manager will happily pull in a patched transitive version when you widen a direct range. A pinned direct dependency can hold a transitive package at a version that has a known vulnerability, and widening to a caret range can allow the patched version through instead (HeroDevs on transitive resolution). So a lockfile diff showing "one direct package changed" can still be twenty entries of churn. Count them.

One more thing worth knowing before you trust the count: passing a test in the agent's own workflow is weaker evidence than it looks. An analysis of repair-agent validation found that 46.0% of positive comparable validation events carried no bug-discriminating information, and 23.8% of baseline rollouts closed on evidence of that kind (Xu and Wu, validation evidence in repair agents). Apply the same skepticism to "the agent ran the test suite and it passed" after a dependency bump.

Reviewer time is not linear in a useful way, but it does have measured anchors. An analysis of more than 50,000 pull requests across 200+ engineering teams reports that each additional 100 lines changed adds about 25 minutes of review time, that defect detection falls from 87% for 1 to 100 line changes to 28% above 1,000 lines, and that PRs over 1,000 lines have roughly 70% lower defect detection than smaller ones (the PR size study). Those are the study's own numbers, not universal constants, but they give you a shape: cost rises roughly linearly and quality falls faster.

Your review rate should come from your own history. Two ways to measure it:

• Per changed package. Take your last ten dependency-only pull requests, note the number of changed lockfile entries and the time from first review request to approval. Divide total minutes by total changed packages. If ten PRs covered 240 changed packages and took 600 reviewer minutes, your rate is 2.5 minutes per changed package.
• Per 100 diff lines. Use the 25 minute figure from the study above as a starting prior and overwrite it with your own median.

Then the estimate is one multiplication:

expected_reviewer_minutes = changed_packages * minutes_per_changed_package

A worked example. A dry run shows 4 direct packages changed and 31 transitive packages changed, so 35 changed entries. At a measured rate of 2.5 minutes per changed package, that is about 88 minutes, so plan for roughly two reviews rather than one. The same diff in raw lockfile lines is often several hundred, because each entry carries an integrity hash and resolved URL; if the diff is 900 lines, the 25 minutes per 100 lines prior puts the estimate at 225 minutes. The two methods disagree by a factor of more than two, which is itself informative: line counts in lockfiles are noisy, so use changed packages as the primary estimate and line count only for splitting decisions.

Add a fixed overhead for the run itself. A clean install and test cycle is usually 5 to 20 minutes of wall clock, and the agent's own iteration should be bounded. The estimate you present to whoever approves the task is reviewer minutes plus bounded run time, not "it's just a version bump."

Here is the decision rule I recommend, and it is deliberately simple enough to put in a prompt.

Split a dependency task into two runs when either condition holds:

• Size: the dry-run diff changes more than 20 lockfile entries, or more than 400 diff lines.
• Blast radius: any major version jump on a direct package, or two or more direct packages changing in the same run, or any added or removed package that is not a direct dependency.

When neither holds, run it as one task. When the rule fires, run one pass that updates direct dependencies only with transitive resolution frozen where the package manager allows it, verify, merge, and then run a second pass for the remaining transitive updates.

The 400 line threshold is not arbitrary. The PR size study places the best defect detection in the 200 to 400 line band, with 87% detection below 100 lines and a steep decline past 600 lines (the PR size study). A dependency change of 400 lines already sits at the top of the useful band, and 600 lines is past the point where reviewers stop catching things. The 20 entry threshold is the rough equivalent of 400 lines given that lockfile entries average several lines each; recalibrate it against your own diff sizes.

The blast radius clause is the more important half. Size tells you how much reading there is. Blast radius tells you how much can go wrong and how hard it will be to attribute a failure. If two direct packages change in one run and the test suite goes red, you have to bisect the dependency change to find which one. Split into two runs and each failure has one suspect.

There is also a workflow reason to keep runs isolated: an agent doing a dependency change wants a clean workspace with no half-finished feature edits, and git worktrees give you exactly that, multiple working directories attached to one repository (git-worktree documentation). One worktree for the dependency run, the feature worktree untouched, and a third for review if you want it (a practical worktree setup). Parallel agents each get their own workspace rather than fighting over one checkout (Laurent Kempé on worktrees for agents).

The estimate is only useful if it runs before the write. Put it in the same place as your other tool gates, where the agent is allowed to propose and the gate decides whether to execute (the preflight checks). A prompt fragment that works:

Before running any package install:
1. Run the resolution in dry-run mode into a scratch file. Do not modify the lockfile.
2. Diff scratch lockfile against the committed one.
3. Report: direct_changed, transitive_changed, major_jumps, added_removed, total_changed, diff_lines.
4. Compute expected_reviewer_minutes = total_changed * RATE, where RATE comes from team config.
5. If total_changed > 20 OR diff_lines > 400 OR major_jumps > 0 OR direct_changed > 1,
   stop and propose a two-run split instead of installing.
6. Otherwise install, run the full test suite, and paste the counts and the estimate into the PR description.

Two details make this robust. First, every number in the report must be produced by a command the agent actually ran, not generated from memory; structured output with explicit fields reduces the chance the model invents a count. Good prompt practice for structured and verifiable outputs is well documented (OpenAI prompt engineering guide). Second, the rate is configuration, not something the model should guess: store it in the repository next to your CI config.

If you want the agent's own reasoning about the diff to be cheaper or more consistent across runs, a single inference endpoint for the summarization step keeps the plumbing simple; Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible key at https://quantaintelligence.ai/inference, which is handy when the same preflight runs against different models over time.

For the split condition, resist the temptation to let the agent choose. A model that has been asked to install a package has an incentive to describe the change as small. Make the gate deterministic: the numbers come from a script, the threshold comparison happens in code, and the agent only reports the outcome. That mirrors why preflight checks exist at all, which is that most failures happen before execution, in the decision, not in the tool call.

Consider a Node project with a manifest that pins three direct dependencies exactly. The task: "update dependencies to pick up patches."

Dry run one. The lockfile diff shows 3 changed entries, 2 of them transitive, no major jumps, 140 diff lines. At 2.5 minutes per changed package that is about 8 minutes of review. The rule does not fire. Run it as one task, install, test, open one pull request with the counts in the description.

Dry run two. The same manifest but a wider range set, which lets the resolver move more. The diff shows 6 direct packages changed, 47 transitive, 2 major jumps, 1 added package, 1,300 diff lines. At 2.5 minutes per changed package, that is about 133 minutes of review, and at the line-count prior it is far worse. The rule fires twice over. Split: first run updates the direct packages with a frozen transitive set where possible (6 direct changes is still a big first run, so split again by package if the tests are shaky), verify and merge; second run takes the transitive churn. Each run lands under the thresholds, each failure has a small suspect set, and no single review exceeds the useful band.

The estimate also gives you something to say to stakeholders. "This is 53 packages and roughly two reviewer hours" is a decision. "It's just a version bump" is not.

If your team lacks the measurement history to set a rate, or you want the preflight built and calibrated rather than hand-rolled, that is the kind of thing a Quanta expert can do against your own repository history; the expert reads your context and hands back finished deliverables, including the script and the prompt fragment, at https://quantaintelligence.ai/agents.

• Counting raw diff lines as work. Every changed lockfile entry carries an integrity hash and a resolved URL, so a one version bump can be five or six diff lines. Count packages first.
• Treating npm install and npm ci as equivalent. npm ci installs exactly what the lockfile specifies and fails on a mismatch, which is why it is the recommended CI command (sbomify on drift detection). Use it to prove the dry-run result installs cleanly.
• Ignoring that patch bumps do not reach everything. An auto-merge bot only acts where a newer patch release exists for a direct dependency, and does nothing for deeply transitive packages, end-of-life libraries, or findings a scanner marks as having no fix available (Seal Security on patch auto-merge). Those are exactly the cases where the split rule matters.
• Letting the lockfile drift between estimate and install. If the tree changes after the dry run, your numbers are stale. Re-run the preflight immediately before the install.
• Assuming a green suite means the change is safe. Evidence quality is a separate question from evidence presence, as the repair-agent analysis shows (Xu and Wu). A suite that passes on the old and new code tells you less about a dependency change than you would like.

A useful sanity table for the decision: