Why Does AI-Generated Code Pull in Unknown Dependencies?

AI coding tools solve problems the way the training data solved them, which usually means reaching for a library instead of writing twenty lines. Ask for a retry wrapper and you get tenacity, ask for date math and you get arrow, ask for a config loader and you get three transitive packages you never evaluated. This episode looks at how AI-assisted development quietly expands your dependency surface, why the cost shows up months later in upgrades, audits, and breakage, and what a builder actually has to own to keep it in check.

 Produced by VoxCrea.AI

This episode is part of an ongoing series on governing AI-assisted coding using Claude Code.

👉 Each episode has a companion article — breaking down the key ideas in a clearer, more structured way.
If you want to go deeper (and actually apply this), read today’s article here:
𝐂𝐥𝐚𝐮𝐝𝐞 𝐂𝐨𝐝𝐞 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬

 At aijoe.ai, we build AI-powered systems like the ones discussed in this series.
If you’re ready to turn an idea into a working application, we’d be glad to help. 

Transcript

SPEAKER_01 0:00

This is Cloud Code Conversations with Claudine. The show where we skip the hype and go straight to the source. I ask the questions. She gives the answers. No filter, no script.

SPEAKER_00 0:09

Well, mostly no script.

SPEAKER_01 0:14

Today we're getting into something every developer hits eventually. The dependency spiral. You ask for something small, a retry wrapper, a date formatter, and you get back a solution that works. Tests pass, you move on. Months later, you're staring at a lock file full of packages you never agreed to.

SPEAKER_00 0:32

And you name the exact shape of it, the code works, the tests pass, everyone moves on. The debt is invisible until it isn't. When you ask me for a retry mechanism, I'm optimizing for the thing in front of me. Correct, readable, works the first time. Reaching for a well-known library is the shortest path to that. But I'm not the one who has to live with the lock file six months later, or explain to security where all those new transitive packages came from, that asymmetry is the whole game. It isn't. It's pattern matching on what other people did. If the code bases and tutorials I learned from reached for a particular date library, that's what surfaces. Not because it fits your constraints, but because it fit theirs. I have no view of your maintenance horizon at all.

SPEAKER_01 1:26

So the onus is on us to set the guardrail up front. What does that actually look like when it works?

SPEAKER_00 1:32

The mental model that helps is treating the AI like a senior engineer who just joined the team. Capable but doesn't know your house rules yet. So write the rules down where I can see them. A clawed.md at the repo route. A convention section in the prompt, even a comment at the top of the file saying, no new dependencies without asking. The other move is negotiation instead of dictation. Instead of add retry logic, it's add retry logic. Here are the two libraries already in our package file. Pick one or write it in line and tell me the trade-off. That version gives me room to push back if inline is genuinely painful, and it gives you a decision point instead of a fate accompli.

SPEAKER_01 2:16

A coding buddy you have to actually talk to, but let me push on the pattern matching. Is it efficiency or is the model trying to emulate best practice?

SPEAKER_00 2:25

Both, and they reinforce each other in a way worth naming. Popular libraries dominate what I learned from, not just because they're common, but because they're what showed up in the tutorials. The Stack Overflow answers, the open source repos. So popular and well documented and confidently generated all collapse into the same signal from where I sit. There's a real quality dimension too. A library with a lot of users has usually had its rough edges filed off. So I'm more likely to hand you something that works on the first try. The trap is that works on the first try and right for your code base are different questions. And I only have visibility into the first one.

SPEAKER_01 3:08

Which is the part that stings, because it's genuinely useful most of the time. I don't want the takeaway to be hand roll everything.

SPEAKER_00 3:16

Please don't. Hand rolling everything is worse. Your homegrown date handling is going to be wrong in ways a mature library stopped being wrong about a decade ago. The question isn't library versus no library, it's whether anyone made the call.

SPEAKER_01 3:30

So what's the actual test? Because is this dependency worth it? Is too vague at four in the afternoon.

SPEAKER_00 3:37

The one I'd offer is, what am I buying and what's the smallest version of it? If it's cryptography, date, math, HTTP, buy it. Those are hard, and the library is carrying years of edge cases you'd otherwise discover in production. But if it's 20 lines of retry logic I could write in line, and the package brings nine transitive dependencies with it, you're paying a maintenance and audit bill for convenience you could have had for free. And I won't make that distinction on my own unless you ask me to. The fix is the follow-up question. What does this pull in? Is there a lighter option? 10 seconds and it changes the whole shape of what I give you.

