Se você é designer e tentou usar IA para basicamente qualquer tarefa de design, sabe do que eu estou falando. A designer Hang Xu publicou no LinkedIn uns vídeos que ilustram perfeitamente a experiência — vale assistir. Em resumo: você pede uma coisa, a IA entrega outra, você corrige, ela entrega uma terceira, você corrige de novo, ela desfaz a correção anterior. É um ciclo que seria cômico se não consumisse horas do seu dia.

Eu passei por isso. E depois de rodar em círculos, pensei: de repente se eu mudar a abordagem a coisa vai melhor? Em vez de pedir para a IA criar design do zero, e se eu usasse a IA para o que ela faz bem — texto, código, estruturação de dados — e complementasse com minhas habilidades de design em vez de tentar substituí-las?

Assim nasceu, entre outras coisas, o Gothicus brasiliensis.

O Gothicus brasiliensis é um projeto editorial e artístico sobre o imaginário gótico brasileiro — um manifesto, um bestiário com 62 criaturas mitológicas, um mapa interativo, um baralho de cartas, um oráculo de adivinhação e uma série de ensaios em andamento. Não era para ser tudo isso. Começou como uma landing page simplezinha.

Pra começar, eu criei alguns protótipos em HTML com ajuda do Claude. Eu tinha uma ideia bem clara de como queria o design e a que ele se propunha, então comecei modestamente. Me animei com o progresso e, obviamente, inflei o site com umas dez coisas que não tinha planejado inicialmente. Não me impedi de nada — o projeto tem cunho artístico e eu não queria reprimir nenhum impulso criativo. O que aconteceu foi previsível para qualquer designer, mas eu escolhi correr o risco: meu design ficou difícil de escalar.

O site estava publicado e funcionando. Mas as decisões de design estavam todas enterradas no código — cores, tipografia, espaçamentos, tudo espalhado por vários arquivos CSS sem nenhuma sistematização. Cada nova página que eu criava exigia que eu fosse caçar os valores certos manualmente, e inevitavelmente apareciam inconsistências. Eu precisava de um design system.

A intenção, na verdade, era maior do que resolver meu problema imediato. Eu queria explorar se era possível usar IA de forma ética para melhorar os fluxos de trabalho entre desenvolvimento e design — em vez de implodir processos que talvez nunca tenham existido direito, ou de demitir profissionais. O Gothicus virou meu laboratório para isso.

A última coisa que testei foi o que chamei de vibe designing: usar IA para fazer a engenharia reversa do design que eu já tinha criado via vibe coding. O inverso do caminho tradicional. Em vez de Figma → código, foi código → design system → Figma.

Passo a passo, o que eu fiz:

Primeiro, pedi ao Claude para analisar o código do site já publicado e extrair dele os design tokens — as decisões de design que já estavam lá implicitamente. Cores, tipografia, espaçamentos, tamanhos, tudo o que define a identidade visual do site mas que estava espalhado e não documentado. O Claude organizou tudo em um arquivo JSON estruturado como design system. Não perfeito, mas um esboço sólido.

Segundo, salvei esse JSON no repositório do projeto no GitHub. Isso foi importante porque criou uma fonte de verdade versionada — qualquer mudança nos tokens ficaria rastreável.

Terceiro, conectei o repositório com o Figma usando o plugin Tokens Studio. O plugin precisa de um token de autenticação do GitHub para acessar o repositório. Uma vez conectado, ele leu o JSON e me deu uma paleta completa dentro do Figma com o design system do projeto. Eu não precisei criar tudo do zero — o plugin importou as cores, tipografia e espaçamentos que já existiam no código.

Quarto, com os tokens carregados no Figma, pedi ao Claude para me ajudar com o passo a passo da reconstrução das telas do site. Página por página, fui redesenhando no Figma o que já existia no código — agora com o sistema de tokens como base. Isso inclusive me ajudou a refrescar e melhorar minhas habilidades no Figma, que ficam enferrujadas quando você passa muito tempo no código.

