Comment by rtkwe
18 hours ago
At least that nominally creates some value at the end of the day. Documentation is the thing everyone wants but no one has time/desire to create. My most recent token heavy task was having an agent write unit tests for coverage on a little graphAPI tool I'd written a bit ago to satisfy SonarQube.
People don't want to read LLM-generated docs though. It'll lack the context to justify why things were designed the way they were, and there's always a risk of hallucination so you still have to verify the documentation's claims, since the person who published it likely did not scrutinize it.
There's two major types of documentation "why is this like this" documentation and then there's "here's the features of this library/tool" documentation. LLM stuff is fine for the latter as long as you screen it for hallucinations. Your right the former they can't really do because they don't have access to the reasoning but I've often found even the latter to be lacking in many teams.
that is such a productivity black-hole tho; at that point i might as well have written it myself
If you have artifacts saved as you develop it can use those when writing docs to capture intent and design decisions.
Inaccurate documentation can be worse than no documentation at all!
...Yes. I didn't say fire and forget but it can handle a lot of rote recitation of library flags and functions perfectly well. The kind of stuff that's autogenerated with javadocs, inputs, outputs and effects that are all in the code are available to the LLMs. Like all things with LLMs generate and review but I've seen some good outputs with minimal errors that saved days of work no one was going to be given the time to do.