AI in product development: what’s still holding it back

The pressure is real: Product teams, and product managers in particular, are under pressure not only to monitor AI but also to actively implement it. Tools are being introduced, pilot projects launched, and budgets approved.

And yet, many teams feel that less has changed than expected in day-to-day product development. Not because AI isn’t capable of anything, but because there’s still too little discussion about where it really makes a difference and what needs to be in place for that to happen.

What AI already achieves in the product development process

AI is not a single tool, but rather a cross-cutting technology that is applied at various stages of the product development process. Here’s a brief overview:

On the development side

The most advanced area: AI can generate code, analyze and improve existing code, generate documentation from code, and create test cases. Development teams are already using it productively, especially for repetitive, structured tasks.

On the product side

Among other things, AI helps refine requirements, analyze user research data, and distill user feedback into actionable insights. The rule is: The more structured the input, the more useful the output.

At the intersection of design and development

One of the most promising areas is the conversion of designs into code. AI can generate front-end code directly from finished design files, thereby automating the most time-consuming part of the handoff between the design and development teams.

This is precisely where many teams are currently pinning their greatest hopes. Yet the hoped-for acceleration often fails to materialize.

Why there are still obstacles

The hopes are understandable: Handing off finished designs to the development team takes a lot of time, generates follow-up questions, and often causes sprints to fall behind schedule. And because the process can, in theory, be easily automated, AI seems like a particularly obvious solution here: The task is repetitive, the input appears structured, and the desired outcome is clearly defined. These are precisely the conditions under which AI works well.

No wonder, then, that many teams have high expectations here. What we see time and again with our clients: The design has been approved, the team uploads the file to an AI tool, and a few minutes later, code is generated. At first, everyone is happy. Except that the developers can hardly use this code. Buttons look different on various screens. Spacing is off. Components have been generated multiple times, even though they’re supposed to be the same. And the generated code often doesn’t fit the development team’s existing architecture: it has to be reworked before it can be integrated into the codebase. What was intended to save time ends up requiring extra work. The sprint hasn’t gotten any shorter; it’s just been redistributed.

Teams respond by switching tools, adjusting settings, or switching to new providers. A quarter later, the same pattern repeats itself. The effort involved in evaluation, migration, and onboarding comes on top of that, and the underlying problem remains. It’s not the tool’s fault.

What’s almost never asked in these situations: What have we actually given this tool?

What is almost always overlooked

AI doesn’t create order. It works with the order that already exists, or doesn’t exist.

The idea of uploading a design file and generating code from it sounds simple. But AI interprets the design file exactly as it is structured. It recognizes patterns when they’re present and generates consistent code when the input is consistent. If the input isn’t consistent, the output reflects that exactly.

AI amplifies what it finds.

AI doesn’t just need the finished design as input; it needs the underlying structure: a design system built in such a way that a machine can work with it. That’s exactly what’s missing in most processes.

The design file itself is never neutral. It reflects how systematically, or unsystematically, the underlying designs are structured. The design system, or the lack thereof, is already embedded in it before AI generates even a single line of code.

Having a design system isn’t enough

Most companies today have a design system. That’s the good news. The less good news: Often, it isn’t yet machine-readable.

Many design systems work well as a shared reference for design and development teams, as a means of communication, and as a visual language. But they aren’t structured in a way that allows AI to reliably generate production-ready code from them. The bar has been raised.

Maturity level, not availability

A design system that works for AI isn’t just another tool: it has a higher level of maturity. The crucial question is whether a machine can understand it. Assessing this is no simple matter, as it is neither purely a design issue nor purely a development issue. If you want to understand where your own design system stands, the design system maturity model is a good place to start. But the real work begins with asking the right questions.

Three signs that your design system is still holding back AI

It’s not always immediately obvious whether AI can work well with your design system. Often, this only becomes clear when a pilot project fails to deliver the expected results. Here are three signs we see time and again:

Generated code takes longer than code written by hand

Although AI has generated code, developers spend a lot of time reviewing, understanding, correcting, and adapting it. Often, the output is so far from being a usable foundation that it isn’t even worth correcting, and the team has to start from scratch. The tricky part: It’s almost impossible to predict when this will happen. Product managers usually notice it indirectly: The sprint isn’t getting any shorter, even though the tool is running. Effort estimates become less reliable because no one knows in advance whether the generated code will be usable. The bottleneck has simply shifted: from writing to reviewing and correcting.

Same elements, different results

A button that appears on ten different screens is interpreted and generated differently by AI ten times. The real problem: The button exists as a component, but instances have been manually overwritten somewhere, variants have slightly different names, and states are missing. To humans, everything looks the same, but AI sees different objects. The result: an inconsistent UI that gets flagged in QA, confuses users, and creates rework loops that no one had planned for. What’s particularly tricky is that the problem isn’t visible in the design itself. It only becomes apparent when AI turns it into code.

Before any AI can be used, someone has to prepare the design file

Before AI can be deployed, someone on the team often has to clean up the design file: standardize naming conventions, add missing states, and resolve inconsistencies. This isn’t an AI-specific problem, as the same gaps exist even when the work is handed off to human developers. The difference: Experienced developers are familiar with the project, the components, and the conventions. They compensate for gaps in information by drawing on their specific wealth of experience. AI cannot do this; it works only with what is in the file.

What product managers can do right now

PMs can support the team by asking the right questions, setting priorities, and leading discussions differently: That’s your leverage. Three shifts in mindset can help.

Not: Which tool is the right one? But rather: What is the input?

If the answer to this question is “our Figma file,” the next question is: Is it structured in a way that a machine can work with it? Often, that’s the moment when it becomes clear where the investment really belongs: not in the next tool subscription, but in the foundation that makes every tool work in the first place.

Not: Do we have a design system? But rather: Can a machine work with it?

Most teams have answered the first question, but few are asking the second one yet. A design system can work well for people, as a reference, a means of communication, and a common language between design and development, yet still be useless for AI. When you bring this question to your design team, you’re kicking off an important process.

Not: Design systems as a design topic. Rather: Design systems as infrastructure.

If you think of the design system as an API or a database structure, you automatically set different requirements for it and can prioritize it differently. Infrastructure doesn’t belong to one team; it serves the entire process. With this framing, an internal design project becomes a strategic decision with its own budget, its own owner, and a place on the roadmap, rather than a never-ending side project that’s never quite finished. The question “Who is responsible for the design system?” suddenly takes on a different sense of urgency, and the answer “the design team, somehow” is no longer sufficient.

The question that makes all the difference

AI is fundamentally changing the way product teams work. But this change isn’t happening uniformly or automatically. Teams that have the right foundation in place will benefit from it.

The difference rarely lies in the tool itself. It depends on whether the design input is structured in a way that AI can work with it. The crucial question isn’t just for the design team: it needs to be addressed at a higher level and answered structurally. Could a machine understand our designs?

If you want to know how far along your design system really is, we’ve developed a structured approach to help you get started. The AI Readiness Check gives you a clear assessment of where you stand, complete with specific recommendations on the next logical steps.