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.