Você está lendo a prova. Este portfólio — dois estudos de caso, uma Bio, um blog em três idiomas, analytics — saiu de um arquivo do Figma para um site no ar em dois dias de trabalho. Não porque eu digitei mais rápido, mas porque mudei quem faz o quê. Aqui está exatamente como foi construído, incluindo o que deu errado.
Figma primeiro, sempre
Cada tela que você vê aqui existiu no Figma antes de qualquer componente ser escrito: a Home, as páginas de estudo de caso, a Bio, até a arte do hero de cada post do blog. Isso não é nostalgia pelo canvas. É onde eu tomo as decisões que importam — hierarquia, ritmo, o que mostrar e o que cortar — e é onde eu as aprovo, num único olhar, antes que alguém gaste tempo com código.
A regra é simples: página nova, seção nova, linguagem visual nova? Figma, revisão, aprovação. Só depois código.
A ponte
O meio do pipeline é o BridgeUX, uma ferramenta que construí que permite a um agente ler e escrever no Figma a partir do terminal: mais de cem operações, desde "me dê o padding exato deste card" até "clone esse brilho em quarenta e sete nós" até "exporte este frame como PNG".
Isso muda o que "pixel-perfect" significa. Os cards de projeto da Home não foram estimados a olho a partir de um screenshot. O agente leu o nó do Figma — 576 por 652, 32 de padding, um título bold de 21 pontos, uma caixa de métrica de 172 de largura, 68 de respiro antes da imagem — e escreveu o componente React a partir desses números. Quando depois eu quis os cards um pouco mais largos, a mudança foi no sentido contrário: ajustar no código, espelhar no Figma, uma fonte de verdade em cada direção.
Quem faz o quê
Essa é a parte que todo recrutador realmente quer saber.
O agente escreve os componentes, conecta as rotas, traduz o conteúdo para espanhol e português, converte trinta imagens para WebP, constrói o favicon a partir do próprio glifo da fonte, gera o sitemap e o social preview, e roda o build no servidor.
Eu decido. Quais dois projetos, de quinze anos, merecem um estudo de caso. Qual único número vai em cada card. Que o dourado é a linguagem visual e onde ele pode aparecer. Que o post "inovador" do blog precisava ser substituído por este. Cada mudança é revisada na URL real, no desktop e no celular, antes de eu dizer "publica".
O princípio sobre o qual escrevi em outro post vale também para as ferramentas: o modelo interpreta, o código executa — e eu aprovo.
Nada está pronto sem evidência
A regra de trabalho que tornou dois dias possíveis é a mesma que uso na StratNova, o SaaS de WhatsApp que estou construindo com um time de agentes: nenhum código no meu laptop, nunca. O código-fonte vive no servidor, o agente edita lá, builda lá, e toda alegação de "pronto" vem com prova — um screenshot da página no ar, um curl mostrando um 200, uma linha de banco de dados mostrando que o evento de analytics chegou.
"Deveria funcionar" não é evidência. "Eu reiniciei" não é evidência. Isso soa pedante até você ver um agente declarar vitória com confiança sobre uma página que renderiza preta.
Os números
Dois dias. Dois estudos de caso com trinta imagens. Três idiomas, cem por cento traduzidos, incluindo as notas escritas à mão. Uma Bio, um CV para baixar, um favicon, social previews, um sitemap. Analytics que respeita a privacidade. Tudo isso em cerca de 180 KB de JavaScript, com as páginas de caso carregadas sob demanda.
O que deu errado
Porque um making-of sem falhas é só marketing:
- O favicon que não queria mudar. Uma regra antiga do Cloudflare costumava redirecionar este domínio para um protótipo do Figma, então os navegadores tinham em cache o raio roxo do Figma como o "meu" ícone. O novo ícone foi servido corretamente por uma hora antes que alguém conseguisse vê-lo. Solução: um
favicon.icoque faltava, URLs versionadas, e paciência. - Os screenshots minúsculos. A primeira versão das galerias de caso renderizava telas de celular com 172 pixels de largura dentro de uma caixa de 1.200 pixels. Era fiel a um layout que ninguém tinha questionado. Um olhar na página real, uma frase minha, um commit.
- O comentário que matou a stylesheet. Um comentário CSS contendo os caracteres
*/dentro do próprio texto se fechou sozinho cedo demais e desativou todas as regras depois dele. Sem erro, só uma página sem dourado nenhum. Agora o build verifica se os comentários abrem e fecham em números iguais. - O build que não foi publicado. Por uma tarde inteira, o site no ar estava servindo um build das 15h47 enquanto toda melhoria vivia só na URL de dev. O agente tinha feito o trabalho; o passo de deploy tinha sido bloqueado por um prompt de permissão que ninguém viu. A evidência pegou: um diff entre dois timestamps de
index.html.
Nenhum desses foi "erro de IA". Foram incidentes normais de engenharia, encontrados do jeito normal — olhando para a coisa real.
Por que isso importa para um Senior Product Designer
Na maior parte da minha carreira, a distância entre uma decisão de design e uma tela publicada era medida em sprints. Agora é medida em minutos, desde que duas coisas se mantenham: o designer consegue especificar com precisão — no Figma, em tokens, numa frase — e alguém insiste em evidência antes de acreditar em qualquer coisa.
Esse é o trabalho agora. Não desenhar mais telas. Decidir melhor, especificar mais apertado, e verificar com mais rigor. As ferramentas finalmente alcançaram o jeito que eu sempre quis trabalhar. Este site é a cara disso.