I think I would never have done it without this help. I would not have wasted time. It would have remained 'undocumented', namely documented with the code and some comments in it.
Personally, I solve this by writing the documentation first, before even writing a line of code (well, as writing the first lines of code, since it's usually the `usage()` function). This becomes my design document and helps me figure out how I want my program to be used, which then informs me on its architecture, which in turn helps me write everything else very intuitively. Of course, it often happens that I change it as I go, but it doesn't matter, it's just quick edits at this point and doesn't feel like a burden.
As much as I love my LLMs, I would *never* let them write the documentation themselves, first because of the "almost good" syndrome (it's always "almost good", "almost there"… which actually means "not good", "not there", but told by people at the height of the hype phase), but second, more importantly, because it would deprive me of a good opportunity to mind map the problem space in which I'm working.
I really love what zester said, "she is also a better programmer than I am, but I am a better engineer than she is". Yes, *this*. And if we let models write too much code for us, or do too much of our thinking, we lose this edge. Engineering is an end product of thinking while programming. Once we're done writing a program, we're left with an executable, sure, but also with thoughts and experiences that will feed our later designs. Cut this and soon there will be "no engineering left in you".
I do use LLMs constantly to brainstorm and to find knowledge in the haystack, though (whatever the haystack is: web, doc, code, etc), but there's no way they're writing code or documentation for me.
