Assisti a um vídeo esses dias que me fez pensar. Um desenvolvedor Android, sem nenhuma formação em design, usou o Claude Code e o Figma MCP pra gerar um conjunto completo de designs de um app mobile a partir de um documento de requisitos em markdown, em mais ou menos uma hora. Depois ele comparou o resultado com o que uma agência de design profissional tinha entregue a partir do mesmo briefing – e os designs gerados por IA ficaram… surpreendentemente próximos.

O vídeo se chama “We don’t need designers anymore” (“Não precisamos mais de designers”), e sinceramente, vendo aquilo, eu entendi a vontade. Já tive esse mesmo pensamento ao contrário, vendo uma IA escrever código surpreendentemente funcional em domínios que eu não conheço. Talvez eu não precise de um engenheiro pra isso.

Vale notar que o cara vende cursos e mentoria pra desenvolvedores mobile, e o canal dele no YouTube faz parte desse marketing. Não invalida a experiência dele, mas significa que os incentivos dele se alinham com uma narrativa específica: a de que desenvolvedores agora dão conta de tudo sozinhos. Um título chamativo como “não precisamos mais de designers” é ótimo pra 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, mas não conta a história toda.

Não estou escrevendo isso pra criticar o vídeo. Estou escrevendo porque as coisas que ele não aborda são justamente as que eu acho mais interessantes, e porque quero pensar sobre pra onde essa indústria está indo, não pra onde o hype diz que ela está indo. Essa sensação de “eu consigo fazer tudo sozinho” é o que eu quero discutir, e acho que ela é real e enganosa ao mesmo tempo.

O que mudou

O que essas ferramentas fizeram com o trabalho criativo e técnico é notável. Uma pessoa que admite abertamente que suas “habilidades de design são uma merda” produziu um conjunto de telas no Figma que qualquer designer olharia e reconheceria como trabalho de verdade. Aquilo está bem além de um esboço ou de um wireframe. Tem um design system ali dentro, a hierarquia tipográfica se sustenta, e os componentes são consistentes. Dois anos atrás isso não existia, e vale celebrar.

Do outro lado acontece a mesma coisa. Já vi designers sem nenhuma formação em desenvolvimento publicarem componentes React funcionando, subirem backends simples, escreverem scripts que resolvem problemas. Coisas que exigiriam meses de estudo 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

A IA baixou a barreira pra produzir, e baixou também a barreira pra você se sentir bem com o que produziu. Você gera algo que parece polido e completo, e esse acabamento acaba grudando em você. Como você não enxerga as falhas que nem sabe que deveria procurar, conclui que está bom.

Iniciantes sempre se superestimaram, e isso é um viés cognitivo bem documentado. Mas tem um estudo recente publicado na Computers in Human Behavior que me deixou incomodado: pessoas usando IA pra resolver problemas de raciocínio lógico melhoraram o desempenho real em cerca de 3 pontos, e superestimaram esse desempenho em 4 pontos. O padrão clássico do Dunning-Kruger, em que os piores se superestimam mais, sumiu. Com IA, todo mundo se superestimou. Maior familiaridade com ferramentas de IA teve correlação com uma precisão pior na autoavaliação, não melhor. Quanto mais acostumado você está com essas ferramentas, mais fácil fica confundir o output delas com o seu próprio entendimento (e sim, estou me incluindo nisso).

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 está pronto” era muito mais fácil de enxergar, porque o resultado bruto de um iniciante era muito mais bruto. O mockup de um estudante de design do primeiro ano parecia o mockup de um estudante do primeiro ano. Hoje pode parecer uma coisa que um designer pleno montou numa terça à tarde, e os dois ficam visualmente indistinguíveis mesmo não sendo a mesma coisa. O iniciante não sabe por que aquelas decisões foram tomadas, nem o que foi sacrificado pra chegar nelas, e não consegue dizer se a navegação vai aguentar conforme o produto cresce, se as cores sobrevivem ao modo escuro, ou se a hierarquia de informação continua fazendo sentido quando dados reais substituírem o texto de placeholder. A IA também não sabe essas coisas. Ela otimiza pra parecer certo.

Comigo acontece a mesma coisa na direção contrária. Consigo levar uma IA a gerar código que compila, roda e passa em testes básicos, e pra mim aquilo parece correto. Mas eu não tenho a intuição de engenharia pra saber se aguenta carga, se a arquitetura escala, se tem alguma condição sutil escondida no meio. Um engenheiro sênior identificaria esses problemas em minutos. Eu não saberia que eles existiam até algo quebrar em produção.

Os limites do bom o suficiente

Voltando ao vídeo: quando ele comparou os designs gerados com o trabalho da agência, ele notou diferenças. O componente de contagem de passos da agência ficou melhor, o dashboard deles era mais cuidadoso, e ele pegou 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 os usuários não esperariam encontrá-la e poderiam acioná-la por acidente. Ele pegou isso porque é um desenvolvedor que já pensou sobre padrões de interação. Um iniciante completo talvez não pegasse.

O que o vídeo passa por cima é que ele estava comparando o output dele com o trabalho de uma agência específica, e achou os dois mais ou menos equivalentes. Se ele tivesse contratado uma agência melhor, a diferença teria sido muito maior. Design profissional existe num espectro, e uma equipe de design de produto realmente boa, que faz pesquisa e design de interação e pensa em sistemas, teria produzido uma coisa significativamente diferente. Mais difícil de comparar por screenshot, mas a diferença nos detalhes que importam com o tempo seria grande.

