Do Design ao Código com IA: Claude Code Muda Tudo
Algo mudou num workshop recente. Já participei de revisões de design, planejamentos de sprint e sessões de handoff entre designers e desenvolvedores o suficiente para saber quando uma mudança no fluxo de trabalho é cosmética — e quando é estrutural. Essa foi estrutural.
Diane, CEO e cofundadora do The Design Project, tinha o Cursor aberto à esquerda, o Figma à direita e o Claude Code rodando entre os dois. Ela digitou um prompt — "redesenhe essa UI como um designer de produto de classe mundial faria" — e assistiu a IA ler todo o codebase, esboçar seu plano, fazer uma pergunta de esclarecimento e então começar a modificar arquivos.
Sem documento de handoff. Sem mockup anotado. Sem ticket no Jira parado no backlog de um desenvolvedor por duas semanas. Apenas uma designer gerando código front-end real através de uma IA que entendia o contexto do projeto.
Fiquei processando essa imagem por um bom tempo. Porque o que eu estava assistindo não era um hack de produtividade — era o fluxo de trabalho de design-para-desenvolvimento começando a se dissolver. E acho que a maioria dos times de produto ainda não sentiu isso, mas vai sentir.
Aqui está o que eu tirei daquela sessão, filtrado pela minha própria experiência construindo com Claude Code. Vou ser honesto sobre onde esse fluxo de trabalho realmente muda as coisas e onde as limitações atuais vão te pegar se você não tiver cuidado.
Tem um momento específico na seção de implementação que reformulou como eu penso sobre o modo de planejamento da IA. Guarde isso enquanto lê.
O Fluxo de Trabalho Antigo Já Estava Quebrando Antes da IA Aparecer
Deixa eu descrever o handoff de design para desenvolvimento que a maioria dos times conhece. Um designer termina os mockups no Figma. Anota espaçamentos, tamanhos de fonte, estados de interação, hover states. Agenda uma reunião de handoff. O desenvolvedor faz perguntas que as anotações não cobriram. Rola um vai e volta. Um sprint começa. O desenvolvedor constrói algo que chega perto — mas não exatamente. Tem um ciclo de revisão. Mais vai e volta. Eventualmente algo é lançado que corresponde a 80% do que foi originalmente projetado.
Soa familiar?
O problema não são as pessoas. Designers são bons no que fazem. Desenvolvedores são bons no que fazem. O problema é a camada de tradução entre eles — a lacuna onde a intenção se perde, suposições são feitas e o contexto evapora durante o handoff. Mesmo com Zeplin, InVision ou o modo de desenvolvedor do Figma, você ainda está movendo uma representação estática de um design para um meio que precisa de código dinâmico, responsivo e com estado.
O que o Claude Code faz — e o que a Diane demonstrou claramente — é colapsar essa camada de tradução.
Quando você dá ao Claude Code um prompt de design e o deixa operar em um codebase real, ele não está adivinhando a implementação a partir de um screenshot. Ele lê a estrutura de código existente, entende a hierarquia de componentes, sabe o que já existe e gera mudanças que se encaixam na arquitetura existente. Isso é algo qualitativamente diferente da geração genérica de código.
A distinção importa. Geradores de código genéricos produzem código que pode parecer certo mas não se encaixa no seu projeto. Claude Code — trabalhando em contexto — produz código que se encaixa no que você já construiu.
Mas antes de entrarmos em como isso funciona na prática, você precisa entender o stack de ferramentas específico que a Diane usou e por que cada escolha importa.
O Stack de Três Ferramentas que Realmente Funciona Junto
O workshop se centrou em três ferramentas trabalhando em conjunto. Já usei as três de forma independente. Vê-las combinadas num fluxo de trabalho deliberado me esclareceu por que essa combinação específica é mais do que a soma das partes.
Cursor como ambiente inicial. Cursor é um editor de código construído sobre o VS Code, com capacidades de IA integradas no nível do IDE em vez de adicionadas como extensão. Para designers entrando num ambiente de programação pela primeira vez, isso importa enormemente. A interface é familiar o suficiente para navegar, o terminal é acessível sem ser intimidante, e clonar um repositório é direto pela interface gráfica.
Para o workshop, Diane clonou o LLM Council do Andrej Karpathy — um projeto open-source que permite consultar múltiplos modelos de IA simultaneamente, com esses modelos avaliando as respostas uns dos outros. A escolha do projeto foi inteligente. É um codebase real, de qualidade de produção, com uma estrutura não trivial, não um app tutorial de brinquedo. Trabalhar com algo real é a única forma de testar se um fluxo de trabalho realmente se sustenta.
Claude Code como camada de inteligência. Essa é a parte que mais me interessa — e a parte onde tenho mais experiência direta para comparar.
Claude Code não apenas gera código a partir de uma descrição. Ele lê. Começa escaneando o README, entendendo a estrutura do projeto, identificando dependências, verificando o que já está instalado. Num repositório recém-clonado, ele cuida da instalação de dependências, configuração do ambiente e coloca o projeto rodando antes de tocar num único elemento de design.
Esse entendimento contextual é o que os geradores de código genéricos não conseguem. Quando a Diane pediu ao Claude Code para redesenhar a UI do LLM Council, ele não gerou um componente novo do zero esperando que ela o integrasse. Ele modificou os componentes existentes, na estrutura de arquivos existente, usando os padrões de estilo existentes — enquanto aplicava a direção de design que ela especificou.
Figma MCP para sincronização bidirecional. O Figma MCP (Multi-Component Plugin) é a ponte entre design e código que torna esse fluxo de trabalho bidirecional. Depois que o Claude Code gera mudanças de UI em código, essas mudanças podem sincronizar de volta para o Figma — dando aos designers uma forma de continuar refinando na camada de design sem redesenhar manualmente o que foi gerado. Edições feitas no Figma podem então voltar para o codebase.
A ressalva honesta aqui: essa sincronização bidirecional é genuinamente impressionante em conceito e imperfeita em execução no momento. O mapeamento de tokens, convenções de nomenclatura de componentes e comportamento responsivo não se traduzem perfeitamente em nenhuma direção. O workshop da Diane expôs exatamente isso — troubleshooting ao vivo, limitações visíveis, uma demonstração em tempo real de que isso ainda não é um problema resolvido. Voltarei a isso na seção de limitações reais.
Modo de Planejamento — A Parte que a Maioria Pula
Esse é o momento que mencionei no início e que reformulou como eu uso o Claude Code.
Quando a Diane pediu ao Claude Code para redesenhar a UI, ela não simplesmente disparou o prompt e esperou o código. Ela o deixou rodar primeiro no modo de planejamento.
O modo de planejamento é a fase do Claude Code onde ele esboça o que pretende fazer antes de fazer qualquer coisa. Ele lê os arquivos relevantes, identifica o que precisa mudar, mapeia a sequência de modificações e — criticamente — faz perguntas de esclarecimento se o prompt deixa margem para interpretação.
Isso não é pouca coisa. A maioria dos desenvolvedores que eu vi usando ferramentas de programação com IA pula direto para a execução. Disparam um prompt, recebem código, rodam, veem que quebra, disparam outro prompt para corrigir e acabam num loop de correção vai e volta que consome mais tempo do que simplesmente escrever o código eles mesmos.
O modo de planejamento quebra esse padrão. Quando a IA esboça sua abordagem primeiro, você pega mal-entendidos no nível do plano — antes de qualquer mudança no código. "Estou planejando modificar o componente Header e adicionar um novo esquema de cores ao Tailwind config" é algo que você pode avaliar e redirecionar em trinta segundos. Descobrir que a IA modificou o componente errado depois do fato te custa dez minutos de debugging e rollback.
Pela linha do tempo do workshop, essa sequência de planejamento-e-execução aconteceu entre os minutos 15 e 20 — o segmento onde os participantes tiveram mais momentos de "ahá". Assistir a IA fazer uma pergunta de esclarecimento sobre a paleta de cores antes de tocar no CSS tornou a deliberação visível de uma forma que uma simples demonstração de antes/depois não consegue.
Minha própria experiência se alinha com isso. Num projeto recente, usei o modo de planejamento do Claude Code para redesenhar um componente de tabela de dados. O plano revelou que meu prompt era ambíguo sobre paginação — o novo design deveria manter a paginação do lado do servidor ou mudar para paginação do lado do cliente? Cinco segundos para esclarecer. O código resultante ficou correto na primeira tentativa. Sem o modo de planejamento, eu teria recebido código que assumia uma abordagem, teria descoberto o problema ao testar e teria gasto tempo corrigindo.
Trate o modo de planejamento como obrigatório, não opcional. Os noventa segundos extras que ele adiciona no início economizam múltiplos desse tempo em cada etapa seguinte.
Passo a Passo do Fluxo de Trabalho do Workshop
Deixa eu reconstruir o fluxo de trabalho que a Diane demonstrou, com o tipo de detalhe de implementação que é útil se você quiser replicar.
Passo 1: Clonar o repositório no Cursor.
# In Cursor's integrated terminal
git clone https://github.com/karpathy/llm-council.git
cd llm-council
Para designers que nunca usaram um terminal, a interface gráfica do Cursor torna isso menos hostil. Você também pode usar a paleta de comandos do Cursor para clonar — sem precisar do terminal.
Passo 2: Deixar o Claude Code ler e configurar o projeto.
Abra o Claude Code e dê contexto antes de pedir qualquer coisa relacionada a design:
Read the README.md file thoroughly. Understand the project structure,
what this application does, and what dependencies it needs. Then install
the dependencies and tell me what I need to set up to run this locally.
O Claude Code vai escanear o README, identificar o stack (no caso do LLM Council, um backend em Python com um frontend em JavaScript), instalar as dependências pelo gerenciador de pacotes especificado e apontar qualquer configuração faltante — como variáveis de ambiente.
Passo 3: Criar o arquivo .env.
O LLM Council, como a maioria dos projetos reais, precisa de API keys para funcionar. O Claude Code vai te dizer exatamente quais variáveis são necessárias. Crie o arquivo .env na raiz do projeto:
# .env — never commit this file
ANTHROPIC_API_KEY=your_key_here
OPENAI_API_KEY=your_key_here
O Claude Code cuida de apontar o que é necessário. Você fornece as chaves reais. Essa é a divisão de trabalho correta — a IA gerencia a forma da configuração, você gerencia os segredos.
Passo 4: Rodar o projeto e verificar se funciona.
# Start the backend
python app.py
# In a separate terminal, start the frontend
npm run dev
O Claude Code vai te dar os comandos exatos baseado no que leu dos scripts do projeto. Uma vez que o app está rodando localmente e você consegue ver a UI original, está pronto para pedir mudanças de design.
Passo 5: Pedir mudanças de design usando o modo de planejamento.
Esse é o passo crítico. Estruture seu prompt de design para invocar o modo de planejamento explicitamente:
Before making any changes, enter planning mode. I want to redesign
this application's UI as a world-class product designer would. The
current UI is functional but visually sparse. I want:
- A dark, modern color scheme
- Improved typography hierarchy
- Better spacing and visual rhythm
- Clear visual separation between model responses
Plan your approach first. List every file you intend to modify and
why. Ask me any clarifying questions before you start.
A resposta da IA será um esboço — algo como: "Estou planejando modificar o App.css para o esquema de cores global, atualizar o ModelResponse.jsx para o layout dos cards de resposta, ajustar o Tailwind config para valores de espaçamento personalizados. Pergunta: devo preservar a estrutura de componentes existente ou propor uma reorganização?"
Você responde a pergunta. Depois aprova o plano. Então a execução acontece.
Passo 6: Sincronizar com o Figma usando MCP.
Uma vez que as mudanças no código estão ativas e você está satisfeito com a direção, o plugin Figma MCP permite puxar essas mudanças de código para um arquivo do Figma. Na prática, isso gera frames no Figma que aproximam o que o código renderiza — útil para compartilhar com stakeholders ou continuar a iteração de design no Figma.
Passo 7: Fazer edições no Figma e enviar de volta para o código.
Ajustes pixel-perfect costumam ser mais fáceis no Figma do que em CSS. Faça essas edições no Figma, depois use o MCP para exportar as mudanças como modificações de código. O Claude Code pode então incorporá-las ao codebase existente.
Passo 8: Fazer commit e push das suas mudanças.
# Stage your changes
git add -A
# Commit with a meaningful message
git commit -m "redesign: apply modern dark theme to LLM Council UI"
# Push to your fork
git push origin main
Se você fez fork do projeto para fazer mudanças independentes — que foi o que a Diane recomendou — esse push vai para o seu fork pessoal no GitHub. A partir daí você tem a opção de abrir um pull request para o projeto original se as mudanças valerem a pena contribuir.
Se você acompanhou mentalmente esse fluxo de trabalho, já entende algo que a maioria das pessoas leva três tentativas para compreender: a IA não está projetando por você. Ela está implementando uma direção que você especifica. A qualidade do que você obtém depende quase inteiramente da qualidade de como você formula seu prompt. E é exatamente por isso que a fase de planejamento existe.
Agora, a parte honesta.
O que o Workshop Acertou Sobre as Limitações
A Diane não apresentou isso como um fluxo de trabalho resolvido. Essa foi a parte que mais apreciei na sessão.
A integração com o Figma MCP revelou limitações reais ao vivo na tela. Inconsistências na nomenclatura de componentes entre o codebase e o Figma significam que o que é importado para o Figma nem sempre se mapeia de forma limpa aos componentes do seu sistema de design existente. A gestão de tokens — design tokens para cor, espaçamento e tipografia — não sincroniza de forma confiável em nenhuma direção ainda. Você consegue uma aproximação razoável de código para Figma, mas "sincronização bidirecional pixel-perfect" é linguagem de marketing aspiracional, não uma descrição precisa de onde as ferramentas estão hoje.
O problema dos tokens é o que eu acho mais frustrante na prática. Se seu codebase usa um Tailwind config personalizado com tokens de cor nomeados, e seu arquivo do Figma tem um sistema de design correspondente, você esperaria que a sincronização preservasse esses nomes. Frequentemente não preserva. Você acaba com valores hexadecimais em vez de nomes de tokens, e overrides de componentes em vez de instâncias de componentes. Corrigir isso manualmente anula boa parte da economia de tempo.
Minha opinião honesta: trate a sincronização de Figma para código e de código para Figma como um passo de "próximo o suficiente para continuar", não como um passo "precisamente exato". Use para comunicar direção e chegar perto do design certo. Não espere que substitua a disciplina meticulosa do sistema de design.
A outra limitação que vale mencionar: a janela de contexto do Claude Code. Em codebases grandes — dezenas de milhares de linhas distribuídas em dezenas de arquivos — o Claude Code pode perder o rastro do contexto do projeto no meio de uma sessão. A fase de planejamento mitiga isso em certa medida, porque o plano funciona como âncora. Mas em projetos muito grandes, você vai notar a IA fazendo sugestões que contradizem decisões anteriores na mesma sessão. Quando isso acontecer, reestabelecer o contexto com um prompt de resumo geralmente o coloca de volta nos trilhos.
Nenhuma dessas limitações torna o fluxo de trabalho menos valioso. Elas o tornam um fluxo de trabalho que requer uma mão experiente para perceber as lacunas — que é exatamente o que a sessão da Diane demonstrou. Ela encontrou o problema do MCP ao vivo e lidou com ele explicando o que estava acontecendo e por quê. Esse é o modelo certo: entender os limites da ferramenta, trabalhar dentro deles e não deixar os casos extremos te distraírem do que o fluxo de trabalho faz bem.
O que Isso Realmente Muda para Times de Produto
O workshop dedicou seu Q&A final a uma pergunta que considero a mais interessante: o que acontece com os papéis quando isso se tornar mainstream?
O enquadramento da Diane: as fronteiras entre Product Managers, designers e engenheiros estão se tornando difusas. PMs estão prototipando diretamente. Designers estão escrevendo — ou pelo menos gerando — código. Engenheiros continuam focados em engenharia, mas se envolvem mais com decisões de design e PRDs mais cedo no processo.
Já vi isso começar a acontecer em times com os quais trabalhei, e acrescentaria algumas nuances.
A difusão é real. Mas não é uniforme. O que ferramentas de IA como o Claude Code permitem é que especialistas possam avançar mais em territórios adjacentes sem se tornarem generalistas. Uma designer sem experiência em programação agora pode gerar um protótipo funcional, avaliá-lo no navegador, iterar sobre ele e compartilhar algo mais próximo do final do que qualquer mockup. Isso não a torna engenheira. A torna alguém cujas decisões de design agora são informadas por como o código em execução realmente se comporta.
O efeito downstream: as revisões de design mudam. Em vez de revisar um mockup estático no Figma e imaginar como vai ficar no navegador, você está revisando algo com o qual pode realmente interagir. O feedback se torna mais específico, mais fundamentado e mais acionável. "Esse botão parece pequeno no celular" substitui "Não tenho certeza sobre esse botão" — porque você pode testar no celular antes da revisão.
Para os engenheiros, a mudança é mais sutil mas igualmente real. Quando designers chegam ao handoff com código funcional em vez de mockups, a conversa de engenharia muda de "podemos construir isso?" para "como tornamos isso pronto para produção?" Essa é uma conversa melhor. Ela pula a camada de tradução completamente.
A habilidade cross-funcional que se torna essencial — e eu encorajaria qualquer pessoa em times de produto a desenvolver — é saber como formular prompts. Não como programar. Não como projetar. Como articular intenção com clareza suficiente para que uma IA possa executá-la com precisão. Isso é uma disciplina. Requer prática. As pessoas que a desenvolverem cedo terão uma vantagem significativa sobre aquelas que tratam ferramentas de IA como caixas mágicas.
Meus Resultados Depois de Aplicar Este Fluxo de Trabalho
No fim de semana após assistir esse workshop, apliquei o fluxo de trabalho de design para código num projeto de um cliente — uma aplicação de dashboard que estava num limbo de design há três semanas porque o designer e o desenvolvedor não conseguiam se alinhar na estrutura de componentes.
Clonei o codebase existente no Cursor, dei ao Claude Code contexto sobre o projeto e então pedi que gerasse o layout do dashboard que a designer tinha criado no Figma. O modo de planejamento revelou uma pergunta imediata: o novo layout deveria usar a estrutura existente de CSS modules ou mudar para Tailwind? Uma clarificação. O plano se atualizou. A execução começou.
Quarenta e cinco minutos depois, o desenvolvedor tinha um protótipo funcional no navegador que correspondia a 85% do mockup do Figma. Não pixel-perfect. Mas próximo o suficiente para que a conversa de revisão restante fosse sobre ajustes específicos em vez de questões de alinhamento fundamental. Lançamos a primeira versão dois dias depois.
Comparado com o sprint onde isso estava parado: três semanas vs. dois dias.
A versão honesta: os 15% de diferença ainda precisaram de edição manual. A sincronização do Figma MCP adicionou cerca de trinta minutos de limpeza para atualizar o arquivo do Figma e refletir o que realmente estava no código. E a primeira tentativa do Claude Code nos componentes de visualização de dados precisou de um segundo prompt para acertar o comportamento responsivo em telas menores. Nada disso foi surpreendente. Tudo foi mais rápido que a alternativa.
O que medir se você tentar isso: tempo desde a aprovação do design até o protótipo funcional (meta: menos de 4 horas para uma única funcionalidade), número de ciclos de revisão de design antes do handoff para o desenvolvedor (meta: 1, não 3), e com que frequência a intenção do design sobrevive intacta ao handoff (registre as discrepâncias entre a especificação de design e a funcionalidade entregue — elas devem diminuir).
Uma Coisa para Fazer Antes do Seu Próximo Handoff de Design
Escolha uma funcionalidade. Uma — não todo o seu sistema de design, não um redesign completo de página. Um único componente ou seção que está parado no Figma esperando desenvolvimento.
Clone seu codebase no Cursor. Abra o Claude Code. Dê contexto sobre o projeto, depois peça para implementar o design a partir da sua descrição do Figma. Use o modo de planejamento. Deixe a IA fazer suas perguntas. Aprove o plano. Observe o que acontece.
Você vai obter um resultado imperfeito. Tudo bem. O objetivo desse exercício não é lançar a partir do primeiro prompt. O objetivo é ver quão grande é realmente a sua lacuna atual entre design e desenvolvimento, e sentir como é iterar em código em vez de mockups.
Os times que vão construir os melhores produtos nos próximos três anos não são os que têm mais designers ou mais desenvolvedores. São os que descobriram como transformar design e desenvolvimento numa única conversa contínua, acelerada por IA — com o Claude Code rodando em algum lugar no meio.
O documento de handoff tradicional teve uma boa fase. Seu substituto já está aqui.
🤝 Vamos Trabalhar Juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- 🔗 Fiverr (builds e integrações personalizadas): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (soluções empresariais): ramlit.com
- 🎨 ColorPark (design e branding): colorpark.io
- 🛡 xCyberSecurity (serviços de segurança): xcybersecurity.io
