Recentemente assisti a um vídeo que me fez pensar. Um desenvolvedor Android, sem nenhuma formação em design, usou Claude Code e o Figma MCP para gerar um conjunto completo de designs para um app mobile a partir de um documento de requisitos em markdown. Em cerca de uma hora. Ele então comparou o resultado ao que uma agência de design profissional havia produzido a partir do mesmo briefing, e os designs gerados por IA ficaram… surpreendentemente próximos.

O vídeo que inspirou este artigo

O título do vídeo é “We don’t need designers anymore” (“Não precisamos mais de designers”). E honestamente, assistindo, eu entendi o impulso. Já tive a versão espelhada desse pensamento, observando IA escrever código surpreendentemente funcional em domínios que não conheço. Talvez eu não precise de um engenheiro para isso.

Vale notar que o autor do vídeo vende cursos e mentoria direcionados a desenvolvedores mobile, e o canal dele no YouTube é parte desse marketing. Isso não invalida a experiência dele, mas significa que seus incentivos se alinham com uma narrativa específica: a de que desenvolvedores agora conseguem fazer tudo sozinhos. Um título chamativo como “não precisamos mais de designers” é ótimo para engajamento, e uma comparação anedótica entre o trabalho de uma agência e uma sessão de IA rende um vídeo convincente. O que não rende é um panorama completo.

Não estou escrevendo isso para criticar o vídeo. Estou escrevendo porque acho que as sutilezas que ele não cobre são exatamente as que mais importam, e porque quero pensar criticamente sobre para onde essa indústria está realmente indo, não apenas para onde o hype diz que está.

Essa sensação de “consigo fazer tudo sozinho” é o que eu quero discutir. Porque acho que ela é ao mesmo tempo real e profundamente enganosa.

O que a IA realmente mudou no trabalho criativo

Deixa eu ser claro: o que as ferramentas de IA fizeram com o trabalho criativo e técnico é genuinamente notável. Alguém que admite abertamente que suas “habilidades de design são uma merda” produziu um conjunto de telas no Figma que qualquer designer reconheceria como trabalho de verdade. Não um esboço, não um wireframe, mas algo com um design system completo, hierarquia tipográfica e consistência de componentes.

Isso simplesmente não existia dois anos atrás, e vale celebrar.

A mesma coisa está acontecendo do lado da engenharia. Já vi designers sem nenhuma formação em desenvolvimento publicar componentes React funcionando, subir backends básicos e escrever scripts que resolvem problemas reais. Coisas que exigiriam meses de aprendizado ou um orçamento de desenvolvimento agora levam uma tarde.

Mais pessoas podem construir mais coisas, e isso é geralmente positivo.

A armadilha da confiança

Aqui é onde a coisa complica, porém. A IA não reduz apenas a barreira para produzir trabalho. Ela também reduz a barreira para se sentir confiante sobre esse trabalho. Você gera algo que parece polido e completo, e porque não consegue enxergar as falhas que nem sabe que deveria procurar, assume que está bom. O resultado parece profissional, então você se sente profissional.

Isso não é novo. Iniciantes sempre superestimaram suas habilidades. É um viés cognitivo bem documentado. Mas um estudo recente publicado no Computers in Human Behavior encontrou algo que merece atenção: quando pessoas usaram IA para resolver problemas de raciocínio lógico, seu desempenho real melhorou cerca de 3 pontos, mas elas superestimaram seu desempenho em 4 pontos. O padrão clássico do efeito Dunning-Kruger, onde os menos competentes superestimam mais, desapareceu completamente. Com IA, todo mundo passou a superestimar. E talvez o mais contraintuitivo: maior familiaridade com ferramentas de IA correlacionou com pior precisão na autoavaliação, não melhor. Quanto mais confortável você é com IA, mais provável que confunda o output da ferramenta com seu próprio entendimento.

Gráfico mostrando pontuações estimadas vs alcançadas por quartil de desempenho ao usar IA. A linha de estimativa é quase plana em torno de 17-18 em todos os quartis, enquanto a linha real sobe de cerca de 11 para 16.
A linha tracejada mostra o quão bem as pessoas achavam que tinham ido. A linha sólida mostra o quão bem elas realmente foram. Com IA, todo mundo achou que foi bem, independente do desempenho real. De Stadler et al., Computers in Human Behavior, 2025.