O que eu quis fazer, em resumo, foi usar o LLM no que ele faz melhor — estruturar informação, organizar dados, gerar código — e complementar com minhas habilidades de design de interface. Na prática, isso me permitiu atuar como full-stack designer: uma pessoa da engenharia que sabe design, ou uma pessoa do design que sabe back-end. Um perfil que não é comum, mas que a IA torna mais acessível.

Não foi tudo lindo.

O Tokens Studio, para ser completamente funcional, é pago — e eu não sabia disso de antemão. A versão gratuita tem limitações que só aparecem quando você precisa de funcionalidades mais avançadas. É o tipo de informação que a IA não te conta porque ela não sabe (ou não sabia na época).

O resultado no Figma não ficou exatamente igual ao site. Há um gap inevitável entre o que existe em código e o que se reconstrói em uma ferramenta de design — e esse gap é um dos motivos pelos quais eu pessoalmente não gosto muito de design de produto digital no sentido estrito. É um pouco moroso e muitas vezes a implementação sai completamente diferente do que foi desenhado. Neste caso, o processo foi o inverso — o código já existia e o Figma era a reconstrução — mas o gap apareceu do mesmo jeito, só na direção contrária.

E a IA, como sempre, errou em detalhes. Tokens que precisaram de ajuste, classificações que não faziam sentido para o contexto do projeto, decisões que eu tive que corrigir manualmente. O Claude é um interlocutor que não se irrita com perguntas infinitas — o que para mim é ótimo. Mas tem que tomar cuidado com os tokens da IA (os computacionais, não os de design), para não esgotar o limite. Por um lado, o limite também força a criatividade. Por outro, me fez notar que a parte de levantar dados e requisitos continua sendo uma atividade profundamente humana.

O que aprendi com o processo foi algo que eu já intuía mas agora posso afirmar com mais convicção: a IA não substitui o repertório — ela o acessa. Só consegui usar a ferramenta bem porque já sabia o que queria, já tinha pesquisado, já tinha errado antes. Eu tinha anos de pesquisa escrita sobre o tema do Gothicus. O que a IA fez foi me ajudar a desengavetar esse material e explorar novas possibilidades.

O vibe designing funciona quando você tem design de verdade embaixo do vibe. Sem repertório, sem pesquisa, sem uma visão clara do que você quer, a IA gera ruído — e ruído bonito ainda é ruído.

Se você tem um projeto que nasceu no código e precisa de um design system retroativo, o caminho que descrevi aqui funciona. Não é perfeito, não é rápido, e exige que você saiba design o suficiente para corrigir o que a IA erra. Mas é real, é replicável, e faz a IA trabalhar no que ela faz bem em vez de lutar contra suas limitações.

Esse texto faz parte de uma série sobre design, IA e viés de dados. O anterior — Se você não consegue explicar, a IA não vai ajudar — discute por que o gargalo da IA no design não é a ferramenta, mas a capacidade de tradução entre linguagens.

If you're a designer and you've tried using AI for basically any design task, you know what I'm talking about. Designer Hang Xu posted on LinkedIn some videos that perfectly illustrate the experience — worth watching. In short: you ask for one thing, the AI delivers another, you correct it, it delivers a third thing, you correct it again, it undoes the previous correction. It's a cycle that would be funny if it didn't eat hours of your day.

I went through this. And after going in circles, I thought: what if I change the approach? Instead of asking the AI to create design from scratch, what if I used it for what it does well — text, code, data structuring — and complemented my design skills instead of trying to replace them?

That's how, among other things, Gothicus brasiliensis was born.

Gothicus brasiliensis is an editorial and artistic project about the Brazilian gothic imaginary — a manifesto, a bestiary of 62 mythological creatures, an interactive map, a card deck, a divination oracle, and an ongoing series of essays. It wasn't supposed to be all of this. It started as a simple landing page.

To start, I built some HTML prototypes with Claude's help. I had a clear idea of how I wanted the design and what it was meant to do, so I began modestly. I got excited with the progress and, obviously, bloated the site with about ten things I hadn't originally planned. I didn't hold back — the project is artistic in nature and I didn't want to suppress any creative impulse. What happened was predictable for any designer, but I chose to take the risk: my design became hard to scale.

