I spent a year rebuilding my studio’s entire design process around AI. It didn’t make us faster, and that’s exactly why it worked. It also left behind a kind of debt nobody’s talking about.
Everyone is selling you this pitch about AI and design: it’s faster. Ten times faster. Ship in an afternoon what used to take a month, watch a prototype assemble itself while you sip your coffee.
I bought it too.
Then I spent the better part of a year rebuilding my studio’s entire design process around AI, across four real products, with real clients, real deadlines, and collaborating with real engineers who were used to standard deliverables. To be blunt, it didn’t make us faster.
Our sprints took five days before we changed our process and our sprints still take five days.
And look, I drank the Kool-Aid early. I wanted this to blow up how we work, so I told one of my team members we’d be knocking out sprints in three days flat. He’s heard me be wrong before, and this time he didn’t sugarcoat it: he told me straight up it wasn’t going to make us any faster. He was right. We weren’t. What we got instead was a different way of working, a fuller, more finished output, with a whole new set of ways for things to go sideways. Every. Single. Time.
Here’s what that conversation actually sounded like. I was excited, probably too excited, ready to reinvent the future. My COO let me explain the entire thing andthen told me flat out that it wasn’t going to make us faster and I was kidding myself if I thought it would. He’s worked with me, in one way or another, for over 20 years and he knows my rhythm. His skepticism was earned. The instinct isn’t his alone: Ashley Reichheld, Christina Brodzik, Anne-Claire Roesch, Greg Vert and Ryan Youra documented that worker trust in company-provided AI actually fell as the tools got more capable, not less. Of course, Ashley’s point is more about workers distrusting AI itself not the process, but the point is salient.
That skepticism is the most valuable thing in the room, and most founders treat it like an obstacle. Ajay Pundhir has argued that a rollout’s loudest skeptics are usually the ones telling you something true, and the leaders who wave them off as obstacles are the ones who watch their transformations stall.
When you run a studio like Charming Robot, nobody has any distance from your decisions. There’s no department to hide behind, no other org to wait out a bad call in. Retool the process and you’re retooling their day, their craft, the muscle memory they spent years building. Bart Mroz, who built and sold the studio Sumo Heavy, has written about what breaks when agency owners treat their people as resources instead of the craftspeople they are. Of course they push back. They’ve earned the right, usually by being right before.
So you don’t win them with a mandate or a pep talk. You win them by being willing to be wrong out loud, and by letting the work make the case instead of making it yourself. Susan Curtin makes the same point about adoption: what actually moves people is an experience, the thing working in front of them, more than any program or pitch.
I stopped promising speed. I kept the loudest skeptic closest and made him poke holes in every step, then let him watch the output get better instead of faster. Keep your skeptic that close and one day he stops arguing with the process and starts defending it. That’s the day you know it works. Sascha Bosio calls this turning resistance into contribution: hand your sharpest skeptic the validation role and their doubt becomes your quality control.
And that turned out to be the best thing that’s happened to how we work.
Slow Ride
Speed is the headline for so many things AI because speed is easy to sell. It’s sexy in a LinkedIn post. It makes a great slide for your boss who read ONE great article on the plane and now wants to know why the design team isn’t a tenth of the size. And let’s be honest, all over the world, “AI makes it faster” is a headline any CFO can fall in love with.
Designers are already documenting the high. Patrick Neeman wrote about building in a weekend what used to take days, and he’s not wrong that it feels like a different job.
The problem is that it’s the wrong framing.
The person who ends up using what you build never sees your sprint. They see the product. And they have never once cared how fast you made it, only whether it does the thing they showed up to do.
When you optimize a creative process for raw speed, you don’t get better products. You get the same products, just sloppier, sooner and shortsighted. You get what I’ve started calling “high-speed mediocrity,” work that shows up faster precisely because nobody slowed down to think. The internet already named the end state: AI slop, the mass production of stuff nobody thought hard about.
Jakub Krehel put it well: in the age of AI, more things being made doesn’t mean better things are being made, and knowing what not to build might be the most important skill of all.
This is Spinal Tap logic: cranking the amp to eleven and mistaking a bigger number for a better sound. Sure, these bots can generate a screen in ninety seconds, but they can’t tell you whether that screen should exist.
This is the exact moment it turns into Jurassic Park. Jeff Goldblum, slouched in the back of the Jeep in the leather jacket, calls it while everyone else is busy oohing at the brachiosaurus: you get so high on whether you can that nobody stops to ask whether you should. That’s AI right now. It’s the raptor that figured out the door handle: brilliant, confident, and completely uninterested in whether it should. Confuse those two and you’ll ship faster, then watch the thing eat the lawyer off the toilet.
Whole Lotta Love
Once we retooled the process, it clicked. This is the part AI is actually good for, and it’s worth a whole lot more than speed. Same idea of a five-day sprint we’d always run, but the new version of those five days delivered real value, to us and to the client.
Here’s an example:
We’re rebuilding a subscription media product right now, the kind where what you see on any given page depends entirely on who you are. Logged out. Logged in with no subscription but a recognized email. Several paid tiers, each unlocking something different. Five user states. On every page. Across desktop, tablet, and mobile.
In the old world, none of this was corner-cutting. It was taking turns. We’d design desktop first, on purpose, because you start on the biggest canvas and earn your way down (some people prefer to do the opposite and start with mobile. I fundamentally disagree with this approach, but that’s another conversation).
Desktop gets built, gets reviewed, gets approved. Then mobile, which is never just the desktop screen squeezed skinny, because nobody uses a phone the way they use a laptop and the design has to respect that. Then tablet. Then the edge cases, the empty states, the logged-out stranger, the guy whose subscription lapsed back in March.
Every one of those was good work. Every one was also its own build, its own review, its own week or two on the calendar. Line them up and a single product becomes a relay that runs for a month, each leg boxing in the legs that haven’t run yet.
Before anyone accuses me of sneaking speed back in through the side door: the sprint is still five days, and nobody here got faster at design. What went away was the relay.
This time, we built all five states at once. Live. Interactive. Flip a toggle and watch the page rearrange itself for a logged-out stranger versus a power subscriber. Switch to mobile and it’s already there. Same five days, an order of magnitude more product. The work got deeper, and depth was the thing that, for years, blew out schedules and drove us crazy with minute details in UX and design.
It’s the difference between handing someone a demo and handing them the full multitrack, every instrument already laid down, so you can finally hear what the song actually sounds like instead of imagining the parts that aren’t there yet.
Ever heard the demo for “God Only Knows” by the Beach Boys? It’s pretty good. But add in the Wrecking Crew at Brian Wilson’s direction and you get what Paul McCartney called the greatest song ever written. Same song, basically same length, but what changed was that the whole mix was finally cohesive.
Come Together
Here’s the part the engineers in my life care about most. It’s where all the scattered pieces finally come together into a single source of truth.
The old handoff was laborious, and the information kept shifting as we moved through each step. It still does. We’d write a PRD up front, a document for designers, engineers, and everyone else to read ahead of time and agree on scope before anyone touched a pixel. Then we’d pair it with wireframes, a Figma file, and sometimes a prototype to show the interactions that mattered. The intent was all there, on paper, everything defined before a line of code got written.
Who updated the PRD when the designs moved? Who fixed the wires when engineering hit something harder to build than we’d all assumed, and how long did that take? Every one of those pieces lived in its own artifact, and every one of them drifted out of date. So the engineer had to stitch the truth together by hand, a Frankenstein’s monster built from a PRD, a Figma file, and a Slack thread, every single time. And like any good Frankenstein-ing, at least one of those parts had died weeks ago and nobody told it yet.
None of this is a new complaint. People have argued for years that the clean handoff is as much of a reality as Middle Earth, that a design file goes stale the moment it’s passed along, and that the truth was always living in the code.
Now the brief comes first too, written up front and approved by engineering before anyone opens an AI tool.
What’s different is what comes after. Once the design is locked, the system generates the documentation and the component library straight from the approved, working prototype: user stories, flow maps, error conditions, acceptance criteria, implementation notes, and the components themselves.
This is the shift Darren Yeo traced when Figma hit its AI moment: product work is moving off the static canvas and toward code and agentic workflows, where the working build becomes the thing everything else answers to.
It all describes the product that actually exists, so the careful, detailed work that used to land at the very end of a project, if it landed at all, now happens in the middle, while there’s still time to change it.
And because that documentation is generated from the prototype instead of maintained next to it, it cannot become out of date. Every change order rebuilds it. Move a state, kill a screen, rethink a flow, and the user stories, the acceptance criteria, and the error conditions regenerate to match what is actually there. You can lay the docs and the working prototype side by side and catch a contradiction in seconds, while it is still cheap to fix.
Remember the Frankenstein problem, the part that died weeks ago and nobody told it yet? This is the version where the monster tells you. When something in the prototype stops making sense, an orphaned state, a flow that leads nowhere, a screen nothing points to anymore, the system surfaces it and asks the only question that matters: do you want to revive this, or clear it out? Nothing gets to quietly rot in the corner because everyone was too busy shipping to notice.
So engineering stops guessing and starts building from the real thing instead of a six-week-old description of it. Fewer “wait, what did you mean here” Slack threads, fewer surprises in QA, less rework two sprints later. That is worth a hell of a lot more than shaving a day off the calendar.
Dust in the Wind
Now the part where I stop selling you and start warning you.
Everybody’s worried about technical debt from vibe coding, the messy, bloated code these tools spit out. And they do. Ask the AI to remove something from a prototype and it will frequently “remove” it by writing more code, not less. It’s the world’s most confident pack rat. That debt is real, and it’s manageable.
The one that’s really going to hurt you is much more subtle and is rarely communicated. It’s the why. Why this flow and not that one. Why this default, this state, this tradeoff. The AI never writes that part down, because the AI never had a reason in the first place.
Because AI is so good at producing a confident, finished-looking deliverable, the temptation is to let the prototype become the spec, to let the thing that looks done stand in for the thinking that was supposed to happen first.
That said, others, like Nicola Piedimonte, are flagging the same trap: an AI-generated prototype is probably not a prototype yet, because looking finished is not the same as proving an experience works. The bot hands you an answer with total confidence and zero rationale, the HAL 9000 of design tools. It’ll build the wrong thing beautifully, in that same calm and reassuring voice, and never once mention that it’s wrong.
Six months later, someone on your team is staring at a feature asking why it works this way, and the honest answer is: nobody knows. The prototype became the spec by accident. Nobody wrote the thinking down, so the thinking is just gone.
So we built the process to make “nobody knows’” impossible. Every sprint opens with an experience brief, not a PRD, and that brief has to answer the why before anyone opens an AI tool: why this flow, why this default, why these states and not others. Claude only ever builds from the brief.
Then, once a concept is approved, Claude generates the documentation back out of the working prototype: user stories, flow maps, error conditions, acceptance criteria, interaction rules, all of it. The reasoning goes in before the first prompt is given and comes back out the second the prototype is real, and it regenerates every time the prototype changes.
The loop allows us to never lose sight of how things are updated, and how the dev team can expect specs. Nobody on my team has to reverse-engineer their own thinking from three weeks ago, because the thinking was on paper before the beautiful, confident, probably-wrong screen ever existed.
This way you’re not the one who pays for a loss of knowledge transfer and neither is some poor bastard who inherits this thing a year later does, guessing at decisions nobody bothered to write down.
Freewill
So here’s where the whole thing actually lands: on judgment, on the calls that are still yours to make.
AI does give you something back. It’s not a factor of five days down to three, but a lot more you can get done inside those same five days. Whether that turns into a gift or a liability comes down to what you do with it.
Spend it on more output, and you get high-speed mediocrity, a firehose of confident screens nobody thought hard about.
Spend it on judgment, and you get the thing you actually came to build. Because a product, the thing a person actually pays for, is an outcome. Time back. A hard thing made easy. The quiet confidence that the tool gets what they’re trying to do. Jakob Nielsen named this the first new interaction paradigm in sixty years: with AI, you specify the outcome you want and let the machine work out the how. Which makes knowing what outcome is worth wanting the whole job.
This is Jobs-to-be-Done, the idea that people hire a product to get a job done. Nobody wants the quarter-inch drill, they want the quarter-inch hole.
Users never see the model, the infrastructure, or the ninety seconds it took to generate a screen, and they never wanted to.
AI can churn out raw material all day. Deciding what a person should ever see, what to bury, and how to shape all that capability into something that feels effortless is the part you can’t prompt for. That’s judgment. That’s the part that stays human.
Nate Jones has been hammering this daily: once the cost of output drops to near zero, the bottleneck moves from speed to taste and judgment, the parts you can’t prompt your way around.
None of this is about slowing down to feel virtuous. It’s the only thing that turns all that horsepower into work you can stand behind instead of a mess you’ll be cleaning up later.
That’s why we still start every sprint with a brief, the problem, the user, the job to be done, the states, the success metric, before anyone opens an AI tool. It’s why exploratory work stays in a scratch branch, and only approved, reasoned work crosses into the lane that goes to engineering.
It’s why a human still makes every call about what’s worth building, and whether a thing is good enough to put your name on.
WarGames had it pegged back in 1983: sometimes the only winning move is not to play. Sometimes the only winning move is not to ship. Product thinking is still a human job. It always was, and a sharper tool doesn’t change that. As Aurélie Radom put it, your design system runs on one person’s judgment, and AI is about to prove it.
The tools got dramatically more capable this year. Our judgment is the only thing that decides whether that capability makes the work better, or just makes the mediocrity arrive on time.
So no, your AI design process isn’t faster. Mine isn’t either.
We need to reframe the question from how fast AI can make us to what do we do with the time it hands back? Spend it on output and you’ll win the race to the bottom, adding more cowbell to a song that was already done. Spend it on thinking, on taste, on getting the hard parts right while there’s still time to change them, and speed stops being the point entirely.
Brian Wilson got the greatest song ever written by hearing the whole arrangement in his head before the band played a note. Speed had nothing to do with it. That’s the job. It always was.
This is the cleanest way to answer Fabricio’s last note, and you’ve already got every link from our work together. Here’s a ready-to-paste “References and further reading” section, grouped by the article’s arc so a reader can jump to whatever pulled them in. Drop it under the Brian Wilson close.
References and further reading
If any of this interested you, here’s where to go deeper. These are the people whose thinking shaped the piece.
On chasing speed
- Patrick Neeman, “The Generative AI Prototype Revolution”
- Jakub Krehel, “Less Is More, More or Less”
- Kezia Jungco, “What Is AI Slop?”
On the handoff and a single source of truth
- Noah Davis, “The Designer-Developer Handoff Is Still Broken”
- Beau Ulrey, “Single Source of Truth Is a Lie”
- Darren Yeo, “Rethinking Figma in an AI World”
On vibe coding and the prototype-as-spec trap
- Simon Willison, “Not All AI-Assisted Programming Is Vibe Coding”
- Nicola Piedimonte, “Your AI-Generated Prototype Is Probably Not a Prototype Yet”
On judgment, taste, and outcomes
- Jakob Nielsen, “AI: First New UI Paradigm in 60 Years”
- Nate B. Jones, “Your prompts are disposable. Your rejections compound. Here’s the skill nobody is developing (+ the guide kit to start)”
- Dolphia, “Your Design System Runs on One Person’s Judgment”
- Aurélie Radom, “The Organizational Cost of Low Taste”
- Clayton Christensen and Theodore Levitt, “Clay Christensen’s Milkshake Marketing”
On leading a team through the change
- Bart Mroz, “People First: Why Workers Shouldn’t Be Viewed Solely as Resources”
- Ajay Pundhir, “Your Resistant Employees Know Why Your AI Adoption Is Failing”
- Susan Curtin, “Why AI Adoption Is Really About Trust”
- Sascha Bosio, “AI Change Management: From Skeptics to Champions Without Mandates”
- Ashley Reichheld and Christina Brodzik, “Workers Don’t Trust AI. Here’s How Companies Can Change That”
Never mind the prompts, here’s the thinking was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More