A distância entre “isso parece pronto” e “isso realmente está pronto” costumava ser muito mais visível, porque o resultado bruto de um iniciante era muito mais bruto. O mockup de um estudante de design de primeiro ano parecia o mockup de um estudante de primeiro ano. Agora pode parecer algo que um designer pleno produziu numa tarde de terça.

É aí que as coisas ficam perigosas, porque o iniciante e o designer pleno estão produzindo outputs visualmente indistinguíveis, embora não sejam a mesma coisa. O iniciante não sabe por que certas decisões foram tomadas. Não sabe o que foi sacrificado. Não consegue avaliar se a estrutura de navegação vai aguentar conforme o produto cresce, se as escolhas de cor funcionam no modo escuro, ou se a hierarquia de informação ainda fará sentido quando a interface for populada com dados reais em vez de placeholder.

A IA também não sabe essas coisas. Ela otimiza para parecer certo.

Vejo isso no meu próprio trabalho. Consigo pedir para uma IA gerar código que compila, roda e até passa em testes básicos. Parece correto. Mas me falta a intuição profunda de engenharia para avaliar se vai aguentar sob carga, se a arquitetura vai escalar, se existem condições de corrida sutis escondidas no modelo de concorrência. Um engenheiro sênior identificaria esses problemas em minutos. Eu não saberia que eles existiam até algo quebrar em produção.

Por que “bom o suficiente” tem limites

Voltando ao vídeo: quando o desenvolvedor comparou seus designs gerados por IA ao trabalho da agência, ele notou diferenças reais. O componente de contagem de passos da agência ficou melhor. O dashboard deles era mais cuidadoso. Ele encontrou um erro de UX no output da IA: uma ação destrutiva (“resetar os passos de hoje”) enterrada no menu de navegação lateral, onde usuários não esperariam e poderiam acioná-la por acidente. Ele percebeu porque é um desenvolvedor que já pensou sobre padrões de interação. Um iniciante completo talvez não percebesse.

Mas aqui está o que o vídeo não aprofunda: se ele tivesse contratado uma agência melhor, a diferença teria sido muito maior. Ele estava comparando seu output de IA ao trabalho de uma agência específica, e encontrou os dois aproximadamente equivalentes. Design profissional existe num espectro, porém, e uma equipe de design de produto realmente boa, que faz pesquisa, design de interação e pensamento sistêmico, teria produzido algo significativamente diferente. Seria mais difícil de comparar por screenshot, mas a diferença nos detalhes que importam com o tempo seria grande.

Isso vale para os dois lados. Um backend feito por vibe coding pode funcionar perfeitamente bem para seus 50 usuários beta. Mas quando 50.000 usuários estão acessando aquele endpoint simultaneamente, as escolhas arquiteturais que pareciam invisíveis em escala pequena se tornam a diferença entre um produto que funciona e um que cai.

A IA elevou o piso. Não elevou o teto.

O padrão que continuamos repetindo

A cada alguns anos há uma onda de ferramentas que facilita para uma disciplina fazer o trabalho de outra. O Squarespace deixou não-designers construir websites. O Webflow facilitou ainda mais. Ferramentas no-code deixaram não-desenvolvedores criar apps. Cada vez, alguém escreve um artigo sobre como não precisamos mais de [preencha o espaço em branco].

E cada vez, os profissionais da disciplina “descontinuada” passam por um momento difícil, para então descobrirem que a demanda por eles na verdade aumentou. Porque agora mais pessoas estavam construindo coisas, e eventualmente essas coisas precisavam ficar sérias. Os websites construídos no Squarespace precisaram escalar. Os apps no-code atingiram seus limites. Os sistemas gerados por vibe coding apresentaram problemas que exigiam expertise real para resolver.

Projetar ou desenvolver um produto completo com ajuda de IA é perfeitamente aceitável para coisas simples ou de baixo risco. Um projeto pessoal. Um protótipo rápido para testar uma ideia. Uma ferramenta interna usada por três pessoas. Mas quando as coisas ficam sérias, quando usuários reais dependem disso, quando o produto precisa crescer e ser acessível e mantível, você não pode confiar em si mesmo para fazer coisas fora da sua expertise. Não porque não seja inteligente o suficiente, mas porque expertise não é apenas saber como fazer as coisas. É saber quais perguntas fazer.

