O ponto de partida: o design já existia
Tudo começou com o layout pronto no Figma. Tipografia definida, paleta minimalista, grid com bastante respiro. O design era meu, a pergunta era se eu conseguia transformar esse arquivo em código de produção usando o Claude como meu desenvolvedor front-end.
Não um código “mais ou menos”. Código real: semântico, performático, acessível. O tipo de entrega que eu cobraria de um dev senior.
A stack foi uma decisão consciente: HTML, CSS e JavaScript puros. Zero frameworks. Zero dependências. Portfólio é vitrine: precisa carregar rápido, ser indexável, e não depender de nenhum ecossistema que pode mudar amanhã.
Fase 1: Estrutura e fundação
O primeiro dia foi o mais intenso. Eu abria o Figma, usava o MCP (Model Context Protocol) integrado ao Claude, e a IA recebia o contexto visual direto do arquivo de design. Isso eliminava o gap clássico de “traduzir” um layout para palavras, o Claude via exatamente o que eu via.
No final do dia, já tinha de pé:
- Estrutura base do HTML com semântica correta (
<header>,<main>,<footer>,<section>) - Logo SVG inline, direto no código
- Cards de projetos
- Navegação responsiva
- Deploy na Vercel com configuração de rotas
O ritmo era pair programming real: eu direcionava a visão, revisava o output, pedia ajustes, iterava. A diferença é que o loop entre “quero isso” e “está pronto pra revisar” levava minutos, não horas.
Mas não foi mágico. O Claude errava espaçamentos, interpretava mal hierarquias visuais quando o componente era mais complexo, e vez ou outra sugeria soluções que funcionavam tecnicamente mas ignoravam a intenção de design. Meu papel era justamente esse: olhar o resultado, comparar com o Figma, e redirecionar. Sem essa revisão constante, o output seria um site funcional mas genérico, exatamente o oposto do que eu queria.
Fase 2: Craft visual e interações
Com a fundação pronta, entrei na fase que mais me interessa como designer: o craft. É aqui que a maioria dos portfólios feitos com IA falham: ficam genéricos, sem personalidade, sem o cuidado nos detalhes que separa um site “ok” de um site que você lembra.
Parallax stacking dos cards
Uma das decisões de design mais marcantes: cada card de projeto ocupa o viewport inteiro e “empilha” conforme o scroll, criando profundidade. Implementei com position: sticky, sem biblioteca de animação, sem JavaScript pesado. CSS puro fazendo o trabalho.
Efeito typewriter no hero
O texto principal digita as frases de apresentação caractere por caractere. Sutil, mas dá vida à página. E respeitando prefers-reduced-motion, quem prefere menos animação vê o texto direto, sem efeito.
Marquee de logos
A seção de empresas usa um marquee infinito com logos em SVG. Parece simples, mas dá uma sensação de credibilidade e movimento. CSS animation puro, zero JavaScript.
Fase 3: Páginas de case study
Essa foi a fase mais densa em conteúdo. Cada case precisava contar uma história de design com contexto, problema, processo e resultado.
Os quatro cases:
- Template de Fretes (Fretebras): Como reduzimos em até 70% o tempo de cadastro de um frete
- WiseChat: Construindo uma ferramenta de comunicação integrada e personalizável
- WiseApp: App de roteirização para motoristas transportarem de forma mais inteligente
- Motorista VIP (Fretebras): Construindo um SaaS que já gerou receita de R$100MM
Cada página seguia a mesma estrutura visual mas com identidade própria: cores, imagens e tom distintos. O padrão que emergiu: header com metadata (empresa, ano, skills), imagem hero, seções de contexto/problema/solução, imagens com hover zoom, e navegação “next case” no final.
O que adicionei, e depois tirei
Aqui está uma lição que pouca gente menciona sobre vibecoding: como é tão fácil adicionar features, você experimenta mais. E como é tão fácil remover, o custo do erro cai a quase zero (mentira, vai uns tokens aqui também).
Eu adicionei animações de scroll reveal em todas as páginas de case. Ficou bonito no primeiro momento. Mas ao navegar o site inteiro em sequência, percebi que o excesso de animação quebrava o ritmo de leitura. O conteúdo competia com o efeito visual em vez de ser servido por ele.
Pedi o rollback. Em menos de dois minutos, as animações sumiram e o site respirou de novo.
Com IA, reverter é tão barato quanto implementar. Isso muda a forma como você toma decisões de design.
Fase 4: Polimento e features avançadas
Language Switcher (PT/EN)
O portfólio precisava falar duas línguas. Implementei um switcher com bandeiras SVG (Brasil e EUA) que persiste a escolha no localStorage. O sistema de tradução usa data-i18n attributes, sem framework de internacionalização, sem JSON externo. Os textos vivem direto no JavaScript, organizados por página.
Escalável? Não. Pragmático pra um site estático com meia dúzia de páginas? Totalmente.
Dark/Light Mode
CSS custom properties invertidas via [data-theme="dark"], com o script carregando antes do body pra evitar flash of unstyled content. Detalhe que me orgulha: a meta[name="theme-color"] muda junto com o tema, então a barra do navegador mobile acompanha. O ::selection também. Tudo coordenado.
Seção Sobre
Página pessoal com histórico profissional e texto de trajetória. Aqui o desafio foi mais editorial do que técnico, encontrar o tom certo entre profissional e pessoal.
Fase 5: Acessibilidade e performance
Essa não foi uma fase isolada, foi preocupação constante. Mas dois momentos merecem destaque.
Usei as Web Interface Guidelines como referência de auditoria. Os ajustes mais impactantes:
- Skip links e ARIA labels nos elementos interativos: essencial pra quem navega por teclado ou leitor de tela
- Loading lazy + dimensões explícitas em imagens abaixo da dobra: elimina layout shift e acelera o carregamento
- prefers-reduced-motion respeitado em todas as animações: não é feature, é respeito
- Preconnect pra CDN de fontes e passive listeners no scroll: micro-otimizações que somadas fazem diferença real em conexões lentas
Não foi checklist por checklist. Foi o tipo de cuidado que, como designer, eu sei que impacta a experiência real, especialmente pra quem a maioria dos sites ignora.
O que aprendi sobre vibecoding como designer
1. A IA não substitui visão de design, ela acelera a execução
Em nenhum momento o Claude decidiu como o site deveria ser. Layout, hierarquia, cores, interações, conteúdo, todas decisões minhas. A IA foi o veículo que transformou essas decisões em código. Sem direção clara, o resultado seria um site genérico com cara de template.
2. A velocidade de iteração muda a qualidade do resultado
Não porque a IA é melhor que um dev, mas porque o loop de feedback encolheu de horas para minutos. Quando você pode iterar mais, converge para um resultado melhor. Antes da IA, meu portfólio anterior levou meses entre “preciso atualizar isso” e “ok, está no ar”. Dessa vez, da primeira linha de código ao deploy, foram 14 dias.
3. Vibecoding não é “no code”, é “all code, mais rápido”
Cada linha do meu portfólio é código real, revisável e versionado no Git. Não é um site feito em Framer ou Webflow. É HTML que eu posso abrir em qualquer editor e entender. A IA escreveu, mas eu revisei, redirecionei e tomei todas as decisões arquiteturais.
4. Revisar output de IA exige um tipo específico de literacy
A surpresa pra mim não foi o que o Claude acertava, foi o que ele errava de forma sutil. Espaçamentos que pareciam corretos mas não seguiam o grid do Figma. Hierarquias de heading que faziam sentido pro HTML mas não pra narrativa visual da página. Micro-interações que funcionavam tecnicamente mas não tinham o timing certo.
Você não precisa saber codar do zero, mas precisa saber ler código o suficiente pra perceber quando o output tá “quase certo”, que é o estado mais perigoso, porque parece pronto mas não está.
5. O Figma + MCP é o que viabiliza isso com fidelidade
A integração do Figma via MCP foi o que tornou tudo possível. Sem isso, eu estaria descrevendo layouts em texto e torcendo pro resultado sair parecido. Com o MCP, o Claude recebia o contexto visual direto e entregava código fiel ao design. Essa ponte entre design tool e código é o que transforma vibecoding de experimento em processo real.
Pra quem está pensando em fazer o mesmo
Não vou dar conselhos genéricos. Vou contar o que eu faria diferente se começasse de novo:
- Começaria pelo sistema de design, não pela página. Eu fui direto pra home e depois ajustei tokens e variáveis retroativamente. Se tivesse começado pelas custom properties e pelos componentes base, as páginas de case teriam saído mais rápido e mais consistentes.
- Documentaria os prompts que funcionaram. Perdi tempo re-descobrindo como pedir certos ajustes porque não salvei os prompts que deram bom resultado. Um doc simples com “quando quero X, o prompt que funciona é Y” teria economizado horas.
- Testaria acessibilidade desde o primeiro commit. Fiz a auditoria no final e encontrei coisas que teriam sido triviais de resolver se estivessem no meu radar desde o início. Incluir “garanta acessibilidade” no prompt padrão teria evitado retrabalho.
- Faria o language switcher antes de escrever os cases. Escrevi todo o conteúdo em português, depois traduzi e conectei ao sistema de i18n. Se a estrutura bilíngue existisse desde o início, teria escrito os dois idiomas em paralelo.