I, personally, am very much going to push back against pair programming as a default. Being "on" all day, interacting with people is completely exhausting. Yes, I've tried it. I can do pairing for an hour or two, then I'm pretty much shot for any social interaction for the rest of the day. Including at home, which is a problem.
TDD sounds great in theory, but in practice most of the time the requests from PMs are incomplete. They may have the happy path mostly figured out, but they have usually given zero thought to corner cases, error conditions, or second order effects. You can't write meaningful tests for these (the most valuable cases to test!) until you go a few rounds of iteration with the PM. And generally you can't explain it to the PM without at least a mockup of the situation. It's often faster to create a barebones implementation to demo than it is to create visual mockups that convey the complexity. And then you've written your implementation before the test anyway.
I have found it (difficult, but) effective to actually make PMs sit with engineers and hash out the most important test cases for this reason. Especially under a deadline, it's easy for PMs and designers to sling mockups and stories at an engineering team, who then have to work out during development what all the behaviours implied by that documentation should be -- many of which aren't even edge cases, they just weren't well-considered.
Walking through mockups and saying "ok, but what happens if I do this" is essentialy the same question as "what are the acceptance tests for this?"
Often that happens in various kinds of meetings over the course of feature development, when it would be more effective to just immediately create the tests up front, which can then go and be developed against. With current tooling, it's actually possible to get the PMs to participate in detail in writing tests. Although that point is often where I have gotten the most pushback.
AI is going to completely replace pair programming for popular languages/frameworks, if it hasn't started already. Human + AI is going to be close to as good as 2 humans, perhaps better, and only one salary.
> Human + AI is going to be close to as good as 2 humans
LLMs are very good at programming chores, albeit with supervision and verification.
But the role of your human pair is to do more than that. I am not keen on pair programming as it in the extreme (reductio ad absurdum ) it is a waste.
But I am denied human conversation in my day job, and it is very bad for my productivity. It is not the programming chores I need help with, it is help avoiding "cul-de-sacs". An LLM is hopeless at that It has no idea of the bigger picture, the passing of time, it feels no frustration and has no hope.
This is a form of pair programming I could get behind, but I will not abdicate my creative tooling to a 3rd party whose priorities are vastly out of alignment with mine own. When I can run a good, free software AI on my laptop or a reasonably priced external box then I'll be interested.
TDD sounds great in theory, but in practice most of the time the requests from PMs are incomplete. They may have the happy path mostly figured out, but they have usually given zero thought to corner cases, error conditions, or second order effects. You can't write meaningful tests for these (the most valuable cases to test!) until you go a few rounds of iteration with the PM. And generally you can't explain it to the PM without at least a mockup of the situation. It's often faster to create a barebones implementation to demo than it is to create visual mockups that convey the complexity. And then you've written your implementation before the test anyway.