Generation Got Faster. Thinking Didn't.

Your company saw the demo. Concepts that took an afternoon now take twenty minutes. Research that took weeks now takes days. And the second leadership noticed, the ask changed: cut the timeline, ship more, move faster.

So you're stuck. The generation part of the job really did get quicker. But the part that makes design worth doing, the thinking, did not. Let me catch you up on what design leaders are actually doing about it, and where the craft debate is heading.

The part of the job that didn't speed up

One head of design put the split cleanly. "We cut design production time from four days to six or eight hours," they told Kai Wong, then added the part people skip: "optimizing my internal processes, that is the easy part."

That's the whole tension in one quote. AI compressed production. It did not compress judgment. Deciding what to build, why, and for whom still takes real time, and no prompt shortens it.

When you present a faster timeline, name which part got faster. Say the generation dropped from four days to eight hours, and the thinking did not move. That keeps the conversation honest before someone halves your whole schedule.

Faster designs still land wrong in code

Speed on the design side means nothing if the build doesn't match. Nick Babich walked through handing Figma files to Claude Code and finding inaccurate fonts, colors, spacing, and even new UI components the model invented on its own.

The pipe between design and code runs through Figma's MCP server, which passes structured data like frames, components, variables, and layout properties. It works. It just doesn't work as well as the demo suggests, so the gap becomes your review problem.

Budget for that gap. If you promise faster shipping, promise a QA pass that catches the drift too. Faster generation plus sloppy handoff nets you the same timeline, minus the trust.

Speed the user feels, not the speed you cut

Here's a lever that doesn't cost you thinking time. Usman Writes lays out four loading patterns, skeleton screens, progress bars, inline spinners, and optimistic UI, and makes the point that every load is a psychological transaction whether you design it or not.

Pick the wrong loader and you break trust. Pick the right one and the app feels faster with no backend change at all. That's speed your user actually notices, which is the speed that matters.

When leadership wants "faster," ask what they mean. Faster to build, or faster to the user. Sometimes the win is a better loading state, not a shorter sprint.

What the craft people are protecting

While product teams chase compression, the craft world is arguing the other direction. The designboom "Crafting the Future" chapter frames craft as an approach that values attentiveness over speed, collaboration over isolation, and long term stewardship over short term production. Their line on technology is the useful part: it should be measured by the quality of the relationships it supports, not by efficiency for its own sake.

A parallel note came out of Milan Design Week, where Indian practitioners described treating AI as a tool for streamlining non-creative workflows, dropping off where human emotion and tactile intuition begin. That's a clean rule. Let AI handle the mechanical parts. Keep the judgment human.

The deep cut

The risk is not that AI makes bad designs. It's that faster generation quietly resets what your organization thinks design costs. Once a stakeholder sees twenty-minute concepts, four days feels like padding, and they'll price all your work at demo speed.

So do the split out loud, every review. Show the generation time and the thinking time as two separate numbers. Let AI take the first one down as far as it goes. Defend the second one by name. The leaders holding the line aren't refusing to move faster. They're being specific about which part can speed up and which part breaks if you rush it.

Three questions for your team

1. On our last shipped feature, how many hours were generation and how many were thinking? Can we show that split to leadership next review?
2. When we hand designs to AI-assisted code, who owns the QA pass that catches font, spacing, and phantom-component drift, and is that time in the estimate?
3. When someone asks for "faster," do we know if they mean faster to build or faster for the user, and have we checked whether a better loading state gets us there cheaper?