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