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 aplicativo parece um "AI slop", o problema não é o Codex. É o fluxo de trabalho.
A maioria dos builders está presa no mesmo ciclo. Eles entregam funcionalidades com IA. O backend funciona. A lógica é sólida. Mas a interface parece igual a todos os outros aplicativos criados com vibe code. Os usuários decidem em dois segundos se algo 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 embalo e queimado dinheiro que não precisava queimar.
Esse processo inteiro agora é opcional.
Para este guia, criei o Haven, um conceito de aplicativo mobile para imóveis. Sistema de design completo em 20 minutos. Todas as telas projetadas em menos de uma hora. Código de produção enviado através do 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 no momento em que você cria uma segunda página. Consistência é o problema. O Moonchild resolve isso de uma forma que nenhuma outra conseguiu.
É uma tela de design com 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:
→ Importando do Figma, GitHub ou uma URL ativa
→ Descrevendo sua marca para o Agentic Design System Builder
→ Adicionando inspiração de design do Dribbble ou de qualquer outro lugar
Depois que o sistema está configurado, você não cria designs do jeito antigo com prompts. Você cola um PRD. Ele gera telas completas com base no seu sistema. E você faz a direção de arte a partir daí.
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 de design. Componentes, tokens, layout, tudo.
Esse é o fluxo de trabalho. Agora, veja como usá-lo de verdade.
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. Parece ok. Depois pedem a próxima funcionalidade. Parece um pouco diferente. Na quinta funcionalidade, o app parece cinco produtos diferentes costurados.
É disso que as pessoas estão falando 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 chute. 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 com a conexão MCP dá os dois ao mesmo tempo.
Etapa 1: Construa Seu Sistema de Design Primeiro. Sempre.
Esta é a etapa que todo mundo pula. Também é a mais importante.
Na @ignytlabs, construímos um sistema de design para cada cliente antes de tocar em qualquer tela. Isso costumava levar dois dias para um designer. O Moonchild faz isso em cerca de 20 minutos.
Para este guia, criei o Haven, um conceito de aplicativo mobile para imóveis. Existem algumas formas de colocar 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. Adicionei três capturas de tela de apps mobile de imóveis que acertaram o estilo que eu buscava e 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 é o quão visualizável tudo é. A maioria das ferramentas de IA, incluindo o fluxo do Google Stitch sobre o qual escrevi no meu último artigo, entrega um arquivo de token simples. Cores. Fontes. Talvez espaçamento. Isso aqui faz algo diferente. Constrói uma biblioteca de componentes completa e uma galeria. Cada badge, botão, card e chip renderizado da forma como realmente ficará dentro do seu app. Clique em qualquer componente e você o vê ao vivo, com controles para testar variantes e tamanhos. Abaixo da visualização, você obtém o JavaScript, CSS, exemplos e dependências reais para aquele 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 "brand badge" ou "rating badge" deve parecer no contexto, você os vê todos lado a lado. For Sale. For Rent. Featured. A família inteira 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.
Etapa 2: Do PRD à Interface
Depois que seu sistema de design está configurado, você não cria designs do jeito antigo com prompts.
Você cola um PRD.
Um resumo de funcionalidades 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 que ela puxe os detalhes certos para as telas certas.
Depois, fiz algo que a maioria pula.
Eu pensei junto com a ferramenta antes de gerar uma única tela.
Esta é a vantagem que a maioria dos builders perde. O modo de chat mantém o contexto completo do PRD. Em vez de despejar o PRD e clicar em gerar, 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 de imóveis?"
→ "A navegação principal deve ser uma aba inferior com Home, Search, Favorites, Profile? Ou algo diferente?"
→ "Antes de gerar, explique a ordem de prioridade para a 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 modo 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 conheceria após a primeira reunião com o cliente.
Agora, uma observação rápida sobre variantes. Leia com atenção.
Um recurso interessante: você pode criar diferentes variantes das suas telas. Basta mencionar explicitamente ao Moonchild que ele cuidará 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 UI mobile para o Haven:
Conceito 1 - Editorial Aconchegante: Fundos creme, espaçamento generoso, serifa para títulos de imóveis, sombras suaves, tratamento de imagem no estilo revista.
Conceito 2 - Moderno Ousado: Modo escuro, alto contraste, sans-serif 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 destaque), 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ê vai fazer?”
Repare no "O que você vai fazer?" no final. Esse é o pequeno detalhe que faz funcionar. Em vez de simplesmente gerar tudo cegamente, a ferramenta voltou com um plano.
Ela disse que construiria 5 telas representativas por conceito primeiro. Eu revisaria as três direções lado a lado. Depois que escolhesse a que queria, ela iria e projetaria o app inteiro nessa 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, e 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 interativo.
Você pode clicar em campos de entrada. Tocar em botões. Navegar entre as 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. A tela de detalhes do imóvel não tinha uma forma óbvia de voltar para a busca. O CTA de contatar o corretor estava muito abaixo da dobra. Ambos teriam ido se eu tivesse entregue o design ao Codex sem navegar antes.
Essa é a vantagem. 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 faz um novo prompt do zero. Você seleciona a tela, diz à ferramenta o que mudar, e ela gera uma v2 no lugar. Quer um herói mais cinematográfico? v2. Quer trocar um layout de cartão por uma visualização em lista? v3. As variantes se acumulam para que você compare e escolha a mais forte.
Para a tela de detalhes do imóvel do Haven, passei por três iterações. A v1 tinha o bloco do corretor muito alto. A v2 corrigiu a hierarquia, mas a galeria de fotos parecia pequena. A v3 acertou ambas. Cerca de 8 minutos de idas e vindas.
Você não está selecionando a partir de uma tela em branco. Está refinando uma direção real. Esta é a parte que mais se aproxima de trabalhar com um designer sênior.
Etapa 3: Conecte o Moonchild ao Codex via MCP
É aqui que o fluxo de trabalho fica INCRÍVEL.
O sistema de design dá ao Codex as regras. A conexão MCP dá ao Codex algo mais poderoso: acesso direto à saída real do design. Não capturas de tela. Não descrições textuais do design. São 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.
Etapa 4: O Codex Entrega o Código
Agora você cria um prompt para o 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 todas as vezes. 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, referencia seu sistema de design e escreve o código. Ele até adiciona estados de hover, transições e tratamento de casos extremos porque está trabalhando com dados reais de design, 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 orçar duas semanas para design em cada MVP de cliente. Um designer criava o arquivo Figma. Um desenvolvedor o interpretava. A interpretação se desviava. 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 todas as equipes. Seja honesto sobre quando ele se encaixa.
Use quando:
→ Você está entregando 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 transferência 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 entregam MVPs e produtos SaaS, este fluxo de trabalho cobre tudo que você precisa.
O Que Observar
Alguns alertas honestos antes de você colocar isso em prática.
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 produzirá telas medíocres. Invista tempo no sistema desde o início. Ele se paga em cada tela.
A qualidade do PRD importa. Um resumo vago gera telas genéricas. Um PRD específico com fluxos de usuário, casos extremos 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, volta a projetar 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 chega a 90% do caminho. Os 10% finais são seu bom gosto.
O Que Isso Realmente Significa
Aqui está minha opinião honesta.
O gargalo em entregar produtos criados com IA nunca foi o código. A IA pode escrever o código. O gargalo sempre foi a camada de design: a consistência, o bom gosto, o sistema que une tudo.
Esse gargalo acabou de desabar.
Na nossa agência, costumávamos orçar duas semanas para design em cada MVP de cliente. Contratar um designer. Esperar pelos arquivos Figma. Ver o desenvolvedor interpretar. Ciclo. O que costumava levar duas semanas agora leva dois dias. Mesma qualidade. Entrega mais rápida. Margem maior.
Este é o fluxo de trabalho que equipes com financiamento já têm com seus pipelines de Figma + designer + desenvolvedor. A diferença é que agora builders solo, agências independentes e pequenos estúdios conseguem a mesma vantagem sem precisar de mais funcionários.
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 é.
→ Etapa 1: Construa seu sistema de design dentro do Moonchild. Importe do Figma, GitHub ou uma URL ativa. Ou descreva sua marca. Ou adicione inspiração do Dribbble como fiz para o Haven.
→ Etapa 2: Cole seu PRD. Pense junto 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 múltiplas variantes em telas principais com diferentes estilos especificados.
→ 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.
→ Etapa 3: Conecte o Moonchild ao Codex via MCP. Isso dá ao Codex dados reais de design, não capturas de tela.
→ Etapa 4: Crie um prompt para o Codex construir cada tela usando o MCP. Interface de nível de produção é entregue 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.
Vamos nessa.
