I've been thinking about what libs and pkg indexes might look like as coding assistants become the norm. What if instead of packages providing a post_install.sh script (to regex config, add symlinks), they had a post_install.md prompt to help integrate the code into your app. Libraries and packages indexes (especially language specific ones) have been a boon for code reuse. But they can only be used for code that can be cleanly abstracted. I often encounter chunks of code I wish could reuse as a lib, but I can't because I can't abstract it well enough But if you wanted to package up a partial table schema and some prompt about how it could be rendered in a UI, then the package manager+coding assistant could auto merge the partial schema into the user's existing schema and even make the right UI updates to show the new fields This might really help when building apps using coding assistants. Having assistants write so much code from scratch still feels unpredictable. What I really want is to be able to suggest from an index of code fragments and prompts which things to glue into my app. Such a package index would encourage open source contribution of prompts plus pre-made code fragments. I'm interested in others thoughts.

David Crawshaw’s [article](https://crawshaw.io/blog/programming-with-llms) might be relevant to your interests; he says that he uses more local packages because it’s easier to keep context smaller to work with LLMs:

As LLMs do better with exam-style questions, more and smaller packages make it easier to give a complete and yet isolated context for a piece of work. This is true for humans too, which is why we use packages at all, but we trade off package size against the extra typing/plumbing/filing to make more readable code. With an LLM both doing and benefiting from a big chunk of that extra work, the tradeoff shifts. (As a bonus, we humans get more readable code!)

which I think meshes well with your idea about having small chunks that are integrated directly into the program, rather than isolated in a

node_modules

or

site_packages

or whatever

Ah, thanks for the reference! That's a cool observation that this trend would encourage smaller packages since writing the extra glue code between them isn't a burden for LLMs. That's a nice way to put it.

Also, LLMs, please save us from incompatible dependencies. I had a situation where external dependency A, which I was already using, depended on X-v1.0, and I couldn't add a library B that depended on X-v2.0.

I would love that. Just have the llm solve the dep incompatibility either by finding the right versions or doing the refactorings in the main app to make it work

What if there were just a way to auto-import based on you using function calls from so-and-so library? The agent could suggest imports and handle everything by preprocessing your code.

Interesting observation. If that addendum really increases the effectiveness of LLMs (measured as how well they extract the useful parts) when using a library as a source , then it definitely will be useful!