Never mind the prompts, here’s the thinking

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. The fastest-looking part of the process is the one that needs a human holding the scissors.

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.

The Skeptic in the Room

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.

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 sells, but nobody using the product ever sees the tachometer. 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

AI’s real gift is the full arrangement. 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. The old way filled one square. Same five days, we now build the whole grid. 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

One prototype, one source of truth, everything crossing 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. One approved prototype in the center. Everything downstream is generated from it, and stays in sync.

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

Ship the what, lose the why, and six months later this is the view: nobody left who remembers how any of it got here.

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 op