Tenta descrever o sabor de um sanduíche para a pessoa do caixa de um restaurante. Não apontar para a foto no cardápio, não escolher de uma lista — descrever. Com palavras. "Quero um pão macio, tipo brioche, com uma carne que tenha aquele gosto defumado mas não seco, um molho meio ácido mas não exatamente mostarda, e umas folhas que deem crocância mas que não sejam alface."

A pessoa do caixa vai fazer o melhor possível. E o resultado vai ser aproximado. Não porque ela é incompetente, mas porque linguagem textual é uma ferramenta limitada para transmitir experiências sensoriais. O pão que você imaginou e o pão que ela entendeu são dois pães diferentes, e a distância entre eles é irrecuperável por texto.

Agora substitua o sanduíche por um layout, o caixa por um LLM, e o cardápio por uma interface visual que não existe. Esse é o estado atual das ferramentas de IA para quem trabalha com design.

Joshua Leigh publicou recentemente um artigo que vale a pena ler: The prompt is not an interface — Why AI sent us back to the command line. A tese dele é provocadora e bem construída: para tarefas visuais e espaciais, a interface de prompt é um retrocesso. Quarenta anos de evolução em design de interação — do Sketchpad de Sutherland em 1963 ao iPhone — foram um movimento consistente para longe da linha de comando e em direção à manipulação direta. Primeiro o mouse, depois o toque. A interface colapsando até quase desaparecer entre intenção e ação. E então chegou a IA, e voltamos para o cursor piscando numa caixa de texto vazia. Voltamos a digitar instruções e torcer para ter escolhido as palavras certas.

Leigh sustenta isso com referências sólidas. Cita a teoria de dupla codificação de Paivio: humanos processam informação visual e verbal por canais cognitivos separados, e o canal visual é mais rápido, retém mais e comunica relações espaciais que a linguagem luta para codificar (Paivio, 1971). Cita Bret Victor: as melhores interfaces permitem que você veja e manipule a coisa em si, não que a descreva por uma camada de abstração (Victor, 2011). E faz uma observação que parece simples mas é devastadora: um designer comunica um layout num sketch de cinco segundos que exigiria quinhentas palavras para ser descrito num prompt de texto. E a descrição ainda seria ambígua.

Isso faz muito sentido, mas eu acho que precisamos ir além se quisermos avançar nos usos éticos da IA.

O prompt é o sintoma mais visível de algo mais profundo: as IAs de hoje foram construídas por e para pessoas que usam texto como linguagem primária. LLMs são, literalmente, Language Models. A linguagem é o meio. E as pessoas que decidiram que esse seria o meio são pessoas para quem o texto é a ferramenta natural de pensamento. O terminal, para um engenheiro de software, não é um retrocesso. É o ambiente preferido. Então a interface de prompt não é um acidente, mas sim a consequência lógica de quem estava na sala quando as decisões foram tomadas.

Leigh apresenta o problema como uma dicotomia clara: engenheiros pensam em texto, designers pensam em imagem. E propõe que a solução virá de interfaces visuais — canvas, grafos de nós, ferramentas de manipulação direta com IA embutida. Ele cita Figma Make, ComfyUI, Adobe Generative Fill como sinais de que a GUI da era da IA está chegando. Essas ferramentas são bem-vindas. Mas a dicotomia é falsa. Ou pelo menos muito mais porosa do que parece.

Eu venho da engenharia. Mas também trabalho com design, com ciência de dados, com pesquisa. E o que observo na prática — não na teoria, na prática mesmo, no dia a dia de liderar times mistos — é que engenheiros também desenham o tempo todo para se fazer entender. Criam ilustrações, representações, abstrações. Desenham no quadro branco, rabiscam em cadernos, mandam screenshots anotados no Slack. A linguagem primordial da engenharia não é só texto. É texto e imagem e protótipos e diagramas. A diferença entre um engenheiro e um designer não é que um pensa em palavras e o outro em imagens. É que eles foram ensinados a valorizar linguagens diferentes, e construíram profissões inteiras em cima dessa separação.

A dicotomia é mais ideológica do que real. E é anterior à IA.

Qualquer designer que já tentou documentar uma decisão de design num ticket do Jira sabe disso. Qualquer engenheiro que já tentou explicar uma arquitetura complexa sem desenhar um diagrama também. A tradução entre visual e textual sempre foi problemática. A IA não criou esse problema — ela o amplificou, porque transformou a tradução de um incômodo burocrático no modo principal de operar a ferramenta.

Na prática, o que isso significa para quem lidera times?

