A Year Rebuilding Around AI: Why Design Sprints Didn't Get 10x Faster: Dan Maccarone told his team they'd knock out design sprints in three days flat. His COO of twenty years let him finish the whole pitch, then said it wasn't going to make them any faster and he was kidding himself if he thought it would.
A year later, across four real products with real clients and real engineers, the sprints still take five days. The COO was right.
"Our sprints took five days before we changed our process and our sprints still take five days." That's the sentence that should end the 10x conversation. It won't, but it should.
Our sprints took five days before we changed our process and our sprints still take five days. That's the sentence that should end the 10x conversation.
Someone bet on that number out loud, rebuilt an entire studio around it, and watched it not move.
The flat number is the finding. Not the failure — the finding. Because when you look at where the time actually went, the 10x promise turns out to be measuring the wrong layer of the work entirely.
Start with what the demos actually show you. Someone connects Figma to an AI tool, types a sentence, and a working screen appears in seconds. It looks like the whole problem is solved.
Then you try it on your own project and it falls apart, and you assume you did something wrong. You did not.
As Christine Vallaure puts it, the demos show you one clean layer working under perfect conditions. Your actual work needs three or four layers stacked together, and nobody shows you the stack, because the stack is where it gets messy and half-solved.
Look at the Figma-to-code pipeline as evidence of exactly this. The MCP connection lets an AI read your real file — your colors, your spacing, your fonts, the actual structure instead of a screenshot.
But it reads your values, not your code. It sees a button, copies the color and the corners, and has no idea your team already has a real, reusable button sitting in the codebase. So it quietly builds a fresh lookalike every time.
That gap is one layer. Above it sits another: the markdown file, the plain-text note holding the rules you'd never write on the canvas but always follow. "Use the quiet button for secondary actions." "Never two loud buttons on one screen." The AI can't infer any of it; someone has to write it down, maintain it, and correct it every time the model gets it wrong.
Each of those layers is real, useful, and half-solved. Stack three or four of them and the clean demo becomes a workflow full of seams that a human has to hold together. The speed you saw in the video lived entirely in the one layer that was already fast.
That's the core of it. Design work — UX work especially — was never primarily an execution problem.
The time sinks were never the pixels. They were understanding what problem you're actually solving, navigating stakeholder opinions that contradict each other, interpreting a vague brief from a PM who's also figuring it out in real time, and making judgment calls that need context no model has.
Those parts are stubbornly human, and they were never going to get faster because Figma added an AI sidebar. What AI sped up was the layer that was already relatively fast.
And when you accelerate the fast part of a process while leaving the slow part untouched, you don't get a faster process. You get one where the bottleneck becomes more visible and more frustrating, because now there's a pile of generated assets waiting on the other side of every slow decision.
Niyati Gupta names the shift cleanly: AI dramatically lowered the cost of making things. It has not lowered the cost of choosing badly. When artifacts become cheap, evidence becomes the scarce resource.
Then there's the tax nobody put on the timeline. Pallavi Sharma describes the exact scene: forty-five minutes crafting the perfect prompt, generating twelve variations of a UI component, reviewing all of them, realizing none are quite right — and then finally sitting down and designing the thing yourself.
It takes another twenty minutes. It looks better. And a quiet, uncomfortable thought surfaces: was any of that necessary?
This is the new work nobody budgeted for.
It's not a niche complaint from designers resistant to change. It's structural. Generative tools produce options, options require evaluation, and evaluation takes time and judgment.
When a tool generates a hundred variations in the time you used to sketch five, you haven't eliminated the choice problem. You've amplified it. The research community already named it: choice overload. More options lead to slower decisions and more second-guessing, not better ones.
Then there's the meeting everyone recognizes. A PM walks into a stakeholder review with a polished AI prototype, expecting to discuss the concept and the user problem.
Instead the room spends forty-five minutes on the wrong conversation. "Is this our font?" "Our buttons don't look like this." "Where did the sidebar go?" The prototype never saw the existing product, so it doesn't match it, and the concept discussion gets postponed while the mockup gets rebuilt.
The feature decision — the one that actually matters — didn't get made. And nobody puts that delay on a chart.
There's a subtler version of the same failure. The states that don't exist until they exist in production, as bugs.
The empty state, the loading state, the partial-data state, the offline state nobody mentioned because it seemed unlikely. When AI generates a screen in twelve seconds, it answers "what should this look like?" without first answering "what does this need to handle?" And because the output looks finished, it gets treated as a decision rather than a draft.
Per Figr, a research team at Stanford reportedly interviewed twenty-two product team members and found the tension exactly there: exploration collapsing into execution because the output looked too good to question. That's the real cost of speed — not a slow tool, but a fast one that lets you skip the thinking and pay for it three cycles later.
So the flat number isn't a disappointment. It's the honest reading of a process where the accelerated layer was never the constraint, and the constraint — decisions, states, judgment, verification — absorbed every hour AI handed back.
Anka Tomaka, over four years into running discovery workshops for regulated industries, expected her six weeks to compress to two or three. It didn't. AI absorbed the laborious parts — reading her way into insurance regulations went from weeks to hours — and handed the time back.
The time didn't turn into speed. It turned into decisions. When she asked Google AI Studio for a reviewer queue, it reportedly returned a fluent screen built around a giant cyan trust score and a one-tap APPROVE — a rubber-stamping nudge built on the average case, served on a screen whose entire job is to review the cases that aren't average.
The tool proposed. The judgment about how "human-in-the-loop" should work in the UI was still hers, and landing on that interpretation still took two weeks. AI doesn't decide. AI proposes. The decision stays with the person accountable for what ships.
So we work faster and slower at the same time. Faster in handling information. Slower, deliberately, in deciding.
Which is why Maccarone stopped promising speed and did something better with his loudest skeptic: he kept the COO closest, handed him the job of poking holes in every step, and let him watch the output get better instead of faster. One day the skeptic stops arguing with the process and starts defending it. That's how you know it works.
Here's the reframe that makes the flat number useful. Speed was always the wrong thing to measure. The person using what you build never sees your sprint — they see the product, and they've never once cared how fast you made it, only whether it does the thing they showed up to do.
Optimize a creative process for raw speed and you don't get better products. You get the same products, sloppier and shorter-sighted — high-speed mediocrity that shows up faster precisely because nobody slowed down to think.
What AI actually bought Charming Robot wasn't a smaller, faster team. It was a fuller, more finished output and the room to slow down where slowing down pays.
So budget accordingly. Plan for the timeline that doesn't move and the decisions that get better. If you walk in expecting three-day sprints, you'll cut the wrong five days.
The sprints still take five days. That was never the bad news. That was the point.