Leif, well put. I look at this as the era of the super-generalist. Everyone is looking for the team member who brings specialist knowledge of every domain. There maybe a few polymaths who possess the such deep knowledge. But the realistic solution, is team members who have the breadth of knowledge to identify the traits of a specialist solution in a given problem domain.
What puzzles me is why the ability to write more code quickly hasn't resulted in more pair coding or pair prompting, as the risk of not defining the solution correctly grows with the speed to market.
Pair coding proper (two engineers at one keyboard) has always been a niche practice — and if anything it’s getting less necessary, because for a lot of execution the model is the second seat now. It offers an approach, catches the small stuff, pushes back on syntax. The engineer’s human pair got absorbed by the tool. Which is exactly why the pairing that counts moved up a level: to product and engineering, in the room together.
The counterintuitive part is that cheap code doesn’t mean fewer decisions. It means more of them. What used to be an MVP is now MVP+2 in half the time — yet that larger scope has to be decided before the agent runs, or it builds the under-specified version at full speed and hands you something superficially plausible that solved the wrong problem.
Which I take as your point: the penalty for bad product definition has gone up, not down.
And that product-eng pairing has to run differently now. The loop isn’t new (agile always planned for it) — what changed is the tempo: it’s collapsed from days to hours, and at that speed the decisions can’t wait for the next planning meeting.
Leif, well put. I look at this as the era of the super-generalist. Everyone is looking for the team member who brings specialist knowledge of every domain. There maybe a few polymaths who possess the such deep knowledge. But the realistic solution, is team members who have the breadth of knowledge to identify the traits of a specialist solution in a given problem domain.
What puzzles me is why the ability to write more code quickly hasn't resulted in more pair coding or pair prompting, as the risk of not defining the solution correctly grows with the speed to market.
Great point, and worth splitting the two.
Pair coding proper (two engineers at one keyboard) has always been a niche practice — and if anything it’s getting less necessary, because for a lot of execution the model is the second seat now. It offers an approach, catches the small stuff, pushes back on syntax. The engineer’s human pair got absorbed by the tool. Which is exactly why the pairing that counts moved up a level: to product and engineering, in the room together.
The counterintuitive part is that cheap code doesn’t mean fewer decisions. It means more of them. What used to be an MVP is now MVP+2 in half the time — yet that larger scope has to be decided before the agent runs, or it builds the under-specified version at full speed and hands you something superficially plausible that solved the wrong problem.
Which I take as your point: the penalty for bad product definition has gone up, not down.
And that product-eng pairing has to run differently now. The loop isn’t new (agile always planned for it) — what changed is the tempo: it’s collapsed from days to hours, and at that speed the decisions can’t wait for the next planning meeting.