| ▲ | AMerrit 7 hours ago |
| 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. |
|
| ▲ | rtkwe 7 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | sheept 5 hours ago | parent | next [-] | | 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. | | |
| ▲ | rtkwe 4 hours ago | parent | next [-] | | 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. | |
| ▲ | shigawire 4 hours ago | parent | prev [-] | | If you have artifacts saved as you develop it can use those when writing docs to capture intent and design decisions. |
| |
| ▲ | overfeed 4 hours ago | parent | prev [-] | | Inaccurate documentation can be worse than no documentation at all! | | |
| ▲ | rtkwe 4 hours ago | parent [-] | | ...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. |
|
|
|
| ▲ | funimpoded 7 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | gdulli 6 hours ago | parent [-] | | 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. | | |
| ▲ | funimpoded 6 hours ago | parent [-] | | 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. |
|
|