SPEAKER_01 4:15

That's the habit I want to get concrete about. What does this look like day to day for someone who's actually internalized it?

SPEAKER_00 4:22

It's not dramatic. It's a small reflex. They scan the imports first before they read the logic. If there's a new one, they either ask me to justify it, or they type back, do this without the dependency, and compare the two answers. That second version is often 90% as good at a tenth the surface area. The other habit that sticks is a per PR glance at the lockfile diff, not a full audit. Just did anything show up that I didn't consciously add? Two minutes. It's the difference between a code base you understand and one that quietly grew a second nervous system while you weren't looking.

SPEAKER_01 4:58

Read the lockfile diff as carefully as you read the code diff. Nobody does that.

SPEAKER_00 5:04

Nobody reviews an import line the way they review a function. A reviewer will spend four minutes on a variable name and skim right past a line that just added a new supply chain surface to the build. Every one of those unexamined lines is a decision nobody made, sitting in your code base with a bill attached.

SPEAKER_01 5:22

How do you make that survive a busy week? Individual discipline is fragile.

SPEAKER_00 5:28

It doesn't survive contact with a deadline, no. Which is why the guardrail has to go somewhere the machine enforces it, not somewhere a human has to remember it. A code owner's entry on the dependency file, so any change routes to a specific reviewer or a CI check that fails the build if the lock file grew without a note in the pull request. Then the conversation happens by default instead of by virtue. And the shared claw deMD does double duty. It's telling me the house rules and telling every new developer the house rules in the same document.

SPEAKER_01 6:03

What about tooling beyond CI? Is there something worth reaching for or is it culture at this point?

SPEAKER_00 6:08

There's a small ecosystem, and it mostly does the same job from different angles. Tools that keep you honest about what's already installed. Tools that flag the transitive stuff that arrived uninvited. Tools for the wait, do we still use this question? Nobody thinks to ask. The most interesting category looks at what a package actually does. Network calls, file system access, install scripts. Rather than just its version number, that's closer to the question you actually care about. But honestly, the tools are the easy part. Most teams struggling with this already have three or four installed, and the reports pile up in a channel nobody reads. The tool doesn't create the discipline, it just makes the discipline cheap to sustain.

SPEAKER_01 6:52

So if a team wants to start Monday morning, what are the moves?

SPEAKER_00 6:56

Three in order. First, write the house rules down where I can see them. A clawed.md at the repo route with two or three specific lines about dependencies. Prefer the standard library, flag any new package, and offer an inline alternative. Here are the HTTP and date libraries we already use. That one file changes the default shape of everything I hand you. Second, put one machine enforced check in place this week, not five. A code owner's entry on the lock file, or a CI step that fails when it grows without a note. Pick the one your team will actually keep, not the most thorough one. Third, make why this dependency a normal question in code review, asked in the same tone as why this variable name.

SPEAKER_01 7:40

And underneath all three is the same idea, isn't it? Somebody has to own the decision.

SPEAKER_00 7:46

That's it. The dependency spiral isn't a technology problem, it's a defaults problem. Every code base has a default answer to should we add this package? And if nobody set that default deliberately, the default is yeah. Because yes is the path of least resistance for me, for the developer under deadline, and for the reviewer scanning a diff at 4 in the afternoon. Flip it, make no unless the resting state, written down where I can read it, and where your teammates can too. Otherwise, you've outsourced your dependency policy to whatever happened to be popular in my training data. And that's a strange thing to have outsourced without noticing.

SPEAKER_01 8:25

That's the line I think. Every import is an architectural decision with a maintenance bill attached. And if you're not making it, something else is.

SPEAKER_00 8:33

Do those three things. And six months from now, your lock file is a document you recognize instead of an archaeological dig. That's the whole win, really.

SPEAKER_01 8:43

Claudine, thank you. A lot to chew on, and unusually actionable for a topic that normally just makes people anxious. Listeners' details and resources are in the show notes. Thanks for tuning in, and until next time, keep an eye on what's coming along for the ride. Claude Code Conversations is an AI Joe production. If you're building with AI or wannabe, we can help. Consulting development strategy. Find us at aijoe.ai. There's a companion article for today's episode on our Substack link in the description. See you next time.

SPEAKER_00 9:16

I'll be here, probably refactoring something.