The issue with this approach is the mental load of verifying that the it did the thing you asked for correctly. And that it did not mess something like a condition expression.
That's fair to an extent and what I've commented on before as well: AI can make the enjoyable part of coding "go away" and replace it with the menial and unfun part: Code review.The "trick" would be to make it more like a pair programming session than code review.
Which make their whole experience painful for anything that involves a bit of refactoring.
Also agreed! So many times when pairing with others it's like that. It's very painful to see other people debug in many cases. Or write code / interact with their tooling. But then there are also some where it's a ray of light. People that know their tooling just as well as you do or maybe even better and you learn a thing or two.I love it when I come out of a pairing session and I've learned something that I can incorporate.
And it pains me when I've used something, maybe even specifically called out how I do something, for the n-th time with someone and they still don't catch on. And it doesn't matter if they don't pick it up by themselves or whether it's something that's one of their improvements to work on because we literally talked about it in the last seven 1:1s or something. Some people "just don't get it" unfortunately. Some people really just aren't cut out to be devs. AI or not.
Editing is effortless in that case. You think about a solution and it's done.
Yes but ;) As in, agreed on effective tool use being awesome but unfortunately more rare than I would like. But there are other people "like you and me" out there. Sometimes we have the fortune to work with them. It's such a delight! I love working with them. I love just working with someone that's on the same level and we can pair on an equal level and get shit done. It's rare though.It's not just done though. It's still work in many cases and some of that really can be improved with this new tool: AI. Just like we were able to replace a 30 minute Perl refactoring done manually with a few seconds IDE refactoring in Kotlin (or whatever language floats your boat/happens to be used where you are)
low quality code and having to coax specifications from teammates.
I'm not sure I understand this part to be honest. I don't usually coax specifications from teammates. I coax them from Product people or customers and while it's not really the most fun sometimes, personally, I do find joy in the fact that I am delivering something that helps the customer. I enjoy fixing a bug both because I like the hunt for the root cause (something AI really isn't great at doing by itself from my experience yet - but I do enjoy working with it) and because I like it when I can deliver the fix to the customer fast. Customer reported a bug this morning and by the end of the day they have a fix. That's just awesome. Cloud FTW. Gone are the days of getting assigned a bug someone triaged 6 months ago and it will go out with a release 3 months from now, ensuring the customer gets the fix installed a year plus from when they reported it (coz of course their admins don't install a new release the day it comes out, right?)
> I don't usually coax specifications from teammates. I coax them from Product people or customers and while it's not really the most fun sometimes, personally, I do find joy in the fact that I am delivering something that helps the customer.
It's when you're dependent on a service and there's no documentation. Even if you can read the code (and if you can't, you probably should learn), it's better to ask the person that worked on it (instead of making too many assumptions). And that's when the coaxing comes into play.