If I may refer to a Zen koan, "your teacup is full."

I started programming professionally around java 1.3, and the greybeards around that time were talking about how they had moved to OOP. Most disliked it but the people who didn't adapt got stuck in dead ends. (Stay in a dead end long enough and it becomes lucrative - see Oracle DBAs and COBOL developers - if you can stay there long enough!)

You absolutely have to treat coding with LLMs as a new skill. It's just like learning a new editor to the same precision that you know Emacs or Vim. It's learning the rough edges - and the rough edges keep changing. As a senior, it's frustrating! However, as I learn more, I learn the necessary concepts to utilize what is good and try the frustrating part in a month or two when it has gotten better and so have I.

I've spent a career reading others' code, so that doesn't bother me.

Now, I prompt through TDD for code that matters and that has helped stop many of the problems I see others face. It's a little slower as an iteration loop but it generates the test data well, it allows me to make sure I understand the problem and the prompt, and it forces the changes to be small, which increases success.

If I have to make a non-trivial change to the code, I know it will try to rewrite it if I don't start a new agent session. So, I'm liberal with creating new sessions.

It is much better at small problems than large problems, which makes me cognizant to keep my problems small. Not only is that good for the LLM, it's good for the codebase.

In some cases, it's better to have the LLM create a script to make the change than try and have it go through the code with a prompt. It's very good at simple scripts.

And I'm not afraid to discard it when it's not valuable at the moment.