Significa que a resposta não é esperar por interfaces visuais melhores. Elas vão chegar, e vão ajudar. Mas o gargalo real não é a ferramenta — é a capacidade de tradução entre linguagens.

O que tenho feito é investir nisso diretamente. Não da forma convencional: não é design thinking genérico, não é workshop de post-its. É algo mais próximo do que se chama design participativo, misturado com uma ideia que peguei emprestada de Paulo Freire: as pessoas precisam ser alfabetizadas sobre um tema a partir de elementos do seu próprio contexto. Não adianta jogar terminologia de design em cima de um engenheiro e esperar que funcione. Você precisa encontrar os conceitos dentro do repertório que a pessoa já tem e construir a ponte a partir dali.

Na prática, isso significou ensinar profissionais de engenharia a pensar elementos críticos de design — não o design operacional de "fazer tela bonita", mas o design estratégico de "compreender o problema antes de resolver." Significou desenvolver a capacidade de articulação: saber avaliar soluções existentes, saber propor alternativas, saber argumentar por que uma direção é melhor que outra com base em evidência. Isso se parece muito com o que o mercado chama de UX research, mas, francamente, é método científico aplicado — definir hipóteses, coletar dados, analisar e iterar.

E a recíproca também foi verdadeira. Precisamos de lideranças em engenharia indicando o que era importante para a gente em design, e então entrar em acordos. A ponte não é unidirecional.

A IA entra nesse processo como uma espécie de melhoria — um marcapasso, se quiser. Ela não substitui a habilidade de tradução entre linguagens, mas melhora a capacidade de profissionais que antes não conseguiam cruzar essa fronteira. Um engenheiro que nunca conseguiria articular um conceito visual agora consegue usar IA para gerar uma primeira aproximação e iterar a partir dela. Um designer que travava na hora de documentar uma decisão técnica agora tem uma ferramenta que ajuda a estruturar o argumento.

Mas — e isso é o ponto central — a ferramenta sozinha não é suficiente. Sem alguém indicando o que é importante, a IA gera ruído, não sinal. Foi preciso uma liderança em design dizendo "isso aqui importa, prestem atenção nestes elementos críticos" e uma liderança em engenharia dizendo "esses são os processos e artefatos essenciais para desenvolver e implementar um software com sucesso." Sem essa mediação humana, o profissional fica sozinho com um LLM que é, por definição, uma ferramenta de texto tentando resolver um problema visual. E aí voltamos ao sanduíche.

Leigh termina o artigo dele dizendo que o futuro da interação com IA não é digitar o que você quer, é mostrar o que você quer dizer. Concordo com a direção, mas acrescento uma camada: antes de mostrar, a pessoa precisa saber o que quer dizer. E isso não é um problema de interface. É um problema de formação, de repertório, de capacidade de operar em mais de uma linguagem ao mesmo tempo. Um problema de pesquisa e compreensão do problema.

Profissionais verdadeiramente multidisciplinares — que transitam entre código, design e pesquisa — sempre existiram, mas sempre foram raros. A promessa implícita da IA é que ela poderia tornar a multidisciplinaridade mais acessível, baixar a barreira de entrada. E ela pode, de fato — desde que haja alguém do outro lado orientando o que vale a pena aprender.

Sem essa orientação, a IA não traduz entre linguagens. Ela só amplifica a linguagem de quem a construiu.

Try describing the taste of a sandwich to the person at the counter. Not pointing to the photo on the menu, not choosing from a list — describing. With words. "I want a soft bun, like brioche, with meat that has that smoky flavour but isn't dry, a sauce that's sort of tangy but not exactly mustard, and some leaves that add crunch but aren't lettuce."

The person at the counter will do their best. And the result will be approximate. Not because they're incompetent, but because text is a limited tool for transmitting sensory experience. The bread you imagined and the bread they understood are two different breads, and the gap between them can't be closed with words.

Now replace the sandwich with a layout, the counter person with an LLM, and the menu with a visual interface that doesn't exist. That's the current state of AI tools for anyone who works in design.

Joshua Leigh recently published an article worth reading: The prompt is not an interface — Why AI sent us back to the command line. His thesis is provocative and well built: for visual and spatial tasks, the prompt interface is a regression. Forty years of interaction design evolution — from Sutherland's Sketchpad in 1963 to the iPhone — were a consistent movement away from the command line and toward direct manipulation. First the mouse, then touch. The interface collapsing until it almost vanished between intention and action. Then AI arrived, and we went back to a blinking cursor in an empty text box. Back to typing instructions and hoping we chose the right words.