The site was published and it was working fine. But the design decisions were all buried in the code — colours, typography, spacing, everything scattered across multiple CSS files with no systematisation. Every new page I created required me to hunt down the right values manually, and inconsistencies inevitably crept in. I needed a design system.

The intention, actually, was bigger than solving my immediate problem. I wanted to explore whether it was possible to use AI ethically to improve workflows between development and design — instead of imploding processes that may never have properly existed, or firing professionals. Gothicus became my lab for that.

The last thing I tested was what I called vibe designing: using AI to reverse-engineer the design I'd already created through vibe coding. The reverse of the traditional path. Instead of Figma → code, it was code → design system → Figma.

Step by step, here's what I did:

First, I asked Claude to analyse the published site's code and extract the design tokens — the design decisions that were already there implicitly. Colours, typography, spacing, sizes, everything that defines the site's visual identity but was scattered and undocumented. Claude organised it all into a JSON file structured as a design system. Not perfect, but a solid sketch.

Second, I saved that JSON in the project's GitHub repository. This was important because it created a versioned source of truth — any change to the tokens would be traceable.

Third, I connected the repository to Figma using the Tokens Studio plugin. The plugin needs a GitHub authentication token to access the repository. Once connected, it read the JSON and gave me a complete palette inside Figma with the project's design system. I didn't need to create everything from scratch — the plugin imported the colours, typography and spacing that already existed in the code.

Fourth, with the tokens loaded in Figma, I asked Claude to help me with a step-by-step reconstruction of the site's screens. Page by page, I redesigned in Figma what already existed in code — now with the token system as a foundation. This also helped me refresh and improve my Figma skills, which get rusty when you spend too much time in code.

What I wanted to do, in short, was use the LLM for what it does best — structuring information, organising data, generating code — and complement my interface design skills. In practice, this allowed me to work as a full-stack designer: an engineering person who knows design, or a design person who knows back-end. A profile that isn't common, but that AI makes more accessible.

It wasn't all pretty.

Tokens Studio, to be fully functional, is paid — and I didn't know that beforehand. The free version has limitations that only surface when you need more advanced features. It's the kind of information the AI doesn't tell you because it doesn't know (or didn't know at the time).

The result in Figma didn't come out exactly like the site. There's an inevitable gap between what exists in code and what gets reconstructed in a design tool — and that gap is one of the reasons I personally don't love digital product design in the strict sense. It's a bit tedious and often the implementation comes out completely different from what was designed. In this case, the process was reversed — the code already existed and Figma was the reconstruction — but the gap showed up just the same, only in the opposite direction.

And the AI, as always, got details wrong. Tokens that needed adjustment, classifications that didn't make sense for the project's context, decisions I had to correct manually. Claude is a conversational partner that doesn't get annoyed by infinite questions — which is great for me. But you have to watch the AI tokens (the computational ones, not the design ones) so you don't hit the limit. On one hand, the limit also forces creativity. On the other, it made me realise that gathering data and requirements remains a deeply human activity.

What I learned from the process was something I already intuited but can now state with more conviction: AI doesn't replace repertoire — it accesses it. I could only use the tool well because I already knew what I wanted, had already researched, had already made mistakes. I had years of written research on the Gothicus theme. What the AI did was help me dust off that material and explore new possibilities.

Vibe designing works when you have real design underneath the vibe. Without repertoire, without research, without a clear vision of what you want, the AI generates noise — and pretty noise is still noise.

If you have a project that was born in code and needs a retroactive design system, the path I described here works. It's not perfect, it's not fast, and it requires you to know enough design to correct what the AI gets wrong. But it's real, it's replicable, and it makes the AI work at what it does well instead of fighting against its limitations.

This is part of a series on design, AI and data bias. The previous post — If you can't explain it, AI won't help — discusses why the AI bottleneck in design isn't the tool, but the capacity for translation between languages.