I think what matters these days is more design and architecting skills. I still actively discuss and exchange idea with my colleagues. I'd imagine I would pair program for a focused session working on an important feature, but I assume an agent basically works as my driver
One reason to pair is to observe how other people work. So I find it invaluable. Even if its how someone else uses an agent.
I also find it useful for educational purposes. In the olden days, that would mean a senior coaching a junior. That's still relevant for most non-trivial tasks, even those that involve an agent.
Pairing also helps two people share a mental model for some code. That becomes the kernel of shared team understanding. I still think that's relevant, even if we're collaborating on a PRD an agent uses.
And frankly, I still think its useful to ocassionally read / write code. And another human in the loop helps a lot with that.
Solo here. So pairing was never my baseline, but the thing agents changed for me is the review rather than the writing. I used to read my own diff once and ship it. Now I read it like it came from someone else, because it did, and the failure mode is different.
So from my own experience two agents are better. If setup properly they will collaborate and argue about code. For speedup use two or more agents if solo
I encourage my teams to pair as often as possible. Usually the format is "two humans, as many agents as necessary". From what I've seen the outcomes are better than anything one human could do, and faster. I have no real data to prove that though.
I think what matters these days is more design and architecting skills. I still actively discuss and exchange idea with my colleagues. I'd imagine I would pair program for a focused session working on an important feature, but I assume an agent basically works as my driver
Yes
One reason to pair is to observe how other people work. So I find it invaluable. Even if its how someone else uses an agent.
I also find it useful for educational purposes. In the olden days, that would mean a senior coaching a junior. That's still relevant for most non-trivial tasks, even those that involve an agent.
Pairing also helps two people share a mental model for some code. That becomes the kernel of shared team understanding. I still think that's relevant, even if we're collaborating on a PRD an agent uses.
And frankly, I still think its useful to ocassionally read / write code. And another human in the loop helps a lot with that.
Solo here. So pairing was never my baseline, but the thing agents changed for me is the review rather than the writing. I used to read my own diff once and ship it. Now I read it like it came from someone else, because it did, and the failure mode is different. So from my own experience two agents are better. If setup properly they will collaborate and argue about code. For speedup use two or more agents if solo
I encourage my teams to pair as often as possible. Usually the format is "two humans, as many agents as necessary". From what I've seen the outcomes are better than anything one human could do, and faster. I have no real data to prove that though.