The design industry is currently having a very loud conversation about AI. Designers shipping code to production. Handoff models becoming obsolete. Teams going from concept to working product with three people and no engineering background.

This conversation is real. The momentum is genuine. For the organisations at the frontier, it's clearly unlocking something important.

But there's a problem with it. It's being presented as the story of the whole market, when it's actually the story of a very small part of it.

What the frontier looks like, and who's actually there

Remote.com announced recently that every product designer on their team has now shipped code to production. Intercom made a similar move. Atlassian published its workflow for designers shipping code. These are meaningful milestones.

But the organisations generating this content share a specific profile: product-led, digitally native, relatively flat in structure. They were already shipping fast and already blurring the line between design and engineering before AI arrived. For them, AI tools didn't change the direction; they simply accelerated it. The infrastructure was already there. The culture was there. The appetite was there to begin with.

They have the most to say because they're moving the fastest. But they are not the whole market.

The data makes this clear. 88% of organisations report using AI in at least one business function. Fewer than 40% have scaled beyond pilot. The gap between the conversation and the reality is wide, and that's before you narrow it to design specifically.

We've been here before

When Spotify published their product and design team model (squads, tribes, chapters, guilds) something predictable happened. Every organisation, from early-stage startups to global enterprises, tried to copy and paste it directly into their own structure.

For the vast majority, it didn't work. Not because the model was flawed, it was built with genuine intention, for Spotify's specific context, their size, their culture, their ways of working. What's less well known is that one of the model's own co-authors later acknowledged that even at Spotify, it was more aspiration than reality. It described where they wanted to get to, not where they actually were.

The organisations that got something useful from it weren't the ones who implemented it wholesale. They were the ones who understood why it was built the way it was, extracted what was relevant, and adapted it to their own context.

The same logic applies now. The question worth asking isn't "how do we do what the fastest-moving are doing?" It's "what is it about their context that makes this possible, and how much of that actually exists here?"

The organisations nobody is writing about

There's a much larger category that rarely appears in the feed. Enterprise scale. Complex structure. Design functions that might be five or even fifteen years old. Teams sitting inside organisations where the primary product isn't software, or where it is, but the organisation wasn't built around software thinking.

In these places, the conversation looks completely different. Some teams are genuinely exploring AI tooling; there are designers inside large financial institutions, healthcare companies, and global manufacturers running experiments and building fluency. That exploration is real.

But alongside it sits a longer, older list of open questions that haven't gone away. How do we define what design is here? Who owns it? How does it connect to strategy? What does a senior designer actually do at this scale, and how do we develop one?

These are the questions we encounter most often in enterprise conversations. They're not going away because there's a shinier conversation happening elsewhere.

The organisations making real progress in this space aren't the ones chasing external benchmarks. They're the ones who have been honest about where they actually are and started asking what they need to build before they can build anything else. In many cases, the real bottleneck isn't technology, it's the absence of the foundations needed to deploy it with any coherence. Trying to import AI-native practices before those foundations exist isn't acceleration. It's noise.

The scale-up problem

There's a third category worth naming. Scale-ups: companies that have grown quickly, hired a design team in the last few years, and are now trying to work out what they've actually built.

These organisations often have the energy of the product-led companies, the speed, the ambition, but they're encountering for the first time the complexity that comes with scale. Inconsistent practices across teams. Design systems are struggling to hold. Designers hired as generalists are now being asked to go deeper.

The most useful question for a design leader in this position usually isn't about AI adoption at all. It's about coherence. Is there a shared understanding of what design is for here? Is the team building capability that will compound over time, or filling seats and shipping work?

Those are the foundations. Without them, moving faster just produces more of the wrong thing, faster.

What this means in practice

Every designer and every design leader should be engaging seriously with what AI can do. The pace of change is real. The implications for the discipline are real. Ignoring it isn't a neutral position.

But the question isn't whether to pay attention, it's whether you're letting the loudest part of the conversation define the problem you think you're supposed to be solving.

The problem looks different depending on where you are:

For the product-led, digitally native team: speed, craft, and the handoff problem. AI-native design is a direct answer to that.

For the enterprise design function trying to establish its place in the organisation: relevance, structure, alignment. The answer looks different.

For the scale-up trying to hold together a team that grew faster than its foundations: coherence and development. Different problem again.

None of these organisations is behind. They're at different points, with different needs, operating under different constraints. Benchmarking against organisations that don't share your context isn't useful, it just produces anxiety in people doing genuinely important work.

The question that actually matters

What problem are you actually trying to solve?

There's a version of design maturity that's about craft; how good the outputs are, how rigorous the research. But there's another version that's about infrastructure. Does the organisation know what design is for? Does it have the capability to develop designers over time, not just hire them?

A lot of organisations are still building that second kind. Not because they're slow, but because it's genuinely hard, takes time, and there's no shortcut.

The most useful thing any design leader can do right now: resist the urge to benchmark against organisations that don't share your context. Get honest about the specific problems in front of you. What's actually holding your team back? What would need to be true for the next stage to be sustainable?

You don't need to be ahead. You need to be oriented.

At Gale & Co., we work with organisations at every stage of that journey, from enterprise teams establishing the foundations to scale-ups building coherence and product-led teams hiring at pace.

If you're trying to work out where you are and what comes next, let's talk.