Codex + uma ferramenta secreta é o fluxo de trabalho de design que temos usado na nossa agência… e o resultado é genuinamente de outro nível.
Venho dizendo isso há meses. Se o seu app parece lixo de IA, o problema não é o Codex. É o fluxo de trabalho.
A maioria dos builders fica presa no mesmo ciclo. Eles lançam funcionalidades com IA. O backend funciona. A lógica é sólida. Mas a interface parece igual a todos os outros apps feitos no improviso. Os usuários decidem em dois segundos se aquilo parece real.
A solução antiga era contratar um designer. Esperar semanas pelos arquivos do Figma. Depois ver seu desenvolvedor interpretar esses designs e recriá-los em código. Quando o design finalmente entrava no ar, você já tinha perdido o ritmo e queimado dinheiro que não precisava queimar.
Esse processo inteiro agora é opcional.
Para este tutorial, construí o Haven, um conceito de app mobile para imobiliária. Sistema de design completo em 20 minutos. Cada tela projetada em menos de uma hora. Código de produção enviado pelo Codex sem reescrever uma única linha de CSS.
Este é o fluxo de trabalho que estou usando agora. E todo builder que entrega com IA precisa entender como ele funciona.
O Que o Moonchild Realmente É
A ferramenta secreta é o Moonchild.
Testei quase todas as ferramentas de design com IA lançadas no último ano. A maioria parece boa na primeira tela, mas desanda quando você cria uma segunda página. Consistência é o problema. O Moonchild resolve isso de um jeito que nada mais conseguiu.
É uma tela de design baseada em chat que começa a partir do seu sistema de design. Não de um prompt em branco. Não de uma captura de tela. Do seu sistema real. Você insere seu sistema de três formas:
→ Importe do Figma, GitHub ou uma URL ativa
→ Descreva sua marca para o Agentic Design System Builder
→ Coloque inspiração de design do Dribbble ou de qualquer outro lugar
Depois que o sistema está lá, você não cria prompts para designs do jeito antigo. Você cola um PRD. Ele gera telas completas alinhadas ao seu sistema. A partir daí, você faz a direção de arte.
E o caminho de exportação é o que fecha o ciclo. O Moonchild envia um conector MCP que entrega seus designs diretamente no Codex como saída estruturada. Não é uma captura de tela para o Codex interpretar. São os dados reais do design. Componentes, tokens, layout, tudo.
Esse é o fluxo de trabalho. Agora veja como usá-lo na prática.
O Problema de Como a Maioria dos Builders Usa IA para Design
Aqui está o que a maioria dos builders faz.
Eles pedem ao Codex para criar uma nova funcionalidade. Ele entrega. Fica ok. Depois pedem a próxima funcionalidade. Fica ligeiramente diferente. Na quinta funcionalidade, o app parece cinco produtos diferentes costurados.
É a isso que as pessoas se referem quando dizem que design com IA é ruim.
O modelo não é ruim. O fluxo de trabalho é.
O Codex não faz ideia de qual é a sua linguagem de design. Cada prompt é um contexto novo. Cada tela é um palpite. Cada componente se distancia do anterior. As cores mudam. A tipografia muda. Tudo se acumula.
A solução é simples. Dê ao Codex um sistema para seguir. Depois, dê a ele o design real para construir.
A maioria dos fluxos de trabalho dá um ou outro. O Moonchild mais a conexão MCP dá ambos ao mesmo tempo.
Passo 1: Construa Seu Sistema de Design Primeiro. Sempre.
Esta é a etapa que todo mundo pula. E também a mais importante.
Na @ignytlabs, construímos um sistema de design para cada cliente antes de tocar em qualquer tela. Antes, isso levava dois dias de um designer. O Moonchild faz isso em cerca de 20 minutos.
Para este tutorial, construí o Haven, um conceito de app mobile para imobiliária. Existem algumas formas de inserir um sistema de design no Moonchild. Você pode importar do Figma, GitHub ou uma URL ativa. Pode descrever sua marca para o Agentic Design System Builder. Para o Haven, fiz o que costumo fazer quando começo a partir de uma vibe. Inspiração de design do Dribbble. Coloquei três capturas de tela de apps imobiliários mobile que acertaram a sensação que eu buscava, além de uma breve descrição do que é o Haven e para quem ele é. A ferramenta extraiu a linguagem de design e construiu o sistema do zero.
O que me surpreendeu foi o quanto tudo é visualizável. A maioria das ferramentas de IA, incluindo o fluxo de trabalho do Google Stitch sobre o qual escrevi no meu último artigo, entrega um arquivo de token plano. Cores. Fontes. Talvez espaçamento. Isso aqui faz diferente. Constrói uma biblioteca completa de componentes e uma galeria. Cada badge, botão, card e chip renderizado do jeito que realmente vai aparecer dentro do seu app. Clique em qualquer componente e veja ele ao vivo, com controles para testar variantes e tamanhos. Logo abaixo da visualização, você tem o JavaScript, CSS, exemplos e dependências reais daquele componente. Pronto para puxar para o código.
A galeria é a parte que realmente muda a forma como você projeta. Em vez de adivinhar como um "badge de marca" ou "badge de avaliação" deve ficar no contexto, você vê todos lado a lado. Para Venda. Para Alugar. Destaque. A família toda de uma vez. Você toma decisões de design informadas antes que uma única tela seja gerada.
É a diferença entre uma folha de estilo e um sistema real.
Passo 2: Do PRD à Interface
Depois que seu sistema de design está definido, você não faz prompts para designs do jeito antigo.
Você cola um PRD.
Um brief de funcionalidade de uma página. Uma especificação de produto. Uma declaração de objetivo. O que você tiver.
Para o Haven, colei um PRD estruturado cobrindo a introdução do produto, os objetivos, os usuários-alvo e funções, as funcionalidades principais e o escopo do MVP, as jornadas completas do usuário, a stack técnica e a direção de design. Cerca de uma página. Específico o suficiente para dar contexto real à ferramenta. Estruturado o suficiente para puxar os detalhes certos para as telas certas.
Depois, fiz algo que a maioria das pessoas pula.
Eu debati com a ferramenta antes de gerar qualquer tela.
Essa é a chave que a maioria dos builders perde. O modo de chat mantém o contexto completo do PRD. Em vez de despejar o PRD e sair gerando, você conversa sobre o produto primeiro. Confirma a lista de telas. Define o padrão de navegação. Pré-determina a hierarquia das telas principais antes de qualquer pixel existir.
Para o Haven, perguntei:
→ "Com base neste PRD, quais telas você recomenda construirmos primeiro? Estou esquecendo algo para um app imobiliário?"
→ "A navegação principal deve ser uma barra inferior com Início, Busca, Favoritos, Perfil? Ou algo diferente?"
→ "Antes de gerar, me explique a ordem de prioridade da tela de Detalhes do Imóvel. Fotos primeiro, depois nome e preço, depois especificações, depois comodidades, depois corretor. Confirme ou melhore."
→ "Ok, agora prossiga e gere essas telas tanto no modo claro quanto no escuro, mantendo o sistema de design que tenho anexado. Certifique-se de completar toda a jornada do usuário e criar todas as telas."
Quando cliquei em gerar, a ferramenta já conhecia o produto melhor do que a maioria dos designers depois da primeira reunião com o cliente.
Agora, uma observação rápida sobre variantes. Leia isto com atenção.
Um recurso interessante: você pode criar diferentes variantes das suas telas. Só precisa mencionar explicitamente ao Moonchild, e ele cuida disso. Para o Haven, eu queria três direções estéticas diferentes para o app inteiro antes de me comprometer com uma. Aqui está o prompt exato que usei:
“Quero que você gere 3 conceitos completos de design de interface mobile para o Haven:
Conceito 1 - Editorial Aconchegante: Fundos creme, espaçamento generoso, títulos em serifa para nomes de imóveis, sombras suaves, tratamento de imagem no estilo revista.
Conceito 2 - Moderno Ousado: Modo escuro, alto contraste, sem serifa em tudo, cantos retos, foco em fotos com imagens de ponta a ponta.
Conceito 3 - Minimalista Premium: Paleta neutra (off-white, carvão, um único acento), tipografia refinada, bastante espaço, microinterações sutis.
Use o sistema de design conectado como base, mas deixe cada conceito puxar o sistema em uma direção estética diferente. Gere telas completas, não apenas seções. O que você fará?”
Perceba o "O que você fará?" no final. Esse é o pequeno detalhe que faz funcionar. Em vez de apenas gerar tudo cegamente, a ferramenta voltou com um plano.
Ela disse que construiria 5 telas representativas por conceito primeiro. Eu avaliaria as três direções lado a lado. Depois de escolher a que eu queria, ela seguiria e projetaria o app inteiro naquela direção.
Isso muda completamente a equação de custo. Você não está pagando por três builds completos. Está pagando por três amostras rápidas, depois um único build completo na direção que você realmente escolher.
Escolhi a editorial aconchegante. O conjunto completo de telas veio em seguida.
Agora, a parte que realmente me surpreendeu.
Cada tela que o Moonchild gera é interativa no modo de visualização. Não é um mockup estático. É realmente interativa.
Você pode clicar em campos de entrada. Tocar em botões. Navegar entre telas como um usuário real testando o protótipo antes de qualquer código ser escrito. Para o Haven, peguei dois problemas de fluxo na visualização que teriam ido para o Codex caso contrário. A tela de detalhes do imóvel não tinha um caminho óbvio de volta para a busca. O CTA de contatar o corretor estava muito abaixo da dobra. Ambos teriam ido para produção se eu tivesse entregue o design ao Codex sem navegar antes.
Essa é a chave. Você testa o produto antes de qualquer código ser escrito.
O ciclo de refinamento é a última peça.
Quando uma tela precisa de ajustes, você não refaz o prompt do zero. Você seleciona a tela, diz à ferramenta o que mudar, e ela gera uma v2 no lugar. Quer um hero mais cinematográfico? v2. Quer trocar um layout de cards por uma visualização em lista? v3. As variantes se acumulam para que você possa comparar e escolher a mais forte.
Para a tela de detalhes do imóvel do Haven, passei por três iterações. v1 tinha o bloco do corretor muito alto. v2 corrigiu a hierarquia, mas a galeria de fotos parecia pequena. v3 acertou ambos. Cerca de 8 minutos de idas e vindas.
Você não está selecionando a partir de uma tela em branco. Você está refinando uma direção real. Essa é a parte que mais se aproxima de trabalhar com um designer sênior.
Passo 3: Conecte o Moonchild ao Codex via MCP
É aqui que o fluxo de trabalho fica SENSACIONAL.
O sistema de design dá as regras ao Codex. A conexão MCP dá algo mais poderoso ao Codex: acesso direto à saída real do design. Não capturas de tela. Não descrições textuais do design. Dados de design estruturados que o Codex pode ler e recriar.
Aqui está a configuração:
→ Vá em Configurações do Moonchild, depois MCP
→ Copie o comando de instalação para sua configuração
→ Abra o Codex CLI
→ Cole o comando de instalação
→ Autentique-se com sua conta do Moonchild
→ Pronto
Uma vez conectado, o Codex vê tanto seu sistema de design quanto as telas específicas do Haven que você projetou.
Passo 4: O Codex Entrega o Código
Agora você dá um prompt ao Codex assim:
Busque o projeto Haven Real Estate Mobile App usando o MCP do Moonchild e me informe quais telas temos dentro dele.
Este primeiro prompt faz dois trabalhos. Confirma que o MCP está configurado corretamente. E dá ao Codex visibilidade total de cada tela que você projetou.
Uma dica rápida antes de deixar o Codex fazer algo mais pesado. Fique no modo de planejamento. O Codex mostra o que está prestes a fazer antes de executar. Leia o plano sempre. Certifique-se de que ele entende quais telas você quer, em qual ordem e com qual fidelidade. Essa é a diferença entre o Codex codificar o que você realmente precisa e o Codex codificar o que ele acha que você precisa.
Depois de revisar o plano e apontá-lo para a tela desejada, o Codex puxa os dados de design diretamente do Moonchild, consulta seu sistema de design e escreve o código. Ele ainda adiciona os estados de hover, transições e tratamento de bordas porque está trabalhando com dados de design reais, em vez de adivinhar a partir de um prompt.
O resultado: interface de nível de produção no seu código real, combinando exatamente com o design, em minutos.
Na @ignytlabs, costumávamos reservar duas semanas para design em cada MVP de cliente. Um designer criava o arquivo Figma. Um desenvolvedor interpretava. A interpretação se desviava. Nós corrigíamos. Ciclo. Com este fluxo de trabalho, o ciclo inteiro se reduz a uma única tarde de trabalho. Mesma qualidade. Margem maior. Muito menos mudança de contexto.
Quando Usar Este Fluxo de Trabalho
Este não é o fluxo de trabalho certo para toda equipe. Seja honesto sobre quando ele se encaixa.
Use quando:
→ Você está lançando MVPs como builder solo ou equipe pequena
→ A consistência do design continua quebrando entre telas
→ Você não quer manter um pipeline separado de Figma para designer para desenvolvedor
→ Você já tem um sistema de design e quer que ele seja aplicado em todos os lugares
Pule quando:
→ Você está em escala com uma equipe de design interna completa e uma biblioteca Figma madura
→ Você precisa de uma entrega perfeita de pixels para um site de marketing ou trabalho de marca onde cada sombra importa
→ Seu código tem padrões de UI altamente personalizados que exigem trabalho de design sob medida
Para 80% dos builders que lançam MVPs e produtos SaaS, este fluxo de trabalho cobre tudo que você precisa.
O Que Observar
Algumas bandeiras honestas antes de você sair usando.
A qualidade do seu sistema de design determina a qualidade da sua saída. Lixo entra, lixo sai. Um arquivo Figma pela metade com três tokens de cor vai produzir telas medíocres. Invista tempo no sistema desde o início. Ele se paga em cada tela.
A qualidade do PRD importa. Um brief vago gera telas genéricas. Um PRD específico com fluxos de usuário, casos de borda e hierarquia clara gera designs úteis. Isso não é uma limitação da ferramenta. É uma limitação de pensamento.
Você ainda precisa de bom gosto. A ferramenta produz. Você dirige. Escolher a variante certa e refiná-la é onde seu julgamento entra. Se você pular a etapa de curadoria, está de volta ao design por vibe.
Alguns componentes precisam de ajustes manuais. Estados animados complexos, padrões de interação personalizados, qualquer coisa fora do sistema de design precisa de uma passada manual no Codex. O MCP leva você a 90% do caminho. Os últimos 10% são seu gosto.
O Que Isso Realmente Significa
Aqui está minha opinião honesta.
O gargalo em lançar produtos construídos com IA nunca foi o código. A IA consegue escrever o código. O gargalo sempre foi a camada de design. A consistência, o bom gosto, o sistema que amarra tudo.
Esse gargalo acabou de cair.
Na nossa agência, costumávamos reservar duas semanas para design em cada MVP de cliente. Contratar um designer. Esperar pelos arquivos Figma. Ver o desenvolvedor interpretar. Ciclar. O que levava duas semanas agora leva dois dias. Mesma qualidade. Entrega mais rápida. Margem maior.
Este é o fluxo de trabalho que equipes com verba já têm com seus pipelines de Figma mais designer mais desenvolvedor. A diferença é que agora builders solo, agências independentes e pequenos estúdios conseguem a mesma alavancagem sem precisar de equipe.
2026 vai ser INJUSTO para agências e builders que descobrirem isso primeiro.
TLDR
→ Pare de culpar o Codex por UI ruim. O Codex não é o problema. Seu fluxo de trabalho é.
→ Passo 1: Construa seu sistema de design dentro do Moonchild. Importe do Figma, GitHub ou uma URL ativa. Ou descreva sua marca. Ou coloque inspiração do Dribbble, como fiz para o Haven.
→ Passo 2: Cole seu PRD. Debata no modo de chat antes de gerar. Defina a lista de telas e o padrão de navegação primeiro.
→ O padrão gera uma variante. Peça explicitamente várias variantes em telas hero com diferentes vibes especificadas.
→ Use a visualização interativa para testar o fluxo antes de qualquer código ser escrito. Refine telas com iterações v2, v3 no lugar.
→ Passo 3: Conecte o Moonchild ao Codex via MCP. Isso dá ao Codex dados reais de design, não capturas de tela.
→ Passo 4: Peça ao Codex para construir cada tela usando o MCP. UI de nível de produção é enviada em minutos.
→ A qualidade do seu sistema de design determina a qualidade da sua saída. Invista nele.
→ O ciclo de Figma para entrega para desenvolvedor está morto. Um fluxo de trabalho agora roda design e código juntos.
Bora.
