"An AI assistant that lets you talk with your documentation." This is a nice opening for me to say something in a positive way instead of a negative way: I'm m

"An AI assistant that lets you talk with your documentation." This is a nice opening for me to say something in a positive way instead of a negative way: I'm more interested in this sort of thing than some of the other uses of the LLMs. Consider the use case I've seen bandied about of "This will automatically take your commit and write commit messages!" This is useless to me... but not because of the "but it will lack insight" sorts of reasons. That may be true, but that only makes it less useful, it doesn't remove the use. The reason why I call this useless is, I have no need for the output to live in a commit message. I can take any commit I like, even a commit that already has a commit message, and feed it into a summarizer. In fact if I do it three or four years from now, it'll probably be even better, on the same input. Taking fixed inputs, just throwing an LLM at it, and recording the output somewhere, is not a useful use to me, because there's no compelling reason for me to do that today when I could even more easily do it on demand, later. Now, ingesting my documentation (or perhaps even my raw source code) and answering the question I have right now is valuable to me, right now. Maybe in three years the system will be even better, but I have a question right now. In general, I'd suggest that any startup looking at adapting LLMs look carefully at any place their system involves storing the output of the LLMs somewhere persistent. Marketing fluff, well, I may have personal distaste for that use, but it's a case where it clearly makes sense. Autogenerated documentation for filling in a Wiki suffers from the same problem I'm outlining here.