Figma to code: por que o resultado é visualmente correto e estruturalmente errado

Um frame do Figma é uma árvore de formas com posições, preenchimentos, traços, sequências de texto e restrições de layout. Isso é uma descrição completa de como algo se parece em um determinado tamanho. Não é uma descrição do que aquilo é.

Cada linha na coluna da direita é uma decisão que o conversor precisa tomar sem ter informações. Ele tomará cada decisão de forma plausível e independente, e é por isso que o resultado é, simultaneamente, convincente à primeira vista e impossível de manter.

Aceitar o resultado como ele é traz quatro problemas específicos, todos os quais surgem após o merge do código, e não durante a revisão.

1. 1

   Ausência de reuso de componentes

   O mesmo card convertido em cinco telas torna-se cinco implementações independentes. Nada as vincula, portanto, uma alteração no card exige cinco alterações, e alguém acabará encontrando apenas quatro.

2. 2

   Valores literais em todo lugar

   Os conversores emitem #6b7280 porque é isso que o preenchimento indica. Sua camada de tokens é totalmente ignorada, o que significa que o design system que você construiu torna-se meramente decorativo nessas telas.

3. 3

   Layout absoluto ou frágil

   Dados de posição são convertidos em posicionamento. O resultado corresponde ao frame exatamente na largura do frame e degrada em qualquer outra, sendo a degradação pior nos dispositivos que você menos testou.

4. 4

   Ausência de semântica

   Textos grandes e pesados tornam-se div estilizadas. Leitores de tela encontram uma página sem estrutura de cabeçalhos, usuários de teclado não encontram marcos de navegação, e ninguém percebe até que ocorra uma auditoria.

A mudança de perspectiva produtiva é parar de pedir para a ferramenta escrever código e começar a dizer a ela qual código já existe. O Code Connect do Figma faz exatamente isso: ele vincula um componente de design ao seu componente de código real, para que o Dev Mode exiba o componente real e suas props, em vez de CSS gerado.

Isso muda o problema de geração para busca, e a busca é um problema que pode ser resolvido corretamente.

Essa última linha é o custo real, e ele existe: o mapeamento só funciona para componentes que já existem. Um design genuinamente novo ainda precisa ser construído. Mas essa é a divisão correta de trabalho — um humano ou um agente constrói o novo componente uma vez, e cada uso subsequente é uma referência, não uma regeneração.

Vale a pena ser concreto sobre o alvo do mapeamento. Um handoff está concluído quando o lado do código se parece com isto — papéis nomeados com valores reais — em vez de uma lista de hexadecimais recuperados de um frame:

Abaixo do mapeamento de componentes, existe uma mudança mais simples que elimina uma quantidade surpreendente de lacunas, e que não exige ferramenta alguma: use os mesmos nomes em ambos os lugares.

O SLDS 2 da Salesforce é o exemplo publicado mais claro. Sua biblioteca do Figma utiliza os mesmos nomes de hooks de estilização semântica que o CSS — os próprios exemplos da equipe são radius-border-4 e font-scale-4 — portanto, os designs mapeiam um para um com o código real. O objetivo declarado deles é um vocabulário compartilhado que une design e desenvolvimento.

O efeito é que toda uma categoria de bugs de handoff deixa de existir. Quando um designer diz font-scale-4 e um desenvolvedor digita font-scale-4, não há etapa de tradução, logo não há espaço para perda de significado. Compare isso com um estilo do Figma chamado "Heading / Large" mapeado para uma variável CSS chamada --text-2xl: cada handoff é uma consulta, e cada consulta pode dar errado.

Muitas equipes possuem uma biblioteca do Figma completa e uma base de código que a reflete apenas parcialmente. O instinto é procurar uma ferramenta que feche essa lacuna automaticamente. Existe uma alternativa mais barata que funciona melhor.

Uma biblioteca do Figma contém as decisões — a escala, as funções, o conjunto de componentes, o ritmo de espaçamento. Essas decisões são transferidas perfeitamente como texto, e o texto é o formato com o qual tanto um desenvolvedor quanto um agente de código podem trabalhar. Extraí-las para um arquivo de tokens e um brief escrito leva um dia de trabalho e torna qualquer conversão subsequente desnecessária, pois o lado do código agora possui a mesma informação que o lado do design.

Analisamos 299 arquivos DESIGN.md escritos para levar exatamente essas informações a agentes de IA, e a maioria não o faz: 86% especificam cores como hex raw sem função semântica, 76% não declaram proibições, 69% não definem modo escuro e 44% não declaram nenhum valor de tamanho concreto em lugar nenhum. Um brief extraído de uma biblioteca real do Figma, feito corretamente, supera quase todos eles — você já tem os números.

1. 1

   Exporte as variáveis como tokens, com funções

   Não a paleta bruta. As funções: qual cor é texto suavizado, qual é borda, qual é um estado desativado. Se suas variáveis do Figma são nomeadas por matiz, este é o momento de renomeá-las por função em ambos os lugares simultaneamente.

2. 2

   Anote as escalas como números

   Tamanhos de fonte, etapas de espaçamento, raios. A biblioteca já contém isso; o lado do código geralmente tem um subconjunto somado a improvisações.

3. 3

   Anote o que a biblioteca se recusa a fazer

   As proibições estão na biblioteca implicitamente — sem sombras em lugar nenhum, sem peso acima de 600 — e são a coisa de maior valor para se tornar explícita, pois são invisíveis para qualquer extração automatizada.

4. 4

   Mapeie os componentes que já existem no código

   Só agora vale a pena introduzir ferramentas, e apenas para componentes presentes em ambos os lados. Tudo o que não estiver mapeado é uma construção nova, e saber quem é quem já é útil por si só.

Expectativas calibradas, por tarefa:

A segunda linha merece mais crédito do que recebe. Uma inspeção confiável — valores exatos, nomes reais de tokens, props reais de componentes — elimina um atrito diário genuíno e nunca promete mais do que entrega.