Leigh backs this up with solid references. He cites Paivio's dual coding theory: humans process visual and verbal information through separate cognitive channels, and the visual channel is faster, retains more, and communicates spatial relationships that language struggles to encode (Paivio, 1971). He cites Bret Victor: the best interfaces let you see and manipulate the thing itself, not describe it through an abstraction layer (Victor, 2011). And he makes an observation that sounds simple but is devastating: a designer can communicate a layout in a five-second sketch that would take five hundred words to describe in a text prompt. And the description would still be ambiguous.

This makes a lot of sense, but I think we need to go further if we want to advance the ethical uses of AI.

The prompt is the most visible symptom of something more fundamental: today's AIs were built by and for people who use text as their primary language. LLMs are, literally, Language Models. Language is the medium. And the people who decided this would be the medium are people for whom text is the natural tool of thought. The terminal, for a software engineer, isn't a regression. It's the preferred environment. So the prompt interface isn't an accident — it's the logical consequence of who was in the room when the decisions were made.

Leigh presents the problem as a clear dichotomy: engineers think in text, designers think in images. And he proposes the solution will come from visual interfaces — canvases, node graphs, direct manipulation tools with embedded AI. He cites Figma Make, ComfyUI, Adobe Generative Fill as signs that the AI era's GUI is coming. Those tools are welcome. But the dichotomy is false. Or at least far more porous than it appears.

I come from engineering. But I also work in design, data science and research. And what I observe in practice — not theory, actual practice, in the daily reality of leading mixed teams — is that engineers also draw constantly to make themselves understood. They create illustrations, representations, abstractions. They draw on whiteboards, sketch in notebooks, send annotated screenshots on Slack. Engineering's native language isn't only text. It's text and images and prototypes and diagrams. The difference between an engineer and a designer isn't that one thinks in words and the other in images. It's that they were taught to value different languages, and built entire professions on top of that separation.

The dichotomy is more ideological than real. And it predates AI.

Any designer who's tried to document a design decision in a Jira ticket knows this. Any engineer who's tried to explain a complex architecture without drawing a diagram knows it too. Translation between visual and textual has always been problematic. AI didn't create this problem — it amplified it, by turning the translation from a bureaucratic nuisance into the primary mode of operating the tool.

In practice, what does this mean for those who lead teams?

It means the answer isn't to wait for better visual interfaces. They'll come, and they'll help. But the real bottleneck isn't the tool — it's the capacity for translation between languages.

What I've been doing is investing in this directly. Not in the conventional way: not generic design thinking, not post-it workshops. It's closer to what's called participatory design, mixed with an idea borrowed from Paulo Freire: people need to be literate about a subject starting from elements in their own context. There's no point dumping design terminology on an engineer and expecting it to stick. You need to find the concepts within the repertoire the person already has and build the bridge from there.

In practice, this meant teaching engineering professionals to think through critical elements of design — not the operational design of "make pretty screens," but the strategic design of "understand the problem before solving it." It meant developing the capacity for articulation: knowing how to evaluate existing solutions, how to propose alternatives, how to argue why one direction is better than another based on evidence. This looks a lot like what the market calls UX research, but frankly, it's applied scientific method — define hypotheses, collect data, analyse and iterate.

And the reciprocal was also true. We needed engineering leadership telling us what mattered on their side, and then finding agreements. The bridge isn't one-directional.

AI enters this process as a kind of improvement — a pacemaker, if you will. It doesn't replace the skill of translating between languages, but it improves the capacity of professionals who previously couldn't cross that boundary. An engineer who could never articulate a visual concept can now use AI to generate a first approximation and iterate from there. A designer who struggled to document a technical decision now has a tool that helps structure the argument.

But — and this is the central point — the tool alone isn't enough. Without someone pointing out what matters, AI generates noise, not signal. It took design leadership saying "this matters, pay attention to these critical elements" and engineering leadership saying "these are the essential processes and artefacts for successfully developing and implementing software." Without that human mediation, the professional is left alone with an LLM that is, by definition, a text tool trying to solve a visual problem. And we're back to the sandwich.

Leigh ends his article by saying the future of AI interaction isn't typing what you want — it's showing what you mean. I agree with the direction, but I'd add a layer: before showing, the person needs to know what they mean. And that's not an interface problem. It's a problem of education, of repertoire, of the capacity to operate in more than one language at once. A problem of research and understanding the problem.

Truly multidisciplinary professionals — who move between code, design and research — have always existed, but have always been rare. The implicit promise of AI is that it could make multidisciplinarity more accessible, lower the barrier to entry. And it can, in fact — as long as there's someone on the other side guiding what's worth learning.

Without that guidance, AI doesn't translate between languages. It just amplifies the language of whoever built it.