O Product Designer precisa aprender programação?

Quando a IA começou a entrar de verdade no trabalho de produto, todo mundo tinha uma resposta pronta pro que o designer deveria virar. Uma das mais repetidas era essa: designer tem que aprender a programar.

A minha resposta, depois de construir bastante coisa com IA nos últimos tempos: o designer não precisa virar programador. Mas hoje ele consegue construir, e precisa entender como a tecnologia é montada por trás o bastante pra decidir bem e conversar de igual com quem desenvolve. São coisas diferentes, e misturar as duas é o que deixa muita gente travada.

Até pouco tempo, ideia de designer parava no protótipo. Dava pra simular uma experiência, mas não dava pra colocar algo de pé sem alguém do desenvolvimento.

Com o vibe coding, isso mudou. Eu mesmo construo com Claude Code, Codex e Antigravity: front-end de plataforma, site com back-end, testes de produto. Uma aba inteira do meu site, a Labs, existe pra isso. Quando não tem um cliente ou um projeto pra aquilo que eu quero aprender, eu vou lá e construo.

Nada disso me transformou em programador. Me deu outra coisa: a capacidade de levar uma ideia até algo que funciona e colocar na frente de alguém.

O que o vibe coding dá pro designer é velocidade pra testar e validar uma ideia. Não é pra construir a solução definitiva.

Imagem · 01

Quando entram arquitetura, segurança e performance, fica evidente que um desenvolvedor com conhecimento profundo é o parceiro certo pra dar continuidade ao que o designer provocou nas primeiras etapas. O papel do designer passa a ser garantir que a direção decidida no começo chegue no final do jeito certo, e testar cada etapa pra saber se está funcionando.

Na software house onde eu coordenava o time de design, eu já construía bastante coisa. E me limitava na entrega final de propósito, pra não colidir com os devs. Nem queria fazer diferente: sempre apostei na colaboração entre as áreas. Do mesmo jeito que um bom programador reconhece código bom, um bom designer reconhece design bom. Somar os dois rende mais do que um tentar ocupar o lugar do outro.

Não precisar programar não significa poder ignorar como as estruturas são feitas. Isso ficou muito claro pra mim nos cursos que venho fazendo: o que o designer precisa aprender agora não é como escrever o código. É como funciona a arquitetura por trás da infraestrutura.

Imagem · 02

Antes, quando a gente começava a criar, sabia mais ou menos por cima como seriam as estruturas, e o resto era com o desenvolvimento. Agora, se você vai construir de forma independente, a arquitetura por trás de tudo pesa muito. Mesmo que você já saiba qual infraestrutura vai usar pensando em escalar, precisa entender quanto tudo aquilo custa, qual é o ponto de equilíbrio, quando vem o retorno e se dá pra usar recursos mais baratos no MVP. E lembrar que o MVP é o momento de testar com poucas pessoas.

O problema que eu vejo muita gente ter aparece na hora de divulgar e começar a vender: ninguém checou se a infraestrutura escala, se ela se organiza de acordo com a demanda.

Do front-end, o designer já entende um pouco, assim como de motion. Quando alguém fala em fazer em React, em Next ou em Flutter, a gente começa a sacar os impedimentos estéticos e de experiência de cada escolha. O passo agora é entender a estrutura do back-end também. Não pra executar, porque isso a IA pode estruturar pra você, mas pra decidir com consciência. E, se você tem um desenvolvedor parceiro que manja muito do assunto, dá pra dividir os desafios do desenvolvimento em vez de competir.

E com IA isso pesa ainda mais. Quem trabalha com tecnologia não pode usar IA de forma superficial, porque ela vai estar dentro do que a gente entrega. Entender como ela funciona por dentro, onde acerta e onde erra, virou parte do trabalho de decidir. É isso, por exemplo, que permite projetar um produto que continua útil mesmo quando a IA não está rodando.

Eu aprendi isso do jeito difícil. Quando comecei a desenvolver o IdeaPilot, uma plataforma pra quem tem ideias e quer transformá-las em projeto, comecei bem e rápido. Conforme ela evoluía, eu tinha mais ideias, via mais possibilidades, testava e entendia melhor o que estava fazendo. A plataforma cresceu quase por brotamento: sentia necessidade de uma funcionalidade nova, a gente aplicava, ia misturando tecnologias.

Chegou um ponto em que eu não conseguia mais evoluir como queria. Provavelmente havia inconsistências que eu não tinha previsto no começo, porque a arquitetura nunca tinha sido pensada pro tamanho que aquilo ganhou.

Ao mesmo tempo, os testes mostraram que o público não era o que eu imaginava. O produto foi feito pra qualquer pessoa com uma ideia, mas a usabilidade, os objetivos e as expectativas de quem usava deixaram claro que ele não era pra qualquer pessoa. Precisei pensar numa solução B2B.

Desse movimento nasceu o Vantiz, o projeto que estou construindo agora. E nele eu fiz o contrário: pensei a infraestrutura inteira, a partir da arquitetura, antes de escrever a primeira linha de código.

Tem uma pergunta que me acompanha enquanto escrevo isto. A cada modelo novo, seja do Claude ou da OpenAI, eu vejo a IA acertar mais e entregar estruturas complexas cada vez mais bem organizadas, inclusive a parte de arquitetura que eu disse que o designer precisa entender. Se hoje ela já estrutura o back-end pra você, quanto falta pra ela também decidir qual arquitetura faz sentido?

É impossível não pensar nisso. Quanto tempo falta pra eu me tornar obsoleto? Como vai ser a minha profissão daqui a alguns anos? Que habilidades eu vou precisar ter de verdade?

Não tenho resposta fechada, e desconfio de quem tem. O que eu tenho é uma aposta: quanto melhor a IA executa, mais vale quem sabe o que pedir, consegue avaliar se o que veio está certo e responde pela decisão. Entender a arquitetura, nesse sentido, não serve pra competir com a IA na execução. Serve pra continuar sendo quem decide o que ela vai construir.

E tem um lado dessa história que me anima. Cada vez fica mais fácil materializar o que antes ficava só na nossa cabeça. A ideia que morria no caderno porque ninguém tinha tempo ou orçamento pra construir agora pode virar algo que roda numa tarde. Isso coloca no centro a criatividade de quem orquestra: imaginar o que vale a pena existir, combinar as peças certas e conduzir a IA, os agentes e as pessoas até a ideia ganhar forma. O orquestrador não precisa tocar todos os instrumentos, mas precisa saber que música quer ouvir.

Essa aposta pode estar errada, e eu vou revendo conforme os modelos evoluem.

O risco do vibe coding é justamente o que ele tem de bom: o que sai dele parece pronto. Roda, tem tela, dá pra clicar. E aí aparece a tentação de colocar no ar sem ninguém de desenvolvimento olhar. Protótipo que funciona não é produto seguro, e a parte que o designer não enxerga, como segurança e performance, é exatamente a que costuma cobrar a conta depois.

Imagem · 03

Por isso a linha que eu sigo é clara: construir pra provar a ideia, entregar pro desenvolvimento quando é hora de escalar. Saber onde termina o seu pedaço também é parte de entender de tecnologia.

Tudo isso vale pra quando o designer está dentro de um time, com desenvolvedores do lado. Mas e quando ele constrói o produto praticamente sozinho, com IA fazendo boa parte do trabalho? É o que estou vivendo no Vantiz, e quero contar com calma.

Enquanto isso, me conta: você já colocou alguma ideia de pé com vibe coding? Até onde você foi antes de precisar de alguém do desenvolvimento?