Hacker News Reader

Comment by lowercased | Hacker News Reader

Would be interesting to see what impact some sort of llm system might be able to have on this approach. Making some changes in one area of the documentation, then having a system indicate some other likely areas of impact which you might not have considered, seems like it would be useful.

View on HN

If the model can reflect the existing documentation that well, w.r.t. changes in code, you may as well use the LLM as the documentation by fine tuning it with boilerplate/initial docs and have it generate the future documentation based on a context of just the code.

My attempts at this (DDD) involve choosing system components or protocol/API layer dependencies such that they can generate the documentation when they generate the client-lib and server interface code. Isn't always possible, and doesn't cover everything. Having a comment-doc pipeline also helps but sometimes that just adds more trees to occlude the forest. This way the documentation doesn't lead the code too much (I'd rather see deprecated warnings than Not Yet Implemented errors).

Good team communication and a solid codelab for new members can go a really long way, too.

I never thought of that problem this way, but it sounds very cool. I imagine a sort of conversation between the LLM and the author.

- LLM: Did you mean to change A to B?

- Author: Yes, but [more nuanced information]

- LLM: Ah ok, here's the documentation updated: [Doc]

This is basically a holy grail for us technical writers. I know quite a few people working on it.

Reply on news.ycombinator.com