[corby]

I'm having a problem like this now. I have a library that handles very complex hardware drivers and linkages.

I want people in the company to use it, but it's big and complicated (lots of chipsets and Bluetooth to boot).

I'm trying to design the library so the MCP can tell the LLM to pull it from our repo, read the prompt file for instructions and automatically integrate with the code.

I can't get it to do it consistenlty. There is a big gap in the current LLM tech where there is no standard/consistent way to tell an LLM how to interface with a library (C/Python/Java/etc.)

The LLM more often than not will read the library and then start writing duplicate code.

Maddening.

[simonw]

That's part of the idea behind https://llmstxt.org/ - even if you ignore the "/llms.txt" URL there's a bunch of thinking around that to help write explanations of things like libraries that can be used to "teach" a model to use it by injecting that into a prompt.

I'm still not clear on what the best patterns for this are myself. I've been experimenting with dumping my entire documentation into the model as a single file - see https://github.com/simonw/docs-for-llms and https://github.com/simonw/llm-docs - but I'd like to produce shorter, optimized documentation (probably with a whole bunch of illustrative examples) that use fewer tokens and get better results.

[nimish]

At this point it seems like just learning the library is easier than trying to cram the documentation into an LLM compatible format.

[simonw]

Doing the work to effectively prepare those docs for an LLM probably does involve "learning the library", but once one person has done that (and published the results) many other people can benefit from it.

I'm a library author myself, so publishing LLM-enhanced versions of the docs to help other people use my library more effectively feels like a sensible use of my time.