dooopSoftware · Quality · 12 min

How to Review Dependencies Suggested by Code Agents

Libraries suggested by AI must undergo review for necessity, provenance, technical fit, testing, and removal plan.

Published on September 6, 2026

CENTRAL THESIS

A dependency suggested by AI should not be added out of convenience. It should be added only when necessity, provenance, and maintenance are clear.

The review transforms an agent's suggestion into a verifiable technical decision, with tests, ownership, and a possible exit.

When a code agent suggests a library, the review should not only ask if the pull request got smaller or if local tests passed. Dependencies of AI-generated code need to be treated as architectural, maintenance, and risk decisions. Inclusion should proceed only when the team can justify why the package needs to be added now and how it will be verified later.

Adding a dependency changes the technical surface

A dependency rarely enters alone. It brings an origin, a license, a version history, a maintenance method, possible indirect dependencies, and a new surface within the product. There are plausible hypotheses for the agent's suggestion, such as local convenience or adherence to the received code context. But the review should not assume this makes the choice appropriate for the system.

The difference seems small in the pull request. One line in the configuration file. An import at the top of the file. Some ready-made calls instead of an internal implementation. But that line participates in the build, tests, deployment, security policy, and update routine.

This is the point engineering, quality, and product leadership need to make explicit: reviewing AI-suggested libraries is not generic distrust of automation. It is governance of AI-generated code applied where future cost is usually hidden.

The practical question is simple: if the agent had not suggested this library, would the team still choose to include it?

If the answer is "we don't know," the pull request is not ready yet.

This care relates to a broader discussion about software quality with AI, but here the focus is narrower: deciding if a specific dependency deserves to enter the product.

First criterion: the dependency must solve a necessary problem

The first review is not about security. It is about necessity.

Before checking provenance, license, or compatibility, the team must ask if that package needs to exist in the system. A library can be technically correct and still be a poor choice because it solves too small a problem to justify recurring maintenance.

The review should compare at least four alternatives:

native feature of the language or framework;
library already approved and present in the project;
small internal implementation with clear scope;
removal or simplification of the accessory functionality.

The dependency tends to make sense when it reduces real complexity, avoids a delicate implementation, or concentrates behavior that would be costly to maintain internally. It tends to be weak when it only saves a few lines, masks a poorly defined product decision, or imports a broad solution for a narrow need.

An operational criterion helps: if the pull request justification only says "the agent suggested it" or "it got simpler," the review should ask for a comparison. It does not need to become a long document. It can be a paragraph:

"The library was proposed to solve X. We evaluated Y, which already exists in the project but does not cover Z. Internal implementation would require maintaining A and B. Therefore, inclusion is acceptable if provenance and tests are approved."

This paragraph changes the conversation. The team stops approving a suggestion and starts approving a decision.

Second criterion: the package's provenance must be verifiable

The OWASP guidance on software supply chain recommends evaluating components and vendors before inclusion. Criteria include active maintenance, vulnerability handling, and compatibility of intended use with the license. The guidance also includes dependency inventory, vulnerability monitoring, and version control.

Provenance does not eliminate risk but allows reviewing the choice with minimal evidence.

In reviewing dependencies of AI-generated code, the package must have identifiable origin. The team must verify the repository, maintainers, license, version history, and minimal maintenance signals. It is also worth noting very similar names to known packages, recent ownership changes, and indirect dependencies that are hard to understand.

None of this guarantees absolute security. For this review, treat components, tools, and vendors involved in the build as items requiring provenance verification. The goal is to prevent a library from entering just because it appeared in a convincing agent response.

A good review comment can ask for specific evidence:

what is the official origin of the package;
where the source code is, when applicable;
which license governs its use;
when recent versions occurred;
which indirect dependencies will be added;
if there is an internal or already approved package with a similar function.

If these questions seem bureaucratic for a small change, perhaps the dependency is too small to justify inclusion. Local convenience should not create a permanent obligation for the team.

The review must also avoid a common mistake: confusing presence in public examples with reliable provenance. Do not assume names, combinations, and APIs suggested by the agent are correct without verification. The package must exist, be the right package, and make sense for that product.

Third criterion: the technical fit must not create invisible debt

Even when the library is necessary and verifiable, technical fit still needs evaluation.

The question here is not "does it work on the machine of the person who opened the pull request?" The question is: does it work in the product environment, with the versions, policies, and restrictions the team actually operates?

The review should observe compatibility with runtime, language, framework, packaging, license policy, internal standards, build, tests, and deployment. It should also consider the size of the imported surface. In the review, importing an extensive chain for a simple need should be treated as a risk.

Treat as invisible debt what does not appear in the user story but may affect updates, versions, alerts, runtime environment, or future package removal.

This point is especially relevant in reviewing pull requests with AI because the agent's suggestion depends on the context it received. If that context does not include the team's dependency policy, versioning strategy, or deployment restrictions, the suggestion may be coherent in code but wrong in operation.

An objective way to review fit is to ask the pull request to declare usage limits:

where the library will be called;
which functions will be used;
which parts should not be used;
which version will be fixed or controlled;
which internal module will be responsible for isolating the package.

Isolating the dependency behind a function or internal module is usually more prudent than spreading direct calls throughout the product. If the team needs to replace the library later, the change is less widespread. It is not a universal rule but a good pattern when the dependency enters to solve a specific behavior.

Fourth criterion: relevant behavior must be testable

Testing the dependency does not mean testing the entire library. It means testing the product behavior that depends on it.

