AI-Mob Prototyping

The adoption problem

Most teams buy AI tools and expect adoption to follow. It doesn't. Designers learn one tool, developers learn another, and product managers learn neither. Everyone experiments in isolation. Three months later, the tools are shelfware and the team is still shipping the same way it always has.

The issue isn't the tools. It's that everyone knows AI changes how work happens — but nobody knows why collaborating effectively with AI tools matters.

What mob programming has to do with it

Mob programming is a practice where a whole team works on the same thing, at the same time, on the same screen. One person drives, the rest help that person navigate. It's been used in software teams for years to solve hard problems fast and spread knowledge without meetings or documentation.

AI-mob prototyping applies this format to AI-assisted work. Instead of sending people off to learn AI individually, you put a designer, a developer, and a PM in front of the same problem — and build/design something together in real time using AI tools.

The developer prompts the AI to generate code. The designer and the PM interpret the output, give feedback, and steer it toward something that solves the problem. The AI becomes a shared resource and a live prototyping/designing partner. It sounds inefficient, but it's faster than the traditional handoff process — and brings everyone together very early on in the problem-solving process.

Why complementary skills matter

AI tools are general-purpose, but the problems teams solve are not. A designer sees interaction patterns. A developer sees data structures and edge cases. A product owner sees user needs and business constraints. When these perspectives converge in a single session, AI becomes dramatically more useful — because the prompts are better, the feedback loops are instant, and the decisions stick.

Compare this to the typical approach: a designer mocks something up alone, a developer interprets it days later, and edge cases surface in QA weeks after that. AI can accelerate each of those steps individually, but it can't fix the gaps without the mob.

What a session looks like

A typical AI-mob session runs two hours and follows three phases.

Frame (0–20 min) — The team aligns on the problem, constraints, and what "done" looks like. No decks, no briefs. Just a clear problem worth solving. Of course, the PM's role is critical here — they must ensure the problem is well-defined before the AI-mob session.

Mob (20–100 min) — The team builds the prototype together, live. One person drives while others navigate. AI handles the heavy lifting — generating layout code, interaction logic, and content — while the team steers it toward something that actually solves the problem. The developer prompts the AI to generate code, they speak the language that the AI understands, and the designer and PM give feedback in real time.

Ship (100–120 min) — The session ends with a working prototype. Not a mockup, not a slide — something you can click through, test with users, or hand to a developer to extend. You can then host it internally where a larger audience can see it, collaborate on it, and give feedback.

What teams take away

The prototype is the obvious output. But the less obvious one is more valuable: the team now has a shared mental model of how you solved the problem, the decisions behind it, and the trade-offs made.

Try it yourself

Our setup looks like this, as we only deal with React web apps:

• DESIGN_SYSTEM.md
• package.json
• A list of custom components with usage examples/variants/props
• Claude Projects with these files in the files section of a project
• A simple instruction, "You are an expert react developer, you faithfully create screens that are fully-compliant with the design system and dependencies provided to you."
• Chat with Claude in that project, copy paste the code in your repository, and see the prototype as you iterate on the prompts and code.