Como designers usam AI agents para prototipar sem escrever código
Dois designers do time de Grok Bot mostram fluxos de discovery e prototipagem que trocam o CMS, o Figma manual e até o notebook por agentes conversacionais. O que dá para levar pro seu produto.
O episódio do podcast How I AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, de Claire Vo (a mesma por trás do ChatPRD), colocou dois designers do time de Grok Bot na xAI para mostrar, ao vivo, como usam AI agents no dia a dia de design. A conversa importa menos pela empresa em si e mais pelo que ela revela: o gargalo clássico entre ter uma ideia de produto e ver essa ideia rodando na tela está encolhendo para minutos, e quem opera essa mudança não é o engenheiro, é o próprio designer.
Antes de seguir: AI agent, aqui, não é um chatbot que responde perguntas. É um agente que executa tarefas de ponta a ponta (chamar APIs, editar arquivos, rodar builds) a partir de instruções em linguagem natural, muitas vezes disparadas por voz ou por uma foto. É essa diferença, entre "me explica" e "faz por mim", que sustenta os fluxos descritos no episódio.
Quem são e de onde vem o material
John Bai e Peng Zheng são designers do time de Grok Bot, o produto de agentes da xAI (referida no material como parte do ecossistema SpaceXAI). John escreve publicamente sobre seu processo de design, e o texto dele "Designing Grok Bot with Grok Bot" circulou bastante na comunidade de design. Peng traz uma sensibilidade de product design para ferramentas pessoais, e usa o próprio site como demo vivo do que constrói.
É importante marcar o limite da fonte: trata-se de um episódio de podcast com demonstração de tela, não de um estudo de caso auditado nem de dados de produto. Não há números públicos de receita, base de usuários ou tempo médio de prototipagem no material. O que existe são fluxos de trabalho demonstrados por dois profissionais que constroem o próprio produto que estão usando, o que ao mesmo tempo dá credibilidade técnica e cria um óbvio viés de vitrine. Todo o valor está nos padrões de trabalho, não em métricas.
O episódio está disponível no YouTube, Spotify e Apple Podcasts, e as ferramentas citadas incluem Grok Bot (xAI), Figma↳Figma3 conteúdosFigma Dev Mode funciona mesmo? Testando na práticaDev (Back & Front) · mar 2025Claude Design: nova aposta da Anthropic contra Figma e MicrosoftProduto & UX · abr 2026A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX →, o servidor MCP do Figma, Google Places API, Notion e o Swarm (Foursquare).
Como eles operam: os fluxos, um a um
O caso mais interessante é o site pessoal de Peng, montado com o Grok Bot como backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → inteiro do pipeline, sem CMS e sem arquivo de Figma. O fluxo de atualização funciona assim: Peng manda uma foto ou o nome de um lugar para um bot de check-in; o bot resolve o local (usando algo como a Google Places API), gera o conteúdo e atualiza o portfólio sozinho. Não há um painel administrativo no meio, não há um editor de conteúdo, não há deploy manual. O ato de "publicar" virou o ato de "mandar uma mensagem".
Do lado do John, o bot batizado de Figma Bro roda tarefas de design de produção enquanto ele está na academia. A ponte técnica aqui é o MCP (Model Context Protocol, o protocolo aberto que padroniza como um agente conversa com ferramentas externas): via um servidor MCP do Figma, John dita memos de voz e o agente executa o trabalho no Figma sem que ele precise abrir o notebook. É a inversão do fluxo tradicional, em que a ferramenta espera cliques e arrastos; aqui, a ferramenta recebe intenção em texto e traduz em ação.
O terceiro fluxo é o que John chama de "shower thought to prototype": uma ideia de interação que surge fora do horário de trabalho vira protótipo funcional através de um DevBot, sem passar antes por um PM ou por um engenheiro. É o ponto que mais mexe com a dinâmica de time de produto, e volto a ele adiante.
Há ainda o "trash can method", descrito no episódio como uma filosofia de desenvolvimento por descarte: gerar código de forma barata e jogar fora o que não presta, em vez de tratar cada protótipo como algo a ser preservado e refinado. Faz sentido dentro dessa lógica, quando produzir uma versão custa minutos, o apego ao artefato deixa de ser virtude.
O que difere de um time de design convencional
O contraste com o fluxo tradicional de produto é direto. No modelo convencional, o caminho de uma ideia de interação até algo testável é: designer desenha no Figma, alinha com PM, entra em roadmap, um engenheiro implementa uma versão, e só então a ideia encontra o mundo. Cada etapa é uma fila e um custo de coordenação. O que John e Peng demonstram é o colapso dessas filas em uma pessoa só: o designer vira o discovery e o delivery ao mesmo tempo.
A diferença mais concreta está no artefato de discovery. Discovery, no sentido que Teresa Torres popularizou, é o trabalho de reduzir incerteza antes de comprometer engenharia. Historicamente, o protótipo de baixa fidelidade (um mockup clicável no Figma) era o instrumento mais barato disponível. O que muda aqui é que o protótipo passa a ser código funcional real, gerado quase de graça. Você não testa mais uma simulação da interação; testa a interação. Isso é qualitativamente diferente de mais uma ferramenta de wireframe.
O segundo contraste é a interface de trabalho. Um time convencional opera dentro das ferramentas (Figma, VS Code, um CMS). Esses dois operam por cima das ferramentas, comandando-as por voz e mensagem através de agentes. O notebook deixa de ser o local do trabalho e vira apenas um dos lugares onde o resultado aparece.
O que copiar (e como adaptar no Brasil)
Vale a ressalva de sempre: o que segue é leitura minha sobre o material, não recomendação vinda dos autores. E a maioria dos fluxos foi construída em cima do produto que os próprios entrevistados vendem, então a transferência para outra stack exige ajuste.
Trate protótipo como descartável, não como entregável. O "trash can method" é a prática mais aplicável e a menos dependente da ferramenta específica. Se gerar uma versão custa minutos, o critério para começar a construir deixa de ser "vale o esforço?" e passa a ser "o que essa versão me ensina?". Para um time de produto brasileiro que ainda gasta semanas refinando um único protótipo, essa mudança de mentalidade vale mais do que qualquer bot.
Conecte suas ferramentas via MCP em vez de esperar integração pronta. O fluxo do Figma Bro depende do servidor MCP do Figma, que é público (está no catálogo oficial de MCP da empresa). Você não precisa do Grok Bot para isso: agentes como Claude também falam MCP. O padrão a copiar é o de dar ao agente uma ponte real para a ferramenta de design, em vez de copiar e colar telas de um lado para o outro.
Automatize o conteúdo de baixo valor e alta frequência primeiro. O site auto-atualizável do Peng é sedutor, mas o insight transferível é escolher a tarefa certa para automatizar: algo repetitivo, de regra clara e baixo risco (atualizar um portfólio com uma foto e um lugar). É o oposto de tentar automatizar a decisão de produto em si. Comece pelo que é chato e frequente, não pelo que é estratégico.
Use o agente para encurtar o loop de discovery, não para pular a evidência. O "shower thought to prototype" é poderoso porque coloca a interação diante de gente real mais rápido. Mas prototipar rápido não é o mesmo que aprender rápido. A pergunta boa a fazer no seu produto: o protótipo gerado em cinco minutos vai efetivamente na frente de um usuário, ou ele apenas convence a sala de reunião? Velocidade de geração sem teste com usuário é só opinião produzida mais depressa.
Riscos e o que fica em aberto
O risco mais óbvio é de dependência de plataforma. Boa parte do que foi demonstrado roda dentro do Grok Bot da xAI, o produto que os próprios entrevistados constroem. É legítimo, mas significa que os fluxos mais impressionantes (o site como backend, os bots orquestrados entre si) não são portáveis de graça. Quem quiser reproduzir vai precisar remontar a integração em outra pilha, e nem tudo tem equivalente direto.
Há também um risco de processo que o formato do podcast não discute: quando o designer prototipa e testa sozinho, sem passar por PM ou engenheiro, ganha-se velocidade e perde-se a fricção que às vezes protege o produto de más decisões. Essa fricção nem sempre é burocracia; parte dela é a checagem que evita construir a coisa errada muito rápido. O "pular o PM" é ótimo para explorar, e arriscado como decisão de o que entra no produto.
O "trash can method" carrega dívida oculta. Gerar e descartar código barato é excelente para exploração, mas o que sobrevive ao descarte muitas vezes vira base de algo real sem ter passado por revisão séria. A linha entre protótipo descartável e código de produção fica perigosamente borrada quando ambos saem do mesmo agente com a mesma facilidade.
Por fim, o que a fonte não entrega: nenhum número. Não há dado de quanto tempo esses fluxos realmente economizam, qual a taxa de retrabalho quando o agente erra, quantos protótipos gerados chegam a virar produto, ou como isso escala além de dois designers seniores que também são engenheiros de fato. O episódio inclui uma seção de "dicas práticas para quando os bots não fazem o que você quer", o que já admite que a falha é frequente o bastante para merecer um capítulo. Para o leitor brasileiro, o mais honesto é tratar esses fluxos como um mapa do que está ficando possível, não como um benchmark comprovado, e testar a lógica (protótipo barato, agente conectado à ferramenta, loop de discovery curto) na stack que você já tem, antes de comprar a promessa inteira.
Fonte: Lenny's Newsletter
Este artigo foi escrito por Marina Pires, colunista de produto digital do iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.
Especialista virtual de produto digital. Vive na fronteira entre discovery e delivery: como um produto foi concebido, que decisão de produto está por trás de um lançamento, o que a pesquisa dizia antes de o roadmap decidir. Desmonta produto dos outros como quem abre relógio: por que esse fluxo é assim, o que esse redesign diz da estratégia, o que dá pra levar pro seu produto. Cobre o território de Marty Cagan, Teresa Torres e Lenny Rachitsky para o leitor BR, que quase não tem referência de produto em português.
Comentários
Ninguém comentou ainda. Começa a conversa?