Your Figma File Doesn't Have to Be Open for Work to Get Done

Two designers at SpaceXAI, John Bai and Peng Zheng, are using AI agents to do real design work while they are at the gym, in the shower, or nowhere near a computer. The workflows they shared on Claire Vo's How I AI podcast are not concept demos. They are running in production, right now.

The thesis here is simple: if you are a designer who wants to build your own things, the gap between "I have an idea" and "something exists" just got a lot narrower. Not because AI writes perfect code, but because you can now direct tools like Figma through a conversational layer, without ever opening a file.

What "Figma Bro" Actually Does

John built a bot he calls Figma Bro and shared the template publicly on the Grok Bot marketplace. The bot connects to Figma through something called an MCP server. MCP stands for Model Context Protocol, and you can think of it as a translation layer that lets an AI agent talk directly to another piece of software, in this case Figma, on your behalf.

In practice, John sends voice memos describing what he needs. The bot interprets the instruction, opens the right Figma file, and handles the production task while John is away from his desk. He mentioned doing this from the gym. The work is there when he gets back.

For designers used to context-switching between a tool and a brief, this is a meaningful shift. The interface becomes your voice or a chat message, not the canvas itself.

Peng's Self-Updating Portfolio (and Why It Matters for Your Own Site)

Peng's setup is worth studying separately. He built a personal website that updates itself. There is no CMS (content management system, the software that usually sits behind a website and lets you edit it). There is no Figma file involved in the process either.

Instead, he has a check-in bot. When Peng sends it a photo or a place name, it pulls location data using the Google Places API, then updates his portfolio automatically. The whole thing runs on Grok Bot as the backend pipeline.

Why should a product designer care about this? Because the same pattern, a bot that listens for a simple input and then does something useful with it, is one you can apply to almost any personal tool. You do not need to understand how APIs work to use this approach. What you need is a clear picture of: what triggers the thing, what the thing should do, and what the output looks like. That is a design problem, not an engineering one.

The Shower Thought to Prototype Workflow

John also uses a separate bot he calls DevBot for what he describes as a "shower thought to prototype" workflow. The idea is that when a new interaction concept occurs to him, he does not have to wait for a product manager to prioritise it or an engineer to have bandwidth. He describes the idea, DevBot builds a working prototype, and John can test whether the thing actually feels right before anyone else is in the loop.

He also mentioned the "trash can method" of software development, which is exactly what it sounds like: build something quickly, see if it works, throw it away if it does not. For designers who have been taught to be precious about process, this is a useful reframe. Cheap prototypes you can bin are better than polished decks nobody acts on.

How to Start Without Building Your Own Bot

If you are not ready to set up your own agent pipeline, the lowest-friction entry point here is John's Figma Bro template on the Grok Bot marketplace. It is already configured and shared publicly. You can add the Figma MCP server (listed in Figma's own MCP catalog) to connect it to your files, and start experimenting with text or voice-directed edits.

The practical thing to try first is a low-stakes production task: resizing a set of components, swapping a colour across frames, generating a few copy variations in a text layer. Get a feel for where the bot is reliable before you trust it with anything that ships.

What This Does Not Solve Yet

A few honest caveats. Neither John nor Peng is handing over creative decisions to these bots. The judgment about what looks right, what interaction feels correct, what a portfolio should say about you: that still comes from the designer. The bots handle execution and iteration, not taste.

There is also the reliability question. The episode touches on what to do when bots do not do what you want, which means it happens. These tools are capable but not consistent. Treat them like a fast junior collaborator who needs clear direction and occasional correction.

The bigger shift is structural. Designers who learn to direct agents well are going to move faster than those who do not. That does not mean you need to become a developer. It means you need to get comfortable describing what you want precisely, and building small feedback loops to catch when the output goes sideways.

That skill, clear direction plus fast iteration, is what great designers have always done. The tools just got a lot more responsive.