Design engineering: o caminho para evitar experiências genéricas de IA

O problema de divergência entre UI prototipada e codada

Se você trabalha em alguma das etapas de desenvolvimento de software há tempo suficiente, deve se lembrar de todas as mudanças que tivemos em relação ao processo de handoff de design para o código.

Antes, era comum termos toda a prototipação do produto em uma ferramenta como Figma, Sketch ou Adobe XD. Tínhamos definido ali coisas como a identidade visual do projeto, os componentes, interações, fluxos de usuário, etc. Se o projeto fosse grande o bastante, você poderia ter um design system, e isso facilitava a colaboração entre designers e desenvolvedores.

Mas, independente de haver ou não um design system, algo que normalmente acontecia com uma facilidade enorme em projetos de diferentes nichos, tipos e portes era a divergência. Era muito comum haver algum tipo de mudança no código que não foi replicada ao Figma, por ter sido gerada através de uma implementação emergencial, ou alguma mudança que foi feita no Figma, mas não foi replicada ao código. Logo, todo o conteúdo que deveria servir como fonte da verdade no Figma não estava atualizado com o que, de fato, era entregue ao usuário final: o artefato do projeto.

As LLM's mudaram diversos aspectos de como escrevemos código em 2026, mas também mudaram aspectos na concepção de design de produto, e a forma como esses conceitos são integrados ao código.

A importância da coerência nos elementos visuais e na experiência do usuário

Ainda que você atue como um indie hacker e faça todas as etapas necessárias para desenvolver um produto, como muitos de nós devs acabamos fazendo em projetos pessoais, também é importante garantir que o design e a experiência do usuário sejam coerentes e consistentes.

A maneira mais eficaz de fazer isso, querendo ou não, é ter uma fonte visual de referência que demonstre qual é o fluxo do usuário nas features que entregamos. Isso ajuda a manter a coerência e a consistência simplesmente batendo o olho, mas também permite que a criação de novos fluxos seja muito mais simples, porque todo o "look and feel" já é pensado enquanto você cria elementos através do seu software de design.

Não há nada mais estranho do que navegar por um produto e ver despadronização de cores, espaçamento, fontes, motion e até de copy. Veja bem, seu produto não é apenas uma tela, mas sim uma experiência completa que o usuário espera.

Ainda que você nunca tenha acessado o site da Coca-Cola, você consegue, minimamente, imaginar qual é a cara do site. Quando não há uma padronização clara, esse tipo de identificação pode não ocorrer com o seu software.

Como a IA pode ajudar nisso

Não vou entrar no óbvio aqui e dizer o quanto um agent pode simplesmente gerar todo um design system com base no seu projeto, integrá-lo e ainda catalogar todos os seus componentes num Storybook da vida. Não.

Até pouco tempo atrás não tínhamos muitas ferramentas de Vibe Design (quase um vibe coding, mas pra design), pelo menos não ferramentas muito populares. Então, era muito mais comum você se deparar com designers que passaram a usar agents para pular a etapa do protótipo em um Figma da vida e ir direto para o código.

E, embora isso traga resultados rápidos, caímos em problemáticas como: se eu quero ver uma experiência, eu preciso rodar o projeto, preciso criar situações com mocks para ver edge cases, preciso fazer todo um setup de backend e infra na máquina de um designer, para que ele consiga trabalhar.

No exato momento em que escrevo essa postagem, temos algumas ferramentas que se propõem a resolver isso, inclusive o próprio Figma, com a conexão de agents onde eles podem ler/escrever elementos no canvas e replicar elementos e experiências entre o projeto de design e o código. Isso é fascinante.

Tenho usado bastante o Paper nas últimas semanas para criar novos fluxos no Physikos, e tem sido uma experiência muito boa, especialmente porque eu já tinha todos os fluxos principais desenhados no Figma (é a forma que eu sempre uso para começar novos projetos). E o Paper tem compatibilidade com o Figma, então também tenho acesso a todos os elementos, ou quase todos, do Figma no Paper.

Existem algumas outras ferramentas que fazem a mesma coisa, como o Pencil e o Wonder, que venho acompanhando o desenvolvimento desde o beta. Todas, essencialmente, fazem a mesma coisa:

• Você cria a UI nos frames, ou usa prompts para automatizar a criação desses elementos e telas
• Você sincroniza o código com o design
• Você mantém uma fonte de verdade, finalmente

Da maneira que coloco aqui, parece algo muito simples. Mas, na prática, eu tenho acesso a variáveis e tokens dentro do software de design: posso simplesmente alterar esses valores em um único lugar e replicar no meu código, sem atrito, sem estresse. Você ainda pode usar MCP's de geradores de imagem e criar seus próprios assets diretamente da mesma tela.

Na verdade, isso é algo que tem dado tão certo que grandes empresas têm passado a criar cargos com o nome de "Design Engineer" para trabalhar com essa abordagem.

Pense nesses profissionais como devs front-end que têm conhecimentos em UI/UX, ou designers que têm conhecimento em front-end. É o tipo de profissional que cruza barreiras de conhecimento para criar a melhor experiência possível para os usuários.

Design engineering: um caminho natural para indie hackers?

Não é novidade nenhuma que cada vez mais pessoas de tecnologia decidem empreender completamente sozinhos lançando seus produtos com a grande ajuda de agents. Também não é novidade nenhuma o surgimento de termos como "AI Slop" dado determinados padrões que LLM's usam para gerar interfaces genéricas sempre com o uso de gradientes, bordas arredondadas, cards sob cards, etc.

O maior risco de um indie hacker pular direto pro código com um agent é acabar reproduzindo exatamente o padrão que todo mundo reproduz: mesmo roxo com gradiente, mesmos cards com sombra suave, mesma fonte (quase sempre alguma variação de Inter), mesmo hero prometendo "ship faster with AI". Isso não é design, é a média estatística de milhares de landing pages que o modelo viu no treino, literalmente. E se o seu produto se parece com todos os outros, a única coisa que sobra pra te diferenciar é preço, e preço é o pior lugar pra competir quando você é um indie hacker sozinho contra empresas com caixa e time inteiro de growth.

E é exatamente aqui que a abordagem prototype-first deixa de ser só questão de organização e vira vantagem competitiva de fato. Quando você desenha primeiro, definindo paleta, tipografia, espaçamento, tom do copy, motion, antes de escrever qualquer linha de código, você está tomando decisões de identidade. O agent deixa de ser quem decide como sua interface se parece e passa a ser quem executa uma decisão que você já tomou. É a diferença entre pedir "cria uma landing page bonita" e pedir "implementa esse frame, com esses tokens, esse texto, esse motion", que foi exatamente a diferença que senti trabalhando no Physikos com o Paper.

Repare: o problema nunca foi usar IA. O problema é terceirizar julgamento estético pra IA, assim como já abordado em postagens anteriores sobre arquitetura de software. Um design system seu, com decisões suas, sincronizado com o código através de ferramentas como Paper, Pencil ou Wonder, garante que o agent trabalhe dentro de um sistema com identidade, e não que ele crie um sistema do zero baseado no que é estatisticamente mais provável de agradar.

Pra quem constrói sozinho, isso é bem mais crítico. Você não tem um time de design pra questionar decisões e brigar contra a tendência do "AI Slop" só por ela existir. A única barreira real entre o seu produto e mais um clone genérico com preço na régua é a disciplina de prototipar antes de codar. Sim, dá mais trabalho no início. Mas é exatamente esse trabalho, essa fonte da verdade visual que você constrói com intenção, que separa produto de commodity.