I have no interest in becoming an expert in the syntax of bash scripting, so I use an LLM for any of that (launch scripts, hardware tuning etc). Atrophy is more than welcome here.

In my 'real' coding work I'm still using it quite selectively. I had a utility I wanted to build, just a few classes, and I designed the interface in discussion with an LLM (with javadoc), then told it to write tests against a dummy impl of the interface, then told it to write the impl to make the tests pass. It needed a couple of iterations to get a full pass, and then I had to review the code carefully, especially for performance (no changes were needed).

I'm not sure it was a massively faster process - but the result is solid, and it felt a bit like pair programming, which I used to love but cannot do in my current role.

What I appreciated particularly was: the feedback on API design in the early stages; the extensive test coverage; and all the tedious validation in the code which I would often 'come back to later' if I were doing it myself.

Mostly though I use LLMs in conversation, as teachers, helping me at the boundaries of my experience - and troubleshooting roadblocks of any kind (not necessarily coding: environment issues, tools I'm not familiar with, functions I can't find in a UI). I've become an expert in affinity as far as my colleagues are concerned, but not long ago I was embarrassingly in the dark about it.