> and you just dump it in your project with limited vetting

Well yes there’s your problem. But people have been doing this with random snippets found on the internet for a while now. The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs

> The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs True. But the difference is the scale and ease of doing with code generators. With a few clicks you can add hundreds of lines of code which supposedly does the right thing. While in the past, you would get code snippets for a particular aspect of the problem that you are trying to solve. You still had to figure out how to add it to your code base and somehow make it “work”

Surely in any responsible development environment those hundreds of lines of code still have to be reviewed.

Or don't people do code review any more? I suppose one could outsource the code review to an AI, preferably not the one that wrote it though. But if you do that surely you will end up building systems that no one understands at all.

Agree. Any reasonable team should have code reviews in place, but an irresponsible coder would push the responsibility of code quality and correctness to code reviewers. They were doing it earlier too, but the scale and scope was much smaller.

Right, but you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?" or "will the author be compromised in a supply-chain attack, or do a deliberate protestware attack?" etc. As for performance, a lot of npm packages don't have proper tree-shaking, so you might be taking on extra bloat (or installation cost). Your point is well-taken, though.

You can avoid all those worries by vendoring the code anyway. you only 'need' to update it if you are pulling it in as a separate dependency.

> you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?

This is not a worry with NPM. You can just specify a specific version of a dependency in your package.json, and it'll never be updated ever.

I have noticed for years that the JS community is obsessed with updating every package to the latest version no matter what. It's maddening. If it's not broke, don't fix it!

Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features.

Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into account all the other possible use cases you don't care about.

But in a lot of cases you can't know all the dependencies, so you lean on the community trusting that a package solves the problem well enough that you can abstract it.

You can pin the dependency and review the changes for security reasons, but fully grasping the logic is non-trivial.

Smaller dependencies are fine to copy at first, but at some point the codebase becomes too big, so you abstract it and at that point it becomes a self-maintained dependency. Which is a fair decision, but it is all about tradeoffs and sometimes too costly.

You'd get those benefits from traditional dependencies if you copy them in and never update. Is an AI dependency going to have the equivalent of "upstream fixes"?

Probably? LLMs will train on fixes, then if you run the code through the LLM again to fix it.

> Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features.

In decent ecosystems there should be low or zero overhead to that.

> Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into account all the other possible use cases you don't care about.

Maybe. I find generic code is often easier to read than specialised custom implementations, because there is necessarily a proper separation of concerns in the generic version.

Wouldn't call it a risk in itself, but part of the benefit of using a library, a good and tailored one at least, is that it'll get modernised without my intervention. Even if the code produced for you was state-of-the-art at the moment of inclusion, will it remain that way 5 years from now?