Never mind the prompts, here’s the thinking

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 and then 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.

That skepticism is the most valuable thing in the room, and most founders treat it like an obstacle. 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. 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. 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.

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.

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.

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.

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.

In the old world, we’d design desktop first, then mobile, then tablet, then the edge cases. 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.

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. Every one of those pieces lived in its own artifact, and every one of them drifted out of date.

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.

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.

Dust in the Wind

Everybody’s worried about technical debt from vibe coding, the messy, bloated code these tools spit out. 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.

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. 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.

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. Spend it on judgment, and you get the thing you actually came to build. Users never see the model, the infrastructure, or the ninety seconds it took to generate a screen, and they never wanted to.

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. 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.

References and further reading

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.”
• 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”