Hacker News Reader

Comment by AMerrit | Hacker News Reader

I've done similar at my job where management wants us to use all of our tokens before they expire. I usually set it to documentation tasks and other minor tasks just to eat up tokens.

View on HN

There's really no end to dot-language diagrams you can have it make. Call graphs, package dependency maps, let it try to figure out an architecture diagram, whatever.

Giving it busywork that you don't have the time or wherewithal to check carefully sounds like a disaster. Rather than introduce content that will be partially wrong and cause confusion if it's ever read, I'd consume the credits and send the output to /dev/null.

Just title it "draft". Odds are nobody will look at it anyway.

Add a pre-commit hook to re-create the diagrams on every commit (in case anything changed, of course), that way you can really burn tokens and look good to management.

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.

If you have artifacts saved as you develop it can use those when writing docs to capture intent and design decisions.

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.

  > LLM stuff is fine for the latter as long as you screen it for hallucinations

that is such a productivity black-hole tho; at that point i might as well have written it myself

IMO that's down to how you personally feel about the two sides of the process. For me the initial writing is super tedious and I've never gotten great at the voice of technical documentation but checking it for errors and correcting that is easy.

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.

Reply on news.ycombinator.com