I've said this a few times on HN: why don't we use LLMs to generate documentation? But then came the naysayers ...
An LLM can't magically figure out your motivation behind doing something a certain way.
111–120 of 181 posts
I've said this a few times on HN: why don't we use LLMs to generate documentation? But then came the naysayers ...
An LLM can't magically figure out your motivation behind doing something a certain way.
If you want to use Ollama to run local models, here’s a simple example: from ollama import chat, ChatResponse def call_llm(prompt, use_cache: bool = True, model="phi4") -> str: response: ChatResponse = chat( model=model, messages=[{ 'role': 'user', 'content': prompt, }] ) return response.message.content
Is the output as good? I'd love the ability to run the LLM locally, as that would make it easier to run on non public code.
You can tell that because simonw writes quite heavily-documented code an the logic is pretty straightforward, it helps the model a lot!
https://github.com/Florents-Tselai/Tutorial-Codebase-Knowled...
https://github.com/Florents-Tselai/Tutorial-Codebase-Knowled...
Is there an easy way to have this visit a private repository? I've got a new codebase to learn and it's behind credentials.
Looks inside
REST API calls
I've said this a few times on HN: why don't we use LLMs to generate documentation? But then came the naysayers ...
Useful documentation explains why the code does what it does. Ie. why is this code there? An LLM can't magically figure out your motivation behind doing something a certain way.
I would find this more interesting if it made tutorials out if the Linux, LLVM, OpenZFS and FreeBSD codebases.
You would need a more specific goal than “make a tutorial”. Do you have anything in mind? Are you familiar enough with any of those codebases to suggest something useful? The task will be much more interesting if there is not a good existing tutorial that the LLM may have trained on. OS kernel: tutorial on how to write a driver? OpenZFS: ?
https://github.com/openzfs/zfs/graphs/contributors
I would have preferred to see what would have been generated without my guidance, but since you asked:
* Explanations of how each sub-component is organized and works would be useful.
* Explanations of the modern disk format (an updated ZFS disk format specification) would be useful.
* Explanations of how the more complex features are implemented (e.g. encryption, raid-z expansion, draid) would be interesting.
Basically, making guides that aid development by avoiding a need to read everything line by line would be useful (the ZFS disk format specification, while old, is an excellent example of this). I have spent years doing ZFS development, and there are parts of ZFS codebase that I do not yet understand. This is true for practically all contributors. Having guides that avoid the need for developers to learn the hard way would be useful. Certain historical bugs might have been avoided had we had such guides.
As for the others, LLVM could use improved documentation on how to make plugins. A guide to the various optimization passes would also be useful. Then there is the architecture in general which would be nice to have documented. Documentation for various esoteric features of both FreeBSD and Linux would be useful. I could continue, but I the whole point of having a LLM do this sort of work is to avoid needing myself or someone else to spend time thinking about these things.