I want to weigh in on how AI can be used effectively within the design process. My bias here is that I’m on the tools — I’m spending my days migrating design systems for LLM legibility, learning new AI tools while also pushing project work, and thrashing around like a junior designer again moving a chunk of my process to prototyping first in code.
It’s an exciting time, but it’s also exhausting!
In talking to my peers and in consuming far too much AI content — there’s a tension I’m feeling when discussing how AI can speed up delivery. The fear is usually that quality will suffer — which quickly turns into a vague conversation about intuition, judgment and craft romanticism. Outside of design teams, the conversation gets harder still, with any opinion that isn’t explicitly “AI is the answer” framed as being protectionist, or somehow against progress.
I think I finally understand how AI can be used to aggressively speed up delivery, while also protecting craft and quality. Both can be true. But it requires a little bit of a reframing.
I’m intentionally keeping this post unpolished because the conversation is evolving rapidly, and I don’t want this to come across as instructional. But bear with me as I try to articulate what I’m seeing and hearing in the industry — and why I’m hopeful for the future.
First of all, quality is impossibly hard to define.
It means different things depending on the company or the problem at hand. The amazing Katie Dill recently described Stripe’s definition of quality as “powerful, well-crafted and beautiful”. Love that. But she also acknowledges that those words are deeply subjective and difficult to operationalize.
This is the common trap: compressing “quality” into “it looks beautiful” or “it functions perfectly”. Those are increasingly table stakes, and honestly AI can absolutely maintain that bar.
All I’ll say is this: quality is not how something looks.
Second: every good designer I’ve ever known has wanted to get their work into customers’ hands by yesterday. Faster has always been the agenda. We compromise on completeness, polish and certainty in the name of learning and delivery all the time. Almost nothing I’ve designed that exists in production looks exactly how I imagined it would. So this isn’t some argument for protecting slowness either.
The problem is that a lot of AI discourse collapses “building software” into a single activity, and then asks how we can do that activity faster than before — and faster than competitors.
But in my experience, speed-to-market is usually just one side of the equation. There are usually two distinct modes of producing work:
Discovery 🌱 — Deciding what should exist.
Delivery 🚀 — Efficiently producing the thing once that decision exists.
The AI conversation is asymmetrically biased toward delivery.
AI has been transformative for this phase because delivery is, and always has been, largely convergent (to borrow some old framing from the forbidden double diamond). Quality here is measurable through consistency, accessibility, robustness, performance and compliance.
Delivery behaviors are observable, optimizable and measurable. Ticket throughput, implementation speed, PR velocity, code generation — this is where almost every product team is currently focused (me included). Fin by Intercom has done this masterfully.
This matters because, until now, turning ideas into production-quality software has been an expensive, multi-team process shaped by tooling, organizational structure and whoever currently owns the workflow. Delivery has historically been frustratingly slow, and designers are often seen as the bottleneck in this process because we typically hold the role of gatekeepers between requirement and execution.
But now… with the right tooling, systems and documentation, it’s entirely reasonable to bark at an LLM… “make this real”…and get high-quality implementation back in minutes instead of weeks. That’s incredible progress, and extremely exciting for so many reasons.
Not least because design is no longer a blocker.
I can see a near-term future where designers and engineers increasingly focus on the “last mile” — refining edge cases, improving consistency, documenting patterns and reviewing outputs. We’ll be the human-in-the-loop.
And yes, that kind of review-oriented role sounds threatening until you realize it’s actually what many of us — and our executive teams — have always wanted. Faster iteration, shorter feedback loops, more time learning from customers. This is palatable because there’s an entirely separate part of the process we’re overlooking:
Discovery is upstream of delivery. It’s the messier part of the process… more ambiguous, more human and far harder to articulate. It’s the part that has always been obvious to people closest to the tools, but difficult to explain outside vague words like intuition and feel.
Importantly, this isn’t exclusive to design. Great engineering teams have their own discovery phase too — architecture, systems thinking, tech-debt, scalability, security and long-term maintainability are all forms of upstream judgment work. AI can accelerate implementation dramatically, but many of the most valuable engineering contributions still live in deciding how something should exist — not just producing it quickly.
In the design world, practitioners have always known that the hardest and most valuable part of product work was never the pixels or implementation layer. What defines a quality outcome — one that lasts and has meaningful impact — is teams who can:
The best product work rarely comes from executing a brief perfectly. It comes from realizing the brief itself was incomplete, shallow or asking the wrong question entirely. Playing in this space is messy, but it’s where great ideas come from, including the understanding that the first version is something to be suspicious of.
The delivery phase works well with AI because best practice exists. That space is compressible into repeatable patterns, structures and rules. Discovery is different, and harder to structure around AI because the qualities that produce great outcomes are far less deterministic, and much harder to measure (or even describe). They require:
An LLM can absolutely generate ideas — sometimes excellent ones — but it does not possess the empathy, lived experience or understanding of consequence to land on any of the above with conviction. Left to operate independently during discovery, AI instead tends toward consensus outcomes: competent, coherent and familiar. Useful for execution, dangerous for differentiation. As Anton Sten put it, AI is remarkably good at producing average.
When involved in discovery, AI is the participant in the group that says “yes” to everything with breathless enthusiasm, but rarely produces ideas that change the conversation… that generate smiles. Which is why, during discovery, the relationship needs to flip: not human-in-the-loop, but AI-in-the-loop.
This is actually a really interesting and under-represented area of AI tooling — where AI is used in divergent activities (like Design Agents in Figma) rather than as a tool to expedite the finish line. Think AI for mood-boarding, finding inspiration or disposable prototypes.
Before we all start championing 2010-era design sprints again (please no), there’s an important caveat: not every problem deserves deep discovery work.
Sometimes “good enough” really is good enough. A huge amount of software work is operational — CRUD interfaces (administration, signup, login, payment flows etc), internal tooling, growth experiments, parity features and cleanup etc — these activities don’t require designers challenging the brief. A settings page is rarely the moment to ask “how do we make this magical?”.
These are the moments where AI can be the efficiency boost for design teams. When the problem doesn’t require a unique angle, and can be easily solved by jumping straight into Claude, or coding a solution into production through Cursor — we should start there. AI accelerates us to the finish line faster than ever before.
In these cases — discovery can absolutely be skipped, compressed or resolved through a short conversation. We just need to be honest about where deep attention and judgment matter — and where AI can simply unblock easy wins.
AI just can’t play every role equally well.
Now AI has compressed delivery so aggressively, discovery becomes the dominant differentiator between products (read 🦑 ‘Designing beyond Beige’). If you automate that layer entirely, what’s left is quickly-built, cheaply-made, average software… same as everyone else.
And look, that might be good enough for some companies — I won’t pretend that Design is the only lever to success. But it’s becoming apparent that the companies who will thrive in the AI era won’t just be the ones shipping software the fastest. They’ll be the ones that can take ideas to market efficiently while still maintaining a clear point of view.
They’ll create products people don’t just use because they’re functionally complete, but because they feel distinct. Products like Notion, Clay and Stripe stand out to me as strong examples of this commitment to product clarity and differentiation. Ironically, AI companies themselves understand this more than anyone — which is why they continue investing so heavily in product and design teams.
Because as execution becomes commoditized, judgment becomes the differentiator.
So for now, my goal is to get dramatically faster at deciding what’s worth making — while also protecting the parts of the process that produce original, enduring ideas. Then use AI to compress everything that comes after.
In the same way designers will increasingly operate in the “last mile” of delivery, I think there’s incredible opportunity in the early incubation phase too — where vague problems are shaped into durable ideas before delivery even begins.
And importantly, discovery isn’t owned by design teams. The best product organizations create environments where great ideas can come from anywhere — engineering, support, leadership, research or directly from customers themselves.
Just don’t expect AI to fill that role.