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

The AI in Design 2026 report, run by Designer Fund with Foundation Capital across 906 designers in more than 60 countries, measured what AI is doing to the boundaries between design and engineering. 65% of designers report doing more product management and engineering tasks, and 40% observe the opposite movement, engineers and product managers taking on design work.

A third of respondents say collaboration has become messier, because nobody knows anymore who owns which part of the process, and 20% report that collaboration with human colleagues has decreased. In other words, the functions are converging but the people are drifting apart.

To me, this is further evidence that the real problem is communication. I believe language models can bring developers and designers closer instead of replacing one with the other or increasing the workload. That requires more than a shared process. It requires a shared vocabulary and tools that both design and development teams can use.

Walls of text, or how software projects are still born

To explain why I keep coming back to communication, I need to describe how software projects are still largely created around the world. What follows comes from my experience with consulting operations, professional software services and digital product design.

When it comes to systems sold to external users, the discovery and development workflow is typically determined by the commercial side. What gets delivered is conditioned by what gets promised at the point of sale. Business analysis workshops follow, varying in length, mapping client needs against what the existing system offers.

The sales team closes the scope and the price. It promises design, configuration and custom development to cover the identified gaps and hands it off to other teams to do the work. The problem is that this mapping involves predominantly commercial people, often without a structured requirements elicitation process or user needs mapping. Design, if called at all, comes in later to bring coherence to a system already structured.

Once the sale closes, the delivery team and the people responsible for implementation inherit large volumes of unstructured information and a management model over which they have little influence. The real requirements elicitation starts there, after the signature. Designers rarely participate in business decisions, even today. Clients agree to requirements lists without a real sense of what they are buying, because prototypes to validate concepts before committing to delivery remain rare.

In short, the client signs a contract based on walls of text, with no opportunity to visualize the solution they are buying.

Visualizing software systems has always been a subject of debate, especially when consulting processes are involved. But there is a fairly obvious solution that keeps being sidelined.

A solution older than design and software

From Brunelleschi and the dome of Florence in 1418, through Leonardo da Vinci's countless paper prototypes and the drawings of design engineers, to Figma Make, using visual models to test concepts is a practice older than the profession of designer and far older than software.

Brooks, in the seminal No Silver Bullet (1987), already proposed rapid prototyping as one of the most promising attacks on the essential difficulty of software invisibility. He goes beyond the diagnosis. He names rapid prototyping as one of the most promising attacks on the essence of the problem and, at the same time, states that much of the software acquisition procedure rests on a fundamentally wrong assumption, that it is possible to specify a satisfactory system in advance, contract its construction, receive it and install it. The text is from 1987 and precisely describes the walls-of-text contract model that persists today.

Drawing has always been an integral and inseparable part of engineering. There is a long history of developers and software engineers advocating prototyping at different stages of system creation. Personally, I have always found the sharp distinction between design and engineering in software and digital product development rather strange.

What happens when teams don't share a reference

The literature documents five recurring consequences.

First, information loss at the handoff boundary. The research context that motivated each design decision does not reach the people who implement it.

Second, rework as routine. Errors discovered after implementation cost orders of magnitude more than errors discovered at the concept stage.

Third, isolated decisions on each side. Designers decide without knowing technical constraints and developers interpret without knowing the intended use.

Fourth, redundant effort. The same problems get solved more than once on different sides of the wall.

Fifth, simultaneous accumulation of technical and social debt. Disciplinary separation produces inconsistent code and deteriorated working relationships, and the two debts feed each other.

Enter AI

From 2025 to 2026, weekly use of AI tools across all stages of design jumped from 54% to 91%, and 75% of designers now use them daily. While AI-assisted code and prototype generation is helping designers, engineers and product managers find a common language, it is also making it less clear who is responsible for which part of the delivery. Some of that confusion predates AI, but some of it exists precisely because there was no coherent shared language to begin with.

Specifically in design with AI, the Polish consultancy Boldare documented a pattern that illustrates the consequences of a missing shared language, the component multiplication problem. An AI agent is tasked with creating an interface card, does not consult the library the design team maintains, and delivers a component nearly identical to one that already existed, with slightly different borders. The episode repeats with every rushed task until the day a redesign becomes inevitable.

According to Boldare, the cause is the absence of the infrastructure AI needs to work consistently, starting with a single source of truth consulted by both the people who design and the people who write code.

There are more people in this boat

"Amidst the errors there shone forth men of genius, no less keen were their eyes, although they were surrounded by darkness and dense gloom."Petrarch, c. 1340 (via Mommsen, 1942)

When I started my career as a digital designer, I gravitated toward service design because it felt like a more comprehensive version of the systemic view I had learned in forestry engineering. Including only designers and developers in the discussion always seemed limited to me, even though it is the most common framing. It took me a while to understand why, since the role of design within IT is still maturing.

The separation between design and technology that we see in development teams today is inconsistent with the history of product development and technological progress. Cukierman, Teixeira and Prikladnicki argue that the fragmentation between the technical and the human sides of development impoverishes software engineering, and they recover Lucy Suchman to remind us that plans and models are weak resources in the face of situated action. Brunelleschi was not a designer or an engineer, he was both at the same time. Da Vinci drew war machines and painted portraits in the same notebook, without switching professions between pages. The division came later. In software, where the object is invisible and communication is a documented bottleneck, insisting on that division is, in essence, a modern dark age.

For Petrarch, darkness was not the absence of knowledge, it was the loss of access to knowledge already produced. For software development, the analogy is the same. The knowledge of how to prototype, validate with visual artifacts and draw before building was produced in engineering, architecture and design over centuries. None of it was destroyed. It became confined to disciplines that do not talk to each other, to organizational silos and to commercial processes that operate as if this knowledge did not exist.

The Renaissance recovered the classical knowledge that medieval Europe had stopped consulting. What we need to recover is more modest and more urgent, the practice of drawing before building that we already know and that software stubbornly ignores.

What happens when teams share a reference

Joey Banks, founder of Baseline Design, combined Claude, Figma's MCP server, Claude Design and Claude Code in a single morning. He audited the typography of a large component library, consolidated styles and prototyped a token reference site. The MCP server connects the language of the design library to the language of the code and lets one person move between the two without asking anyone for passage.

I observed something similar on my teams, and I also noticed that, after ups and downs, the group came closer together instead of drifting apart. The downs were not surprising. Brazilian software engineering research registers this pattern: Motta and Cukierman documented how implementing a development model in a public company stumbles less on technique and more on the organization's resistances.

We used language models to help other teams generate prototypes and validate the solution with the client before misunderstandings took root. AI helped, yes, but it was not the main point. I always start the conversation by noting that prototypes in engineering projects have been documented since at least 1500. After that, I talk about shared languages and processes. AI comes in as a means of construction and alignment.

What turned the game was the brute fact that it worked. With clients, the prototypes made the solution easier to visualize and reduced approval friction, because the client finally sees what they are accepting.

A bridge is measured by what it manages to cross. If your team uses AI to write code faster and nobody can explain what the other side of the wall does, what you built accelerates the delivery of the same old misunderstandings.

References

This is part of a series on design, AI and data bias. Previous posts: The AI aesthetic crisis looks like the WordArt one, only worse · If you can't explain it, AI won't help · How I used AI to reverse-engineer my own design