AI Coding May Change Which Dependencies We Keep
Inlining small utilities can reduce package exposure, but it creates maintenance work. Here is why I am focusing on the tools coding agents trust.
I expect coding agents to change which dependencies teams choose to keep. Small utilities and simple UI components are plausible candidates for code maintained inside the application. That is a prediction about development habits, and it could be wrong.
It also explains part of my interest in extension security. The agent that helps remove a package still depends on tools, plugins and reference material. Those deserve review too.
The cost moves into your repository
Importing a package buys access to someone else's maintenance. You inherit their release process and whatever dependencies your chosen version brings with it. Whether installation scripts run depends on the package manager, configuration and packages involved.
An agent may be able to implement a small feature locally after reading reference code. That removes a package update path, but your team now owns the implementation. You need tests and a way to discover bugs in the copied or adapted logic. Source licences and attribution requirements still apply.
I would consider this for a short formatting helper. I would be much more reluctant to do it for cryptography or a protocol implementation whose maintainers spend years dealing with edge cases. Fewer entries in a lockfile do not establish lower risk by themselves.
Count the trust you retain
Suppose a project reduces its dependency count from 1,000 to 50. That is a useful prompt for review, but it does not mean 950 distinct maintainers or executable install scripts disappeared. Packages can share publishers; a single remaining package can carry substantial access and complexity.
The practical question is which update channels were removed and who now maintains the replacement code. An SBOM should still describe incorporated third-party components where applicable. Hiding them by copying source would make the inventory less useful.
Dependency scanners continue to serve a real need. Even a project with a small lockfile needs to track vulnerabilities and compromised releases. I am making a product bet about where I can contribute, rather than claiming those tools are becoming unnecessary.
The agent's tools need their own review
A coding assistant may consult a remote MCP service, use an editor extension or run a local helper before it writes a line of application code. Each integration changes what can read the project or influence the output.
For a local executable, inspect the artifact and its permissions. For a remote service, establish what data it receives and how access is controlled. Pinning a client package does not freeze the server's behaviour.
RiskyPlugins focuses on these extension and plugin records. The hosted MCP endpoint lets an assistant consult findings during its work. The caller still needs to decide what evidence is sufficient before installing or running anything.
I want to test this prediction against actual projects: which packages teams remove, whether they can maintain the replacements, and which new integrations their agents introduce. A smaller lockfile would be one observation. Fewer incidents and manageable maintenance would be the more useful result.