If the package formats data, tests should cover the formats that matter to the product. If it validates user input, tests should cover accepted, rejected, and ambiguous inputs. If it changes serialization, authentication, file reading, or integration with another service, tests should verify the effect on the real flow.

DORA recommends testing throughout development, combining automation and manual activities such as exploration and usability, as well as maintaining and reviewing test suites. This recommendation does not resolve the decision about dependencies but reinforces a useful discipline: quality should not be pushed to a later stage.

In the case of AI-suggested libraries, the team should be suspicious of two weak evidences:

"the agent said it finished";
"it passed once on local test."

Anthropic distinguishes the agent's execution trajectory from the effective result in the environment. A message saying the task finished is not enough to prove the result. This distinction is valuable here: the agent may have completed the change, but the team still needs to verify the dependency's effect on the product.

The acceptance criterion should be written in terms of observable behavior. For example: "when receiving inputs with punctuation, spaces, and common variations, the form must normalize the value before saving." This criterion is better than "use library X for normalization." The library is a means. The behavior is the commitment.

To deepen the testing part without mixing topics, it is worth connecting this review to the process described in how to test AI-generated code. The question of this article, however, remains: does the proposed dependency allow verifying what really matters?

Fifth criterion: there must be a removal or replacement path

Approving a dependency must foresee scenarios where it no longer serves the product, such as license change, compatibility break, maintenance abandonment, undesired behavior, or future functionality simplification.

Therefore, approval must include a simple rollback or replacement plan. It does not need to be extensive. It must answer:

who monitors updates and relevant alerts;
how the version will be controlled;
where the library is encapsulated;
which tests indicate behavior break;
what alternative exists if removal is necessary.

The Google SRE chapter on gradual rollouts addresses evaluating a change on a portion of traffic before expanding exposure and distinguishes releasing code from activating features. For dependencies, the application is careful: when the change affects visible behavior or operational risk, it may make sense to separate technical inclusion, activation, and usage expansion by configuration.

This will not be necessary for every small library. But the distinction is useful. Merging code does not need to mean immediately exposing the entire product to new behavior.

The central point is responsibility. A dependency without technical owner tends to be left out of review routines until it generates unplanned maintenance.

Checklist for reviewing dependencies suggested by code agents

Use this checklist as a filter before approving inclusion. It does not promise to eliminate risks. It makes the decision more explicit and verifiable.

Necessity

Does the dependency solve a problem that cannot be addressed by native code, an already approved library, or a small internal implementation?

Approve when there is explicit justification for not using an existing alternative. Reject when the dependency only reduces a few lines of code without reducing risk or complexity.

Provenance

Are the package origin, maintainers, license, repository, and version history verifiable?

Approve when the team can identify source, license, and minimal maintenance signals. Reject when the package has unclear origin, a name similar to a known package, or uncertain maintenance.

Scope

Does the library do only what the product needs or bring disproportionate functionalities and indirect dependencies?

Approve when the imported scope is compatible with the problem solved. Reject when a small need depends on a broad and hard-to-audit chain.

Testing

Can the critical behavior of the dependency be verified by automated tests and manual review when necessary?

Approve when there are test cases for flows that can break the product. Reject when the team accepts the library because the agent said the task finished or because the local test passed once.

Maintenance

Is it clear who monitors updates, alerts, compatibility breaks, and possible removal?

Approve when the dependency has a technical owner and review rule. Reject when the library enters without responsible party, without version control, or without a replacement path.

This checklist also helps separate this topic from a general code review. To discuss readability, intention, coverage, and coherence of the pull request as a whole, the article on how to review AI-generated code is more appropriate.

Fictional example: when to reject a library suggested by the agent

Imagine a fictional case. An agent receives the task to adjust a registration form to accept CPF and CNPJ entered with or without punctuation. It suggests an external formatting and validation library. The pull request is short. Local tests pass. The change seems harmless.

In the review, the team applies the criteria.

First, necessity. The project already has an internal utility to normalize documents, used in other forms. It does not cover a specific variation of spaces before and after the value, but the adjustment would be small and testable. The new library, therefore, does not solve a problem the existing code cannot solve.

Second, provenance. The package origin is verifiable, but the review finds indirect dependencies that would not be used by the product. There is no evidence that this additional scope benefits the task.

Third, technical fit. The library offers formatting, validation, and input masks. The product only needs to normalize the value before saving. Importing the entire package would increase maintenance surface for a narrow need.

Fourth, testing. Relevant scenarios can be covered with automated tests on the internal utility: input with punctuation, without punctuation, with spaces, with invalid characters, and empty fields. It is not necessary to depend on the library to make behavior verifiable.

Fifth, maintenance. Since there is already an internal module responsible for normalization, including a new library would create two paths to solve the same problem.

The decision, in this fictional example, is to reject the dependency suggested by the agent, adjust the existing utility, and record in the pull request the acceptance rule: the form must normalize documents in the expected formats before saving, without introducing a new external dependency. The expected effect is to reduce maintenance surface, but this must be monitored in tests and subsequent reviews, not assumed as an automatic result.

This rejection is not resistance to AI. It is a team using AI without transferring to it the authority to change the product architecture.

Before including a dependency suggested by a code agent, require a short justification with four answers: what problem it solves, why existing code does not solve it, what is the package provenance, and who will be responsible for update, removal, or replacement.

If you want to discuss this decision in your company context, talk to dooop.

Sources

To continue this reading

How to investigate quality drop after changing a model

NEXT DECISION

Discuss application in the company

Conversation about the software company context

Content by dooop. Registration allows relating this topic to the reader's journey and tracking interest in the subject.