MobAI: From Copilot to Team Pilot

AI can make individuals faster. For leaders, the bigger question is whether it helps teams build shared context, judgment, and better decisions.

Exploring MobAI with Joe Justice at Volvo Cars

AI can make individuals faster.

It can also make teams more fragmented.

That is one of the risks I see in how many organizations approach AI adoption right now. One person gets a copilot. Another learns better prompts. A third builds a small automation. Someone else experiments with agents. All of that can be useful.

But most important work in organizations is not done by isolated individuals. It depends on shared understanding, coordination, judgment, learning, and decisions across people.

For leaders, this creates a subtle problem. The organization may look more productive while the team becomes harder to align, steer, and learn from.

This is especially true in complex product development. When the work is uncertain, no single perspective is enough. Product, technology, design, operations, business, customer understanding, risk, and delivery all see different parts of the system.

But many organizations do not actually have teams. They have groups. People sit in the same structure, attend the same meetings, and share the same delivery label. But much of the real work still happens in silos. Individuals pick up tasks, make local decisions, and come back later to synchronize.

This is one reason so many organizations end up coordinating their way forward in endless sync meetings. People meet to talk about the work, report on it, align on it, and hand over pieces of it. Soon several things are half-started, everyone is busy, and the calendar becomes the real operating system.

AI can make that pattern stronger. With a copilot next to each person, it becomes easier to feel self-sufficient. That is powerful. It can also reduce the felt need to involve others.

If AI mainly helps each person move faster in their own local direction, the team may get more output without becoming more capable together.

The bottleneck has moved. It is no longer only about how fast we can draft, prototype, summarize, code, or analyze. AI can help with all of that. The bottleneck becomes shared knowledge, judgment, coordination, and choice.

Everyone has an assistant. Everyone produces more. But the team may not share a stronger view of the problem. It may even lose some of the friction where different perspectives used to meet.

That is the question behind MobAI:

What happens when a team uses AI together on real work?

MobAI hackathon at Assa Abloy

From private assistance to shared work

MobAI was coined by Joe Justice after observing AI-assisted group work at Tesla. It builds on mob programming, also called software teaming, popularized by Woody Zuill.

The basic idea is simple. A team brings a real challenge and works on it together, with AI as part of the shared workflow. The team adds context, tests assumptions, makes decisions, reviews output, and learns as it goes.

This is different from one person prompting while everyone else watches. It is also different from everyone using their own AI tool in parallel and stitching the results together later.

MobAI treats the team as the unit of learning.

The multiple perspectives are not overhead. They are part of the method. In complex work, product risk, customer risk, technical risk, usability risk, and organizational constraints interact. The point is to bring the right perspectives together while the problem is still being shaped.

The shift is from asking, “How can I become faster with AI?” to asking, “How can the team use AI to think, learn, and make better decisions together?”

That is the shift from Copilot to Team Pilot.

Shared work needs deliberate conditions

Shared work needs deliberate conditions

That shift sounds simple, but it is not automatic.

In recent MobAI work, both in course settings and in a full-day customer hackathon, one thing became clear:

It is not enough to put people in a room with AI and hope collaboration happens.

A hackathon can be a very useful way to get started, especially because many organizations already use hackathons to explore new ideas. MobAI gives that kind of event more structure: real work, shared context, short rotations, human-in-the-loop reflection, and cumulative learning.

But MobAI is not limited to hackathons. The same pattern can be used for any complex work where the team needs several perspectives in contact with each other while assumptions, risks, direction, and constraints are still being shaped.

Whatever the format, the team needs enough time, a shared workflow, the right perspectives in the room, and a real problem worth working on together. It also needs to notice where generic AI helps, where it falls short, and what local context needs to be added.

The loop is deliberately simple. The team works on a real challenge with AI in the shared flow. Then it pauses and asks:

  • Are we heading in the right direction?
  • What did we learn?
  • What needs human judgment?
  • What is missing?
  • What new insights and context should we feed back into the AI?

Then the next rotation gets better.

The point is not to remove humans from the loop. The point is to make the human loop better.

For leaders, this is an important distinction. The leadership question is not only whether people know how to use AI tools. It is whether the team is building better shared context, judgment, and learning around the work.