E vale pros dois lados. Essas ferramentas elevaram o que um iniciante consegue produzir. No teto elas não mexeram. Um backend feito por vibe coding talvez aguente seus 50 usuários beta numa boa. Aí 50.000 pessoas batem no mesmo endpoint ao mesmo tempo, e as escolhas de arquitetura que eram invisíveis em escala pequena viram a diferença entre um produto que funciona e um que cai.

O padrão que a gente repete

De tempos em tempos aparece uma onda de ferramentas que facilita pra uma disciplina fazer o trabalho de outra. O Squarespace deixou não-designers construírem sites, aí o Webflow facilitou mais ainda, aí ferramentas no-code deixaram não-desenvolvedores criarem apps. Toda vez, alguém publica um texto sobre como não precisamos mais de [preencha a lacuna].

E toda vez os profissionais da disciplina supostamente descontinuada passam por um período difícil e depois descobrem que a demanda por eles aumentou, porque mais gente estava construindo coisas e cedo ou tarde essas coisas precisavam ficar sérias. Os sites feitos no Squarespace precisaram escalar, os apps no-code atingiram seus limites, e os sistemas feitos por vibe coding esbarraram em problemas que exigiam expertise de verdade pra resolver.

Projetar ou desenvolver um produto inteiro com ajuda de IA é perfeitamente aceitável quando o risco é baixo. Um projeto pessoal, um protótipo rápido pra testar uma ideia, uma ferramenta interna que três pessoas usam. Quando fica sério, quando usuários reais dependem daquilo, quando o produto precisa crescer e ser acessível e mantível, você não pode confiar em si mesmo nas partes que ficam fora da sua expertise. Ser esperto não resolve, porque boa parte da expertise é saber quais perguntas fazer antes de tudo. Eu consigo fazer vibe coding de uma feature. Só não vou saber o que não sei até que ela quebre.

A IA como tradutora

Acho que essas ferramentas tornaram a colaboração entre designers e engenheiros mais necessária do que ela era, e ao mesmo tempo deram pra gente um jeito bem melhor de fazer isso. É essa a parte que me deixa otimista, e é a que menos aparece nessa conversa toda.

Pensa no que acontecia quando um designer insistia numa animação sutil e o engenheiro lia aquilo como perfumaria desnecessária. O designer não conseguia articular direito o custo técnico do que estava pedindo, e o engenheiro não conseguia enxergar por que aquele detalhe inútil ajudaria alguém a entender uma mudança de estado e a confiar mais na interface. Cada um tinha razão sobre a sua parte, e os dois falavam línguas diferentes.

A IA consegue traduzir entre os dois. Como designer, eu uso pra entender a limitação técnica que está por trás de uma resistência, pra ver por que uma coisa que parece simples no Figma pode ser muito mais difícil de construir e manter do que aparenta. Um engenheiro pode usar no sentido contrário, pra cavar por que uma decisão que parece cosmética está resolvendo um problema real de usabilidade. Em vez de cada lado adivinhar o raciocínio do outro, os dois podem ir lá e conferir.

Usar IA como tutora e tradutora, pra ajudar designers e engenheiros a trabalharem melhor uns com os outros, pode valer muito mais no longo prazo do que a empolgação de curto prazo de fazer vibe coding e vibe design de tudo por conta própria. A pessoa que entende os dois lados bem o suficiente pra fazer as perguntas certas e identificar os problemas certos vai continuar sendo necessária. Todo time de produto bom em que eu trabalhei tinha algumas dessas pessoas.

O que eu tento não esquecer

Uma coisa que ajuda é desenvolver gosto pela disciplina vizinha à sua. Você não precisa ser desenvolvedor pra reconhecer quando um código gerado está estruturalmente bagunçado, nem precisa ser designer pra saber quando um layout gerado não vai escalar. Aprender o suficiente sobre o outro lado pra ser um crítico útil exige bem menos do que ficar competente naquilo.

O que a IA te entrega é um primeiro rascunho, muitas vezes bom, mas um rascunho. O desenvolvedor do vídeo precisou do critério dele pra pegar o problema do menu lateral, e esse critério era dele, não do modelo. Seu trabalho é trazer o seu pra tudo que a IA produzir.

Depois tem a questão do que está em jogo. Pra um projeto paralelo, faça vibe coding do começo ao fim e se divirta. Se tem usuários reais dependendo daquilo, chame gente que sabe o que está fazendo, porque o custo de errar se acumula com o tempo. E proteja as conversas que a IA não tem por você. A conversa entre um designer e um engenheiro que entendem o produto a fundo não é algo que se gera com um prompt, e produz decisões melhores do que qualquer um dos dois faria sozinho.


São tempos incertos pra todo mundo que trabalha com criação ou com tecnologia. Se a IA vai te substituir ou não depende do que você traz pro seu trabalho além de execução. Se o que você traz é principalmente transformar uma especificação em um arquivo, um briefing em um layout, um ticket em código funcionando, então sim, essa parte está sendo automatizada. Mas se você traz critério e ofício, e a curiosidade de continuar perguntando por que uma coisa funciona, mais teimosia suficiente pra não dar por pronto enquanto não funciona, você não vai ser substituído tão cedo, e provavelmente é mais valioso do que era dois anos atrás. Os produtos que eu admiro continuam sendo construídos por pessoas que se importam muito com o que estão fazendo, que se desafiam entre si, e que sabem reconhecer quando alguma coisa ainda não está boa o suficiente. Nenhuma ferramenta automatizou nada disso. O piso subiu sozinho; mexer no teto vai dar trabalho de verdade.

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