Pair programming when enforced full-time as a way of having two developers work together is completely exhausting, unpopular with most developers, and slower than having everyone work on their own problems. There is a certain personality who really likes full-time pair programming because they are very social and like coworking problems, but most people dislike it.
That’s fascinating, i recognise every bit of everything else you said but in my experience this was the golden redeeming quality - velocity of correct code is massively (maybe 4x) sped up.
Maybe the difference is overall - pairing becomes too tiring so you might be extremely productive but the short periods of it mean that the slow and steady solo approach wins out because you can do it for longer.
When there's hard problems to track down, I think all developers go to pair debugging. If not only for the rubber duck effect.
I'll talk out loud to myself and verbalize my thought process.
The objective is to show them tools, techniques, and approaches that they would otherwise not pick up. I'm not literally coding with them; I'm doing the coding and explaining my inner monologue for a given problem.
Tooling in particular can be hard to pick up. Even little things like the JavaScript debug console in VS Code can be a productivity changer.
For me, this has been very successful and I have helped more junior devs accelerate their careers. A lot of it is honestly selfish; the more I teach them to work and think like me, the more of my work I can hand off to them. In exchange, I get to work on more interesting things -- win-win
To this day I haven't found an LLM application that works better than regular autocomplete Copilot. It's sufficient to get over the blank canvas problem in a lot of cases without being overly ambitious and biting off more than the LLM can chew.
I've yet to try Cursor, but that's because I don't have a lot of hope: I first heard the same kinds of great things about Aider and Claude and o1, and all of those have disappointed. It's hard to want to switch editors to see if this time is for real.
I had the perfect use-case for LLM-assisted coding a few days ago: I had a well-defined function to implement, for which dynamic programming was a great fit. I haven't used DP in years but it's a well-trodden path, why not throw the problem at the LLM and let it implement it?
Well despite careful prompting, it kept getting it wrong. At some point it generated some credible code, but I spent the day finding problems, nudging it to fix it, asking for explanations for stuff that looked (and was) incorrrect... Resulting code was bug riddled and horrible (LLMs tend to fix problems by adding more code rather than rearchitecting the existing code to eliminate edge-cases). I ended up spending a whole lot more time, I had to spend ages carefully nudging the LLM to no avail, understand LLM-generated garbage code _and_ still solve the problem myself.
For me as a senior eng, Cursor is where AI turned the corner from "maybe helpful for fringe / basic things" to "actually amplifies my productivity". Took about 30 min to flip the switch for me, so I suggest you give it a try.
I imagine it's easier to switch for someone who's already making do with VS Code, because at that point the main hurdle is just being willing to pay for an editor. I already pay for an editor (a bundle of them), but "VS Code with better AI integration" just... doesn't appeal, especially when the word-of-mouth recommendations say all the same things that I've already heard about other tools that didn't work for me.