My main code-adjacent use cases broadly fall into the following categories, and I'll give a few more specific examples afterward: (1) Using LLMs as a learning

My main code-adjacent use cases broadly fall into the following categories, and I'll give a few more specific examples afterward: (1) Using LLMs as a learning aid (or docs augmentation) (2) Writing one-off _whatevers_ (3) Finding the appropriate docs/info in the first place (4) As a meta-tool to sniff out whether other people have gone down this path before (5) Cloning any sort of boilerplate "pattern" which requires more than simple text substitution (nvim macros, custom CLI tools applied to a visual selection, ... can get you a long ways, but they're not good for everything) For a few select examples: (1a) You can copy in a snippet of code and ask what _this_ character does _here_, finding appropriate search terms to actually learn about the topic. (1b) Generated examples are fine, even if they're wrong, if you use them as a mental scaffolding to learn more about a library. Analyze them and prove them right or find why they're wrong, and that process of analysis teaches you in a different way than just reading the docs by themselves. (1c) Sometimes the docs are just unwieldy. Ask the LLM for the snippet immediately after the "-B" flag, and then you can search for that more-unique snippet instead of, e.g., 1000 occurrences of other fields referencing "-B" and not defining it. (2a) Say you want to know how your webserver responds when the client sends each byte in a separate syscall, waits a second between each one, and then immediately starts a new pipelined request doing the same shenanigans without waiting for a response to the first one. The LLM can generate exactly what you need, or when it fails it was still faster than typing it yourself. It's a task that's much more succinct to describe in English than code, yet simple enough that the LLM has a high success rate, and a brief scan of the code can confirm it's actually hitting localhost instead of downloading not-a-virus.exe.txt. The stakes are low if it's wrong because you can visually tell if it's doing the right thing. (3a) I recalled reading once about the design of the voting/scoring algorithm used internally in Google's TGIF question ranker and knew there was a brief public blog post going over the more important details in a consumable format. Current search engines mostly can't point me to an old, unmonetized, niche blog post, especially when I don't remember any of the important keywords. LLMs can often point me to the exact blog, and barring that can usually give me the keywords I need to find it myself (similarly with finding things like the AWS SDK C API, which exists but isn't advertised and is hard to search for because the other keywords dominate). In this case, I wanted to read about Wilson's Scoring by Evan Miller [0]. (4a) Ask the same question a few different ways and a lot of times. If you only get garbage hallucinated blog posts, research articles, and keywords not related to your current task, it's suggestive of the specific task you're doing not being popular. If at a high level you know your end goal has been implemented many times, that's suggestive of you going down an incorrect path. (5a) I was writing a program heavily leveraging lazy type instantiation to generate a zero-cost (de-virtualized, inlined where appropriate) iterator library. Anyone can write map and reduce, but it's a little more annoying to have a meta-layer doing that sort of thing in the type system, especially with some other constraints I had in the project. However, showing the LLM a few examples of this type-level way of defining the things I'm doing and then asking for implementations of `peek` or `skip` or whatever worked swimmingly. They're well suited to that task because the boilerplate isn't just simple textual substitution, because the tasks are simple enough that the LLM has a high chance of getting them right, and because the nature of the library is that a couple very simple hand-written tests will catch all the subtle mistakes, and a human reading the code will catch all the non-subtle errors. And so on. I don't use LLMs for everything. If I want to do anything involving infrequently used Python dunders I'll probably go straight to the data model docs [1] and search within that page. I write most code by hand (give or take many custom tools I've integrated into my nvim workflow). Sometimes an LLM makes my life easier though. [0] https://www.evanmiller.org/how-not-to-sort-by-average-rating.html https://www.evanmiller.org/how-not-to-sort-by-average-rating... [1] https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html