Make the Governed Path the Fastest Path for AI-Assisted Engineering
Eric Thompson
October 21, 2026
Share post:
AI is the junior engineer on your team now, and junior engineers add unvetted open source dependencies. A coding assistant proposes an import, a developer accepts it, and a package no one evaluated lands in the build along with every transitive dependency it brings. The review step that used to sit between "someone wants this library" and "this library shipped" was built for people choosing packages one at a time. It was never designed for a teammate that suggests them at machine speed.
That makes dependency intake an engineering leadership decision, and a speed decision first. A governed intake path works only when developers, and the assistants working beside them, would choose it over the quiet alternative: the public registry, one install command away. Make the governed path the fastest path, and governance stops landing on your team as unplanned work. Leave it slower, and the team will route around it without anyone deciding to.
Key takeaways
AI coding assistants now choose open source dependencies inside the editor, including packages and versions that do not exist.
A governed intake path wins only when it is the default and the quickest route for developers and their assistants.
The engineering leader owns four decisions: where installs resolve by default, who carries the hardening work, how fast exceptions move, and when end-of-life upgrades get scheduled.
Running a governed source is permanent operational work. Decide whether to carry it in-house or consume it as a hardened input, and price it honestly either way.
AI-assisted teams that leave intake ungoverned will spend 2027 on rework they could have avoided.
How AI coding assistants changed who chooses your dependencies
Before assistants, a new dependency usually started with a person. Someone read the docs, compared two libraries, and opened a pull request a reviewer could question. The process was deliberate, and it put a human decision at the point of entry.
Assistants move that decision into a suggestion. Researchers at the University of Texas at San Antonio, the University of Oklahoma, and Virginia Tech generated 576,000 code samples from 16 code-generating models and found that at least 5.2% of packages recommended by commercial models, and 21.7% of those recommended by open source models, did not exist. They logged 205,474 unique hallucinated package names.1 Anyone can register one of those names on a public registry and wait for a developer to accept the suggestion, the pattern now called slopsquatting.
Upgrades carry the same problem. Sonatype analyzed 36,870 dependency upgrade recommendations from large language models across Maven, npm, PyPI, and NuGet and found that 27.76% referenced versions that do not exist.2 At the same time, the volume of hostile packages keeps climbing: Sonatype counted 454,600 new malicious packages across npm, PyPI, Maven Central, NuGet, and Hugging Face in 2025.3
Taken together, the evidence says the decision point moved. The package gets chosen inside the editor, at the moment a developer accepts a suggestion, and any control further down the line is reviewing a choice that has already been made. OWASP now ranks Software Supply Chain Failures third in its Top 10 for 2025, and the category topped the project's community survey.4 We covered the governance gap this opens in who governs the dependencies your AI assistant picks.
Why mandates lose to the quiet alternative
Every engineering team has a quiet alternative. When the approved path means filing a ticket and waiting two days, developers take the public registry. Nobody is being reckless. They have a sprint commitment and a tool that makes the unapproved choice frictionless.
That is why an intake policy announced from the top lands badly. To the team, a new rule with no fast path is unplanned work, and engineering leaders are right to push back on those terms. Security leaders who argue for a hard block have a fair point too: a gate that stops a bad package beats a guideline that asks nicely. Both sides are describing the same failure. A control that slows the team becomes a control the team learns to avoid. The tension between security and engineering over open source often starts here.
The way through is to measure governed intake the way engineering already measures everything else. Growth and safety were never a trade-off; engineering has always measured productivity and quality together. You can ship a lot of broken software quickly, and no customer thanks you for it. Intake belongs in the same measurement.
What does an engineering leader have to decide?
Four decisions make the governed path the fastest one. They run in this order, because each depends on the one before it.
1: Where an install resolves by default. Point pip, npm, and Maven at an approved source through the artifact repository your team already runs, so the commands developers type today return vetted open source components. Coding assistants that run those same commands inherit the same default. When the governed source is the default, choosing it costs the developer nothing.
2: Who carries the hardening work. A governed source needs CVE remediation, malware scanning, version upgrades, source-attested builds, and breaking changes integrated before they reach your team. That is a standing team's worth of work, and it never finishes. The honest question is whether your team carries it in-house or consumes it as a hardened input. We laid out everything that comes with building your own private artifact registry for teams weighing the first option.
3: How fast an exception moves. Assistants will suggest packages your approved set does not include yet. Track the time to answer an exception request as an engineering metric and publish it to the team. When a request takes longer than a developer's patience on a deadline, the public registry wins again.
4: When end-of-life upgrades happen. Dependency end-of-life and the breaking-change upgrade that follows belong on the roadmap as scheduled decisions. Left unscheduled, they arrive as an emergency in the middle of a release.
Bring these four to your security counterpart as a shared plan. Security decides what qualifies for the approved set; engineering owns how quickly the approved path runs and how exceptions get handled. Each team ends up accountable for the part it controls.
What it costs to run a governed intake path
Name the cost first. Running your own governed source means building every component you serve, tracking advisories across every ecosystem your teams use, testing each upgrade against your code, and staffing all of it permanently. A leader who sells that to the team as a one-time setup task is not being straight with the people who will run it.
The return is work that never has to happen. Every package vetted at intake is a finding nobody triages later, a rework ticket nobody files mid-sprint, and a release nobody holds for a dependency fix. Those costs compound as AI speeds up delivery, which we walked through in four business costs that can follow AI-accelerated delivery.
If you consume the hardening work instead of building it, hold the provider to the bar you would set for your own team. ActiveState, for example, builds open source from source in a SLSA Level 3 build environment, delivers remediated components on contractual SLAs of 5 business days for critical CVEs, 10 business days for high, and 30 business days for all others once a fix is available upstream, and serves them through native pip, npm, and Maven commands and the artifact managers teams already run. Whichever route you take, the questions stay the same: who does the work, on what clock, and does the developer notice?
What happens to teams that leave intake ungoverned?
AI-assisted teams that leave intake ungoverned will spend 2027 on rework they could have avoided. Every accepted suggestion adds to a dependency set nobody chose on purpose. Each later CVE, malicious package removal, or forced upgrade in that set lands as unplanned work in a sprint that was already committed, and the volume grows with every assistant your team adopts. Even worse are the CVEs and malware that go unresolved.
The human role on the team moves up a level, to architect, product thinker, and QA eye. That role includes deciding what the junior engineer (AI) is allowed to pull in, and making the right choice the easy one.
This quarter, run one test with your team: ask a developer to add a new package the way they would on a deadline, with an assistant open, and time the approved path against the public registry. If the public registry wins, change the default before you write another policy. Make the governed path the fastest path, and the team will choose it without being told.
Eric Thompson is VP of Engineering at ActiveState. He has spent more than 20 years building and scaling enterprise software and developer-tools organizations. Previously he was VP of Engineering at Kion, where his team launched an MCP-based AI assistant and he moved the organization to AI-first development, and Director of Engineering at Puppet, where he led part of the engineering organization through two acquisitions.
Footnotes
Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath, and Murtuza Jadliwala, "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs," 34th USENIX Security Symposium, August 2025. https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen
What does "make the governed path the fastest path" mean?
It means the approved way to add an open source dependency is also the quickest way for developers and their AI coding assistants. When installs resolve to a vetted source by default and exception requests get quick answers, teams choose governed intake because it saves them time.
Why do AI coding assistants change open source dependency governance?
Assistants suggest packages and versions inside the editor, or in a huge block of generated code, so the choice happens the moment a developer accepts a suggestion. Peer-reviewed research presented at USENIX Security 2025 found commercial models recommended nonexistent packages at least 5.2% of the time, and anyone can register those names on a public registry.
Should engineering teams build their own governed package source?
They can, and it is a permanent operational commitment: building from source, remediating CVEs, scanning for malware, and integrating breaking changes for every ecosystem in use. The useful decision is whether to carry that work in-house or consume it as a hardened input, with the cost stated up front.
Does governed intake replace dependency scanners?
Scanning stays as the backstop. Governed intake decides what enters the build, so scanners have less to find and the team spends less time triaging findings.
Who owns open source intake, security or engineering?
Both teams own a part. Security decides what qualifies for the approved set, and engineering owns how quickly the approved path runs and how exceptions are handled.
