About seven or eight years ago, I was leading a development team when someone introduced me to a concept I hadn't encountered before: mob programming. The idea sounded almost counter-intuitive. Instead of developers working individually — or even in pairs — the entire team works together on the same problem at the same time, looking at the same screen.
My first reaction was probably the same one most people have: how could that possibly be efficient?
But the idea stuck with me, so I decided to research it before bringing it to my company.
If I was going to ask an organization to dedicate time and space for an entire engineering team to work together on one problem, I needed more than curiosity. I needed evidence. As I looked into teams that were already practicing mob programming, the results they reported were difficult to ignore. Teams saw fewer defects in production, higher code quality through continuous review, faster onboarding for new engineers, and far less knowledge trapped inside individual developers.
One observation showed up repeatedly in the research. While mob programming might appear slower in the moment — because multiple people are focused on one task — the overall delivery speed often improves. Teams spend less time debugging, less time rewriting code, and far less time rediscovering how systems work.
Armed with that research, I pitched the idea internally. I didn't present it as a novelty or a team experiment. Instead, I framed it as an engineering practice with measurable outcomes. What I asked for was fairly simple: a dedicated room, a large display everyone could clearly see, and time carved out once a week for the team to work together.
To their credit, leadership was open to the idea.
We set up a room with a 50-inch television mounted on the wall acting as a large secondary monitor. Chairs were arranged so the entire team could see the screen comfortably, and a single keyboard drove the workstation. The format itself was simple. One person sat at the keyboard — the driver — while the rest of the team focused on solving the problem.
The driver typed exactly what the team told them to type, and we rotated the driver regularly so everyone participated.
One rule made the whole thing work far better than I expected: the driver was not supposed to think about the solution. Their job was simply to execute what the team decided.
At first that sounds strange. Developers are accustomed to solving problems while they code, and telling someone at the keyboard not to solve the problem feels counterintuitive. But separating those responsibilities changes the group dynamic in a powerful way.
When someone is coding and thinking at the same time, their attention is split. They're often preparing what they want to say next while also focusing on the implementation. In mob programming, the driver is freed from that pressure. They aren't responsible for solving the problem or preparing the next idea. They simply execute the team's decisions.
That small shift creates something interesting. The driver becomes one of the most attentive participants in the room, because they are free to listen fully instead of thinking ahead. Meanwhile the rest of the team focuses entirely on the problem — discussing approaches, exploring tradeoffs, and thinking through edge cases.
Instead of multiple developers trying to drive the solution, the team begins to function as a single thinking unit.
We didn't mob every day. In fact, we mobbed only once a week. That cadence turned out to be perfect. During the rest of the week, people still worked independently, but the mob session became the place where we tackled the types of problems that benefited most from collective thinking: complex bugs, architectural decisions, difficult integrations, and tricky edge cases.
Some of the best work our team produced came out of those sessions.
But the biggest surprise wasn't the productivity. It was the effect mob programming had on the team itself.
When people solve hard problems together in real time, something changes. Trust grows. Respect grows. Developers begin to understand how each other think. Junior engineers learn faster because design decisions are explained out loud instead of hidden in code commits. Senior engineers share context that might otherwise remain in their heads.
Without intending to, mob programming became one of the most effective team-building mechanisms I've ever experienced.
For a while, mob programming gained attention within the Agile community. Over time, however, the industry largely moved away from it. Remote work made it harder to do naturally, and many teams drifted back toward individual work streams. The idea never completely disappeared, but it stopped being widely discussed.
Recently, though, I've started thinking about it again. The environment we build software in today is very different from what it was eight years ago.
Today nearly every development team has access to AI assistants, and interestingly, AI fits surprisingly well into a mob programming environment. Instead of the team pausing while someone searches documentation or experiments with an idea, AI can surface relevant information instantly, generate scaffolding code, suggest alternative implementations, produce test cases, and even summarize the architectural decisions made during the session.
The team still makes the decisions. AI simply removes friction from the collaborative process.
Looking back, I think the real value of mob programming had very little to do with writing code together. The screen was just a focal point. The real outcome was shared understanding. The team thought together.
And in a world where AI can generate code faster than any human team ever could, shared understanding may become even more valuable than it was before.
Mob programming may have sounded unconventional when I first pitched it years ago. But with AI now part of the development process, it might actually make more sense than it did back then.
Because the future of software development probably isn't humans versus AI.
It's humans thinking together — with AI helping them move faster.
And sometimes the best way to do that is still a room full of engineers solving a problem together, one screen at a time.