O que sobra quando a IA consegue fazer as telas

A IA já faz telas. Pede dez opções de interface e, em minutos, elas aparecem. Então a pergunta pra quem é Product Designer ficou bem concreta: o que sobra?

Minha resposta, depois de alguns meses testando isso na prática: sobra o que vem antes da tela e o que vem depois dela. Decidir o que deve existir, desenhar como o sistema se comporta e provar com coisa funcionando. A profissão não acabou, mas o que ela entrega mudou de tamanho. Quem continuar entregando o de antes, só que mais rápido, vai competir onde a máquina já é melhor.

No meu último emprego, coordenando um time de design numa software house, a gente já usava IA de dois jeitos. Como ferramenta, o mockup do Figma virava protótipo navegável e o cliente passava a dar feedback em cima de uma experiência de verdade; síntese de entrevista e organização de dado ficaram muito mais rápidas. Como entrega, dentro do software do cliente, a IA já lia os dados da operação e trazia leituras e projeções que antes dependiam de alguém montar relatório na mão.

Eu mesmo já construía com vibe coding, front-end de plataforma e site com back-end. E junto com os desenvolvedores, o time entregava agente funcionando pro cliente.

Então "empresa de tecnologia tem que ir de IA" não era dúvida. A dúvida era outra: se eu já conseguia construir, e o time já entregava agente, o que exatamente o designer traz pra essa mesa sem virar outra profissão?

Todo mundo tinha resposta pronta. Designer tem que aprender a programar; designer tem que virar gerente de produto. O que eu via era gente boa, com anos de estrada, travada no dilema entre continuar como antes ou ir de cabeça. E, enquanto isso não se resolvia, a saída mais comum era a mais perigosa: usar a ferramenta pra fazer o mesmo de sempre, só que mais rápido. Parece adaptação. Muitas vezes é só repetir o que já deu certo sem ver se ainda serve.

Quando saí de lá, não corri atrás da próxima vaga. Tirei alguns meses pra testar a minha resposta, com uma regra: IA em todos os projetos, em etapas diferentes, inclusive na entrega final. Vários saíram com agente funcionando dentro do produto. O que segue é o que eu aprendi.

Quando a IA gera dez telas em minutos, produzir tela deixa de ser o gargalo. O que fica escasso é saber qual das dez é a certa, por quê e pra quem. O trabalho se desloca pra formular o problema, definir o que é "bom" antes de gerar qualquer coisa e recusar o que parece bonito mas não resolve.

Na prática, eu vejo isso aparecer em três lugares.

Decidir o que deve existir. Antes do artefato, o critério. Qual problema vale resolver, qual solução cabe no negócio, no prazo e na tecnologia disponível. É o trabalho de quem senta entre design, produto e engenharia, e a IA não assume esse papel porque ele exige contexto e alguém que responda pela decisão.

Desenhar como o sistema se comporta. Quando o software age sozinho, a interface deixa de ser só tela e vira conduta: o que o agente faz por conta própria, quando pede confirmação, como erra, como o usuário corrige e como a confiança volta depois de uma falha. Num projeto de prospecção, por exemplo, a primeira camada inteira (contato, qualificação, triagem) pode rodar só com agentes, e a pessoa entra onde faz diferença. Desenhar isso é desenhar o comportamento de um sistema inteiro. Isso já é trabalho de hoje.

Provar com coisa funcionando. O designer não precisa virar programador, mas hoje ele consegue construir. Com vibe coding dá pra levar uma ideia até algo que roda, com foco em testar e validar, não em escalar. Quando entram arquitetura, segurança e performance, um desenvolvedor com conhecimento profundo é o parceiro certo pra continuar o que o designer provocou no começo. O diferencial passa a ser ter artefatos que mostram o raciocínio, e não só dizer que tem repertório.

Decidir o que deve existir inclui decidir onde a IA entra, e onde ela não entra.

Imagem · 01

Pra isso, ajuda lembrar que IA não é uma coisa só. Eu olho pra ela em dois eixos.

O primeiro é a forma da conversa. No modo exploratório, você ainda está descobrindo o que quer e usa a conversa pra abrir possibilidades. No estruturado, você já sabe onde quer chegar e, no limite, configura a IA pra fazer sempre a mesma coisa, do mesmo jeito, como um GPT customizado.