Consigo fazer vibe coding de uma feature. Não vou saber o que não sei até que ela quebre.

Por que a colaboração importa mais agora, não menos

Aqui está a parte que eu acho genuinamente esperançosa, porém. A ascensão das ferramentas de IA tornou a colaboração entre designers e engenheiros mais necessária, não menos, mas também nos deu uma forma muito melhor de fazer isso.

Pensa no que costumava acontecer quando um designer insistia numa animação sutil que um engenheiro via como perfumaria desnecessária. O designer não conseguia articular totalmente o custo técnico que estava pedindo, e o engenheiro não conseguia enxergar por que aquele “detalhe inútil” na verdade ajudaria os usuários a entender uma mudança de estado e se sentir mais confiantes na interface. Os dois lados tinham razão, mas estavam falando línguas diferentes.

A IA pode ser uma tradutora aqui. Como designer, eu consigo usar IA para entender melhor as limitações técnicas por trás de uma resistência, para ver por que algo que parece simples no Figma pode ser genuinamente difícil de construir e manter. Um engenheiro pode usar IA para explorar por que uma decisão de design que parece cosmética na verdade resolve um problema real de usabilidade. Em vez de cada lado adivinhar o raciocínio do outro, a IA pode ajudar a diminuir essa distância de entendimento.

Usar IA como tutora e tradutora, para ajudar designers e engenheiros a trabalhar melhor uns com os outros, pode ser muito mais valioso no longo prazo do que a empolgação de curto prazo que sentimos ao usá-la para fazer vibe coding e vibe design de tudo por conta própria. A pessoa que entende os dois lados bem o suficiente para fazer as perguntas certas e identificar os problemas certos não vai ser substituída por IA. Essa pessoa é um colaborador, e as melhores equipes de produto com que trabalhei são cheias deles.

Coisas que você pode fazer agora

Não quero encerrar isso como um aviso vago. Aqui estão as coisas que procuro ter em mente como designer trabalhando ao lado de ferramentas de IA:

Desenvolva gosto na disciplina adjacente. Você não precisa ser desenvolvedor para reconhecer quando código gerado está estruturalmente bagunçado. Não precisa ser designer para saber quando um layout gerado não vai escalar. Aprenda o suficiente sobre o outro lado para ser uma crítica útil.

Trate o output da IA como um primeiro rascunho forte, nunca como resposta final. O desenvolvedor do vídeo precisou do próprio julgamento para capturar o erro do menu de navegação. Esse julgamento era dele, não da IA. Seu trabalho é trazer esse julgamento para o que quer que a IA produza.

Seja honesto sobre o que está em jogo. Para um projeto paralelo? Ótimo, faça vibe coding do começo ao fim. Para algo do qual usuários reais dependem? Traga pessoas que sabem o que estão fazendo. O custo de errar se acumula com o tempo.

Busque as colaborações que a IA não consegue substituir. A conversa entre um designer e um engenheiro que entendem profundamente o produto não é algo que se gera com um prompt. Ela produz decisões melhores do que qualquer uma das pessoas faria sozinha. Proteja isso.

Lembre-se de que o teto ainda é feito por humanos. A IA elevou o piso, mas os melhores produtos ainda são construídos por pessoas que se importam profundamente com o que estão fazendo, que se desafiam mutuamente, e que reconhecem quando algo ainda não está bom o suficiente.


São tempos incertos para todos que trabalham em áreas criativas e técnicas. Acho que a resposta honesta para “a IA vai me substituir?” é: depende do que você traz para o seu trabalho além de execução. Se o que você traz é principalmente transformar uma especificação em um arquivo, traduzir um briefing em um layout, implementar um ticket, então sim, essa parte está sendo automatizada. Mas se você traz julgamento, curiosidade, ofício, e um compromisso genuíno de fazer as coisas direito, você não vai a lugar nenhum. Provavelmente é mais valioso do que era dois anos atrás.

O piso subiu. Agora cabe a nós elevar o teto.

Sim, usei IA para me ajudar a estruturar e refinar este artigo.