Every large engineering org eventually wants the same thing: one view of every dependency across hundreds of repositories. Who uses lodash 4.17.20. Which services still pull in the bad Log4j. What breaks if the shared client library gets bumped. The market has answered that demand the same way for a decade — another scanning tool, another dashboard, another seat license. AI just collapsed the price of that answer to roughly zero. What it did not collapse is the judgment about which dependency actually matters to the business, and that distinction should change how you staff.
The Intern Test
A few weeks ago a thread on r/devops laid the problem out in its purest form: an org with hundreds of repos, an intern, and eight weeks to proof-of-concept org-wide dependency visibility. The question was which existing tools to start from. The replies named the usual suspects — Backstage, Dependency-Track, OWASP Dependency-Check, SBOM aggregation, Azure DevOps Advanced Security.
The most-repeated advice was not a tool recommendation. It was a warning: don't build a platform around this problem, because the maintenance and curation overhead becomes the real project. One commenter described the graveyard exactly — great metadata systems that slowly drift because ownership and update discipline become unclear.
That thread is the whole thesis in miniature. The scanning and graph-building layer is now intern-plus-AI work. An agent can walk hundreds of repos, parse the manifests and lockfiles, and emit a dependency graph in an afternoon. The thing that decays — the thing every reply warned about — is curation. Knowing which entries in the graph are load-bearing. That was never in the tool, and it still isn't.
Visibility Was Never the Bottleneck
If scanning solved the problem, Log4Shell would have been closed out in a quarter. The entire industry pointed every scanner it owned at Log4j in December 2021. Two years later, Veracode found that 38% of 38,278 applications across 3,866 orgs were still running vulnerable Log4j versions. Worse, 32% sat on Log4j 1.2.x — end-of-life since August 2015.
The underlying behavior explains it: 79% of the time, developers never update a third-party library after adding it to a codebase. And the single biggest predictor of slow remediation was not scanner coverage. Developers who lacked context on how a vulnerable library related to their application took more than seven months to fix half their backlog. Teams with that context fixed theirs in weeks.
Read that gap again. Seven-plus months versus weeks, and the variable was not tooling. It was integrated knowledge of the system — which call paths touch the library, what the upgrade breaks, who owns the blast radius. Every org in that dataset had visibility. The ones that remediated fast had people who understood what they were looking at.
The Scan Got Free and Less Trustworthy at the Same Time
AI agents now build dependency graphs for free — and they also pollute them. Endor Labs' State of Dependency Management 2025 analyzed 10,663 MCP server repositories plus AI dependency recommendations across PyPI, npm, Maven, and NuGet. The findings: AI coding agents import vulnerable and hallucinated dependencies at scale, 75% of MCP servers are built by individuals, 41% carry no license at all, and 82% touch sensitive APIs. Endor's recommendation is blunt — treat AI-generated code as untrusted third-party input.
The people using these tools already sense it. The 2025 DORA report puts AI adoption among software professionals at 90%, up 14 points year over year, with a median of two hours a day. More than 80% report productivity gains. And 30% trust the output "a little" or not at all. DORA's own framing: AI is "a supportive tool... rather than a full substitute for human judgment."
So the economics flipped in both directions at once. The access-rent layer — paying a vendor to tell you what is in your own repositories — is collapsing, because an agent does the inventory for free. The judgment layer got more valuable at the same moment, because the same agents that build the graph inject noise into it, and somebody has to know which edges are real and which ones matter.
The Upgrade Nobody Documented
A concrete instance from my own infrastructure. I run a set of production cron jobs on a Mac mini that depend on better-sqlite3, a native Node module compiled against a particular runtime ABI. A routine Homebrew update moved the default node from v22 to v26. Every job that touched the database started crash-looping, silently, until I noticed the output had stopped.
No scanner flags that. The dependency graph was accurate the whole time — better-sqlite3 was right there in the manifest, version pinned, zero CVEs. What broke was a relationship between a native module's ABI and a runtime version that no manifest expresses. The fix took five minutes because I knew the system. Someone without that context loses a day to it, and the scanner contributes zero useful minutes either way.
Now scale that to a 400-repo org and multiply by every undocumented coupling: the service that pins an old client because the new one changed retry semantics, the EOL logging library that looks scary but is unreachable from any network input, the "low" severity finding that sits directly on the auth path and is the actual emergency.
Staff for the Judgment, Not the Scan
Platform engineering spent 2025 taking stock of what AI changed about its own discipline. For dependency work, the honest ledger looks like this.
AI commoditized: repo crawling, manifest parsing, SBOM generation, graph assembly, CVE matching, even drafting the upgrade PR.
AI did not commoditize: knowing which transitive dependency carries business risk, which upgrade breaks the thing nobody wrote down, and which finding deserves this week's attention. That is integrated expertise — it accumulates in people who have lived inside the system, and it does not transfer through a dashboard.
Three practical moves follow. First, stop funding the visibility layer as if it were the hard part; an agent plus an intern can stand it up, exactly as that r/devops thread suspected. Second, assign senior, named owners to the graph's curation — the drift the commenters warned about is an ownership failure, not a tooling gap. Third, measure context instead of coverage: the Veracode data says the team that understands how a library relates to its application remediates an order of magnitude faster than the team that merely detects it.
The single pane of glass is finally cheap. It was never the product. The reading of it is, and the people who can read it are the ones worth paying for.
Top comments (0)