O segundo é o papel que você pede pra ela: especialista que te ensina um assunto fora da sua área, parceiro de brainstorm, persona que veste o papel do usuário e avalia, analista que organiza o que você já tem, executor que produz o artefato ou age por você, e decisor, que devolve uma decisão junto com a probabilidade de ela estar certa. Esse último costuma ser outro tipo de modelo, feito pra decidir e não pra gerar texto, como o Jev, da TypeSafe AI.

Os dois eixos se cruzam, e uma conversa real passa por vários papéis: começa com o especialista, vira brainstorm, termina com a persona julgando.

Isso vale pra como você trabalha. Quando o assunto é o projeto que você se comprometeu a entregar, entra outra decisão. E aqui vai uma posição minha, pensando em longo prazo e em custo: tenta fazer a solução ser viva e útil sem precisar rodar IA. Deixa a IA só nos processos em que ela realmente ganha tempo, melhora a qualidade da entrega ou melhora a decisão. E garante que a ferramenta funcione mesmo sem ela.

IA rodando custa a cada uso, muda de comportamento quando o modelo muda e às vezes fica fora do ar. Um produto que só funciona com ela herda tudo isso. Saber quanta IA cada situação precisa é o mesmo julgamento de saber quanto design cada situação precisa.

Nesses meses de teste, eu reparei em outra coisa. Tem empresa achando que design pode ser substituído por IA. Fui olhar o que elas entregam: tudo parecido, tudo no automático, o tal do IA slop, aquela produção genérica que se reconhece de longe. E o usuário percebe.

Imagem · 02

Só que tem uma diferença que muita empresa não enxerga. Em ferramenta interna, o slop passa, porque o colaborador é obrigado a usar. Em produto pro cliente final, que escolhe entre você e o concorrente, não passa. A empresa se perde justamente aí: "fiz assim no sistema interno e funcionou, por que não funciona pro cliente?". O colaborador aguenta. O cliente vai embora.

Com um bom designer no fluxo, junto com a IA, o produto fica mais competitivo no visual, na experiência e na marca. Do mesmo jeito que um bom programador reconhece código bom, um bom designer reconhece design bom, e a IA não preenche isso sozinha. Saber o que compete a cada área é o que permite somar, em vez de tirar gente achando que a máquina cobre.

Nada disso dispensa o básico. Tela bem feita, fluxo intuitivo e handoff que o dev consegue usar são o mínimo. Quem faz toda a pesquisa e o discovery mas não entrega isso talvez seja um bom pesquisador, um bom PM ou um bom estrategista, profissões que eu respeito. E quem só entrega tela bonita sem entender o problema é executor de layout.

Imagem · 03

O designer que continua relevante faz as duas pontas: entende antes e entrega bem no final. E cuida do caminho entre elas, faseando a entrega, criando pontos de medição no meio, documentando de um jeito que não se perde. Quem só olha o final não sabe chegar lá de novo, nem onde encaixar a IA.

No fundo, design é juntar gente: stakeholder antes, time durante, usuário no final. Fazer todo mundo enxergar a mesma coisa antes de construir. Não é coincidência que o mercado tenha levado esse jeito de pensar pra outras áreas com o nome de Design Thinking. Designer que esquece disso vira só quem desenha tela.

Toda aposta sobre o futuro devia dizer como saber se errou. Estes seriam os meus sinais:

• se agentes passarem a tomar boas decisões de produto sem supervisão, a ideia de que o julgamento sobra enfraquece;
• se as empresas pararem de contratar quem decide e só contratarem quem executa com IA, eu estava errado sobre onde está o valor;
• se produto genérico, feito no automático, começar a ganhar cliente final em pé de igualdade, o argumento do designer no fluxo cai.

Por enquanto, não vejo nenhum dos três acontecendo. Mas fico de olho, e vou contando aqui.

Lá em cima eu disse que o designer não precisa virar programador, mas consegue construir. Então até onde ele deve ir? Precisa aprender a programar de verdade, ou basta entender como a tecnologia é montada por trás? Essa é a próxima investigação.

Enquanto isso, me conta: no seu trabalho hoje, quanto é entregar tela e quanto é decidir o que deve existir?