Exploring MobAI with Coretura

AI gets better when the team gets clearer

AI gets better when the team gets clearer

In a recent MobAI hackathon, this became very concrete.

The team worked on a real product and technical challenge. We used short rotations, shared screens, frequent reflection, and AI in the flow. We also recorded the team’s opening context: purpose, constraints, technical setup, and challenge framing.

Then we transcribed that opening context and let the client’s own Copilot use it to suggest sub-teams and starting prompts.

That changed the quality of the work. Not because the AI suddenly became brilliant, but because the team had given it something better than a generic prompt:

Their actual situation: purpose, constraints, language, technical context, open questions, and what they were trying to learn.

The most useful context did not only come from the opening. It also came from the reflection moments during the day, where the team paused, judged the AI output, clarified what it now understood, and fed that back into the next round.

At the end, we also recorded the retrospective. That captured what the team had learned about the challenge, the method, the gaps, the risks, and the next experiment.

The team did not only give AI a better starting point. It kept improving the context as the work unfolded.

That is where the real work begins.

MobAI reveals what the team needs to clarify

MobAI reveals what the team needs to clarify

MobAI does not hide the messy parts of teamwork. It tends to reveal them faster.

What are we trying to achieve? What is in scope? What are we assuming? Which risks matter first? What does “good enough” mean here? What needs human judgment? Who has context the rest of us are missing?

Those are not AI questions. They are team questions.

If people work mainly as a group of separate specialists, these questions often get answered locally. AI may help each person produce more polished local answers, but the hard product-development work is often in the differences between those answers.

In the hackathon, the AI work surfaced unclear product assumptions, missing customer context, different meanings of MVP, proof of concept, and experiment, and moments where technical risks got attention before business or usability risks.

That could look like a problem. I think it was part of the value.

The team was not just producing AI-assisted output. It was discovering what it needed to clarify in order to make better progress.

This is why I do not see MobAI as an AI training format. At least not mainly.

It is a team practice.

MobAI with the Traton AI Enablement team

Why this matters now

Why this matters now

Many organizations are treating AI as an individual productivity story.

That story is useful, but too small.

If AI stays mostly private, it can make work less visible. It can create more variation in assumptions, more local optimization, and more generated material for others to interpret later. The organization may feel faster, but the coordination problem has not gone away.

This is also why AI makes product judgment more important, not less. AI can help teams prototype faster, explore more options, write more material, and build more things with less effort. That can accelerate learning. It can also accelerate noise: more features no one asked for, polished prototypes of weak ideas, and confident plans built on shallow understanding.

If you lead teams adopting AI, one useful signal to watch is not only how much faster people produce work. Watch what happens to shared understanding.

Are assumptions becoming more visible or more private? Are decisions becoming clearer or just more numerous? Is the team learning together, or are individuals moving faster apart?

AI can make a group faster without making it a team.

That is the dangerous trade.

MobAI explores another path: AI as part of shared work, in a visible team flow, with human judgment, local context, and collective ownership around it.

In uncertain work, the first useful backlog may not be a list of features. It may be a list of risks and assumptions to validate.

MobAI can help make that visible.

From Copilot to Team Pilot

From Copilot to Team Pilot

MobAI is not one person doing clever prompting for the group. It is not people silently using separate AI assistants in the same room. It is not an AI tool rollout. And it is not a promise that AI will solve the hard parts of collaboration.

If anything, it assumes the opposite.

The hard parts still matter: trust, clarity, listening, product judgment, shared language, and the ability to pause and rethink together.

AI does not replace those capabilities. But used well, it can make them more visible. And once they are visible, the team can improve them.

The next step is not only better individual copilots. It is better team practices.

Practices where AI is visible in the work. Where the team owns the output. Where human judgment stays in the loop. Where context improves over time. Where people learn together, not only faster apart.

That is why I find MobAI interesting.

Not because it is a new label for using AI, but because it points to a deeper shift:

From individual productivity to team capability.

From private prompting to shared learning.

From Copilot to Team Pilot.

If you want to explore how this could work with your team, reach out to me at michael.gothe@crisp.se