Por que a maioria das soluções AI para design não funcionam?

A grande maioria dos skills e plugins disponíveis para “melhorar” o design simplesmente não é usada por designers profissionais. O motivo é direto: designers já sabem fazer o que essas ferramentas prometem entregar, e fazem melhor. Mesmo quando a ferramenta traz algum ganho marginal, são necessárias muitas iterações para chegar em um resultado satisfatório.

Quem acaba usando esse tipo de recurso são pessoas que não atuam profissionalmente com design, e isso revela um padrão importante, explico a seguir.

O que profissionais de design realmente buscam

Designers profissionais buscam soluções escaláveis, que se encaixem no fluxo de trabalho existente e que, na balança final, gerem mais resultados positivos do que o atrito adicionado ao processo. Por isso, todos esses frameworks e skills e até ferramentas interias que aparecem a cada dia geram mais “awareness” do que resultado. Quem acaba testando e aplicando são profissionais sem a responsabilidade da cadeira: aventureiros, empreendedores que não têm orçamento para contratar um designer, influenciadores e freelancers que trabalham de forma mais independente.

Do outro lado estão os profissionais de design, que além de uma entrega visualmente coerente, precisam se preocupar com uma lista quase inesgotável de critérios: estéticos, funcionais, ergonômicos e de negócio. E infelizmente, nenhuma ferramenta de IA oferece tudo isso, ainda.

Duas formas de olhar para as ferramentas de IA em design

Na minha visão, as ferramentas e métodos de aplicar IA em design devem ser analisados a partir de duas perspectivas distintas (se você realmente que agregar valor ao processo e ao resultato):

1. Atalho para melhorar um output pontual

É o caso de baixar um skill para ajudar o modelo a gerar um resultado visualmente mais interessante. Ex: o DESIGN .MD, Esse tipo de recurso tem um público específico: a pessoa não-designer, o empreendedor solo, o aventureiro. São pessoas que não têm o compromisso de fazer um trabalho de design rigoroso, não são cobradas por isso e não precisam de consistência ao longo de um projeto maior.

2. Funcionalidade que otimiza um processo maior

Aqui entram recursos como o MCP e Skills do Figma, o GSD, ou a integração do processo de research em um conjunto de Agents, Skills e Conectores. Esse é o tipo de coisa em que profissionais de design, produto e engenharia deveriam investir atenção e energia.

O ponto central dessa segunda categoria é que a ferramenta facilita parte do processo, mas o trabalho de design continua sendo responsabilidade do profissional. A qualidade do output de design to code, por exemplo, é uma responsabilidade compartilhada entre design e engenharia. E uma vez encontrado um ponto ótimo, ele pode ser escalado para todo o time.

Andrej Karpathy, cofundador da OpenAI e a pessoa que cunhou o termo “vibe coding”, fala sobre a diferença entre vibe coding e desenvolvimento agêntico. Em uma tradução simplificada, seria algo assim: 

• Vibe coding é a ideia de que, com o avanço da IA, qualquer pessoa, mesmo sem nenhum conhecimento técnico, pode criar software, principalmente para resolver problemas pessoais ou explorar projetos sem o compromisso com a qualidade do código gerado. 
• Já o desenvolvimento agêntico tem mais a ver com usar IA para apoiar o fluxo de desenvolvimento, onde o profissional se permite não fazer todo o “trabalho pesado” de código, mas ainda assim é responsável pela estratégia, pela arquitetura e por garantir que o output atenda ao rigor e à qualidade técnica esperados.

Essa distinção se aplica diretamente ao design. As ferramentas da primeira categoria são o equivalente ao vibe coding no nosso contexto. As da segunda são o que o profissional de design, produto e engenharia deveria estar olhando com atenção.

O que realmente agrega valor para o profissional

O que faz diferença para o perfil profissional tem mais profundidade. É a peça que facilita e acelera o fluxo, mas mantém o controle do rigor e da qualidade na mão de quem tem a especialidade.

O Figma MCP é um bom exemplo: ele conecta, acelera e mantém consistência, mas todo o trabalho de design permanece na mão do profissional, que carrega tanto o conhecimento da disciplina quanto o entendimento do domínio específico do produto. Além disso, essa ferramenta se integra a um workflow já conhecido, validado e refinado, baseado em colaboração entre times.

Olhar crítico como filtro, não como barreira

Sendo um pouco mais pessimista: quando olho para o Claude Design, por exemplo, não consigo enxergar ele em um fluxo de trabalho de um time de produto, pelo menos por enquanto. Comparado com o Figma, que é colaborativo por concepção, a distância ainda é grande. Recomendo o Papo na Arena com participação do Vitor Ferreira falando sobre o Claude Design.

Ter esse olhar crítico, na prática, te ajuda a direcionar energia. Você para de sentir FOMO de acompanhar todas as novidades e passa a se perguntar: o que realmente agregaria valor no meu trabalho atual, esse que paga meus boletos? Usar uma ferramenta por curiosidade ou em um projeto pessoal é uma coisa. Buscar uma solução para otimizar o processo de um time, que seja replicável para outros times dentro da empresa, é outro nível de exigência completamente diferente.

Criar seus próprios fluxos é estar na vanguarda

Uma das formas mais efetivas de estar na frente é criar seus próprios fluxos e ferramentas, ou “materializar” uma metodologia de design em um workflow agêntico.

A ideia é pegar processos consolidados, aqueles que já estão nos livros, como Opportunity Solution Tree, ICE Score e Análise Heurística, e alimentar um agente ou uma skill para que ele seja acionado em momentos específicos do processo, ajudando a criticar o que você está construindo. PS: ajudar a criticar e evoluir é diferente de pedir para uma AI fazer o trabalho por você.

Isso não é uma ideia sem precedente. Acompanho alguns canais gringos de desenvolvimento de software (ainda navego nesse lado obscuro da força 😅) e vejo desenvolvedores fazendo exatamente isso: pegando métodos como DDD (Domain-Driven Design), TDD (Test-Driven Development) e princípios de engenharia de software extraídos de livros de referência, e transformando em skills para usar nos seus fluxos de desenvolvimento com LLMs. Veja exemplo do Matt Pocock.

O paralelo com design é direto e vale ser explorado.

Quando seu processo está pronto para virar um workflow agêntico?

Essa é a pergunta que inevitavelmente aparece nesse momento. E a minha resposta é: não precisa estar em um ponto perfeito.

Logicamente, não faz sentido portar para um fluxo com IA um processo que ainda não está minimamente maduro. Mas se você já conhece razoavelmente aquele processo, se o repete algumas vezes por semana ou por mês, isso já justifica a adaptação. Com a mentalidade de que todo processo pode receber iterações, você começa e vai refinando.

E ferramentas como Claude Code ou Gemini facilitam exatamente isso: a cada nova descoberta, você pode pedir para o próprio modelo atualizar o agente ou a skill com a nova regra. O processo evolui junto com o seu aprendizado.

Se você quer aprender mais sobre como agregar ferramentas de AI como Claude Code em seu fluxo de trabalho, eu tenho um curso prático e didático para ajudar com isso, confere aqui antes que feche a turma.

No fim, o que importa é o que gera valor

Está na hora de focar nos processos que realmente importam. E o que gera valor é o que te libera tempo operacional para ser mais estratégico: falar com usuários, pensar no negócio e, sim, ter tempo de descanso também.

Até a próxima.