My attempts at finding a middle ground:
* I use LLMs to resolve the more annoying merge conflicts. It's not super hard work, but I don't like it, and I don't think I learn much from doing it.
* I implement a feature by hand, write some basic tests, and tell the AI to review it and write tests for cases that I missed (or was too lazy to do, most of the time)
* For 80% of the bugs that I fix, I have a pretty good idea going in where the bug might be. In the other cases, I ask the LLM to generate a list of hypotheses what's wrong. Often (but not always) it turns out one of the hypotheses was right.
* Sometimes it's not so easy to figure out how to trigger a bug in a test case. Haven't done it yet, but I plan to ask LLMs to experiment to try to do that for me.
* I use LLMs to generate tools that I wouldn't otherwise write (not high enough priority, too lazy, ...). For example, we had a rabbitmq connector that occasionally kept getting stuck without reconnecting in rare patterns of network interruptions. It wasn't really high priority for us (rare, easy to work around by restarting the service), so I didn't want to spend days of engineering on it. I asked Claude to write me a test harness that reproduced the issue, and it did. Having a bunch of automatically runnable scenarios made the actual fix not too hard.
* Sometimes, I have some software design problems where I feel I have a pretty good solution, but something about it feels off. Talking this through with an LLM often helps to refine or change the approach.
---
This approach to AI usage doesn't make me 10x more productive, but I do think it's a net benefit both for code quality and my enjoyment of the job. I don't know if, in a few months or years from now, I'll still be competitive like this, but right now, I'm doing fine.
* I use LLMs to resolve the more annoying merge conflicts. It's not super hard work, but I don't like it, and I don't think I learn much from doing it.
* I implement a feature by hand, write some basic tests, and tell the AI to review it and write tests for cases that I missed (or was too lazy to do, most of the time)
* For 80% of the bugs that I fix, I have a pretty good idea going in where the bug might be. In the other cases, I ask the LLM to generate a list of hypotheses what's wrong. Often (but not always) it turns out one of the hypotheses was right.
* Sometimes it's not so easy to figure out how to trigger a bug in a test case. Haven't done it yet, but I plan to ask LLMs to experiment to try to do that for me.
* I use LLMs to generate tools that I wouldn't otherwise write (not high enough priority, too lazy, ...). For example, we had a rabbitmq connector that occasionally kept getting stuck without reconnecting in rare patterns of network interruptions. It wasn't really high priority for us (rare, easy to work around by restarting the service), so I didn't want to spend days of engineering on it. I asked Claude to write me a test harness that reproduced the issue, and it did. Having a bunch of automatically runnable scenarios made the actual fix not too hard.
* Sometimes, I have some software design problems where I feel I have a pretty good solution, but something about it feels off. Talking this through with an LLM often helps to refine or change the approach.
---
This approach to AI usage doesn't make me 10x more productive, but I do think it's a net benefit both for code quality and my enjoyment of the job. I don't know if, in a few months or years from now, I'll still be competitive like this, but right now, I'm doing fine.