O relatório AI in Design 2026, conduzido pela Designer Fund com a Foundation Capital a partir de 906 designers em mais de 60 países, mediu o que a IA está fazendo com as fronteiras entre design e engenharia. 65% dos designers relatam fazer mais tarefas de gestão de produto e de engenharia, e 40% observam o movimento contrário, engenheiros e gerentes de produto assumindo trabalho de design.

Um terço das pessoas entrevistadas diz que a colaboração ficou mais confusa, porque já não se sabe quem é dono de qual parte do processo, e 20% relatam que a colaboração com colegas humanos diminuiu. Ou seja, ao que parece, as funções estão convergindo, mas as pessoas estão se afastando.

Para mim, isso é mais uma evidência de que o problema real é de comunicação. Acredito que modelos de linguagem podem aproximar desenvolvedores e designers em vez de substituir uns pelos outros ou aumentar a carga de trabalho. Para isso, além de um processo compartilhado, é necessário criar um léxico em comum e ferramentas que possam ser usadas tanto por times de design quanto por desenvolvedores.

Paredes de texto, ou como projetos de software ainda nascem

Para explicar por que insisto no tema da comunicação, preciso contar como projetos de software ainda são largamente criados no mundo. O que descrevo a seguir vem da minha experiência com operações de consultoria, serviços profissionais de software e design de produto digital.

Quando se trata de sistemas que são vendidos para usuários externos, tipicamente o fluxo de trabalho de descoberta e desenvolvimento é determinado pela parte comercial. Ou seja, o que será entregue é condicionado pelo que é prometido na hora da venda. A seguir, são realizados workshops de análise de negócio, com duração variável, que mapeiam as necessidades do cliente em relação ao que o sistema existente oferece.

A equipe comercial fecha o escopo e o preço. Promete design, configuração e desenvolvimento sob medida para cobrir as lacunas identificadas e entrega para outras equipes realizarem o trabalho. O problema é que esse mapeamento envolve predominantemente pessoas da área comercial, muitas vezes sem um processo estruturado de elicitação de requisitos ou de mapeamento de necessidades do usuário. O design, se for chamado, entra depois para dar coerência a um sistema já estruturado.

Fechada a venda, a equipe de entrega e os times responsáveis pela implementação herdam grandes volumes de informação desestruturada e um modelo de gestão sobre o qual têm pouca influência. A elicitação real de requisitos começa ali, depois da assinatura. Designers raramente participam das decisões de negócio, mesmo hoje. Clientes concordam com listas de requisitos sem a real dimensão do que estão comprando, porque protótipos para validar conceitos antes de comprometer-se com a entrega continuam raros.

Ou seja, o cliente assina um contrato com base em paredes de texto, sem oportunidade de visualizar a solução que está comprando.

A visualização de sistemas de software sempre foi tema de debate, ainda mais quando envolve processos de consultoria. Mas existe uma solução bastante óbvia que segue sendo jogada para escanteio.

Uma solução mais antiga que o design e que o software

De Brunelleschi e a cúpula de Florença em 1418, passando pelos inúmeros protótipos no papel de Leonardo da Vinci e plantas de projetistas de engenharia até o Figma Make, usar modelos visuais para testar conceitos é uma prática mais antiga do que a profissão de designer e muito anterior a softwares.

Brooks, no texto seminal No Silver Bullet (1987), já propunha o uso de técnicas de prototipagem rápida como uma das frentes mais promissoras à essência do problema de invisibilidade do software. Ele vai além do diagnóstico. Nomeia a prototipagem rápida como um dos ataques mais promissores à essência do problema e, ao mesmo tempo, afirma que boa parte do procedimento de aquisição de software se apoia numa premissa fundamentalmente errada, a de que é possível especificar um sistema satisfatório de antemão, contratar sua construção, recebê-lo e instalá-lo. O texto é de 1987 e descreve com precisão o modelo de contrato baseado em paredes de texto que persiste até hoje.

Desenhar sempre foi parte integral e inseparável da engenharia. Existe um longo histórico de desenvolvedores e engenheiros de software defendendo o uso de prototipação em diferentes estágios da criação de sistemas. Pessoalmente, sempre achei estranha a aguda distinção entre design e engenharia no campo do desenvolvimento de software e de produtos digitais.

O que acontece quando não se usa a mesma referência

A literatura documenta cinco consequências recorrentes.

Primeira, perda de informação na fronteira do repasse. O contexto de pesquisa que motivou cada decisão de design não chega a quem implementa.

Segunda, retrabalho como rotina. Erros descobertos depois da implementação custam ordens de grandeza mais do que erros descobertos na fase de conceito.

Terceira, decisões isoladas de cada lado. Designers decidem sem saber as restrições técnicas e desenvolvedores interpretam sem saber a intenção de uso.

Quarta, redundância de esforço. Os mesmos problemas são resolvidos mais de uma vez em lados diferentes do muro.

Quinta, acúmulo simultâneo de dívida técnica e dívida social. A separação disciplinar produz código inconsistente e relações de trabalho deterioradas, e as duas dívidas se alimentam mutuamente.

Entra a IA

De 2025 para 2026, o uso semanal de ferramentas de IA em todas as etapas do design saltou de 54% para 91%, e 75% dos designers passaram a usá-las diariamente. Apesar de a geração de código e protótipo com uso de IA estar ajudando designers, engenheiros e gerentes de produto a encontrarem uma linguagem em comum, também está tornando mais confuso quem é responsável por qual parte da entrega. Parte dessa confusão antecede a IA, mas parte se deve justamente a não ter existido uma linguagem coerente desde o início.

Especificamente para o design com IA, a consultoria polonesa Boldare documentou um padrão que evidencia as consequências da ausência de uma linguagem compartilhada, o problema da multiplicação de componentes. Um agente de IA recebe a tarefa de criar um cartão de interface, não consulta a biblioteca que o time de design mantém e entrega um componente quase igual ao que já existia, com bordas ligeiramente diferentes. O episódio se repete a cada tarefa apressada até o dia em que o redesign se torna inevitável.

De acordo com a Boldare, a causa desse problema é a ausência da infraestrutura de que a IA precisa para trabalhar com consistência, a começar por uma fonte única de verdade consultada tanto por quem desenha quanto por quem escreve código.

Tem mais gente nesse barco

“Em meio aos erros brilharam homens de gênio, seus olhos não eram menos aguçados, embora estivessem cercados de escuridão e densa penumbra.”Petrarca, c. 1340 (tradução a partir de Mommsen, 1942)

Quando comecei a carreira de designer no meio digital, me interessei mais pelo design de serviço porque me parecia uma versão mais abrangente e mais próxima da visão sistêmica que aprendi na engenharia florestal. Por isso, incluir apenas designers e desenvolvedores na discussão me parecia limitado, embora seja o mais comum de encontrar por aí. Demorou para eu entender o porquê, já que a própria função do design dentro do ambiente de TI ainda está em processo de amadurecimento.

A separação entre design e técnica que vemos em times de desenvolvimento hoje não é coerente com a história do desenvolvimento de produtos e avanços tecnológicos. Cukierman, Teixeira e Prikladnicki argumentam que essa fragmentação entre o lado técnico e o lado humano do desenvolvimento empobrece a engenharia de software, e recuperam Lucy Suchman para lembrar que planos e modelos são recursos fracos diante da ação situada. Brunelleschi não era designer ou engenheiro, era as duas coisas ao mesmo tempo. Da Vinci desenhava máquinas de guerra e pintava retratos no mesmo caderno, sem trocar de profissão entre uma página e outra. A divisão veio depois. No software, onde o objeto é invisível e a comunicação é um gargalo documentado, insistir nessa divisão é, em essência, uma idade das trevas moderna.

Para Petrarca, a escuridão não era ausência de conhecimento, era perda de acesso ao conhecimento já produzido. Para o desenvolvimento de software, a analogia é a mesma. O conhecimento sobre prototipar, validar com artefatos visuais e desenhar antes de construir foi produzido em engenharia, arquitetura e design ao longo de séculos. Nada disso foi destruído. Ficou restrito a disciplinas que não conversam entre si, a silos organizacionais e a processos comerciais que operam como se esse conhecimento não existisse.

O Renascimento recuperou o conhecimento clássico que a Europa medieval tinha deixado de consultar. O que precisamos recuperar é mais modesto e mais urgente, a prática de desenhar antes de construir que já conhecemos e que o software teima em ignorar.

O que acontece quando se usa a mesma referência

Joey Banks, fundador da Baseline Design, combinou o Claude, o servidor MCP do Figma, o Claude Design e o Claude Code numa única manhã. Auditou a tipografia de uma biblioteca grande de componentes, consolidou estilos e prototipou um site de referência de tokens. O servidor MCP conecta a linguagem da biblioteca de design à linguagem do código e permite que uma pessoa transite entre as duas sem pedir passagem a ninguém.

Observei algo similar nos meus times, e também percebi que, depois de altos e baixos, o grupo se aproximou em vez de se afastar. Os baixos não surpreenderam. A pesquisa brasileira em engenharia de software registra esse padrão: Motta e Cukierman documentaram como a implantação de um modelo de desenvolvimento numa empresa pública esbarra menos na técnica e mais nas resistências da organização.

Usamos modelos de linguagem para ajudar outros times a gerar protótipos e validar a solução com o cliente antes dos mal-entendidos. A IA ajudou, sim, mas não foi o ponto principal. Sempre inicio as conversas lembrando que se sabe da existência de protótipos em projetos de engenharia pelo menos desde 1500. Depois disso, falo que precisamos de linguagens e processos compartilhados. A IA entra como meio de construção e alinhamento.

O que virou o jogo foi o fato bruto de que funcionou. Com os clientes, os protótipos facilitaram a visualização da solução e reduziram a fricção de aprovação, porque o cliente finalmente vê o que está aceitando.

A ponte se mede pelo que consegue atravessar. Se o seu time usa IA para escrever código mais rápido e ninguém consegue explicar o que o outro lado do muro faz, o que vocês construíram acelera a entrega dos mesmos mal-entendidos de sempre.

Referências

Esse texto faz parte da série Design, IA e viés de dados. Os anteriores: A crise estética da IA parece com a do WordArt, só que pior · Se você não consegue explicar, a IA não vai ajudar · Como usei IA para fazer engenharia reversa do meu próprio design