The design process used to start with research and end with building something new. Today it begins with a prompt, or a few visuals pulled from Claude or Cursor. We used to sit together to understand the problem, brainstorm ideas, collect and sort them, pick a few, agree on a direction, and only then build the screens in Figma and hand them to engineering.

This article traces that shift: how AI has sped product development up, what it is quietly disrupting, and how we keep both people and AI agents at the center of what we make.

Working on something new changed how we approached all of it. We started by understanding the user problem, then went straight to iterating ideas and reacting to feedback with AI tools. We shipped quickly. And usage fell away after about a week.

It solved a problem that almost nobody actually had: the kind that an afternoon of real interviews would have caught before any line of code was written. The work was clean and well‑made. It simply answered a question no one was asking.

It took 2 days to build. That's both the gift and the trap.

The old sequence wasn't ceremony. We put research first because building was expensive and asking was cheap. A team could lose months on the wrong idea, so we spent a little time up front to avoid spending far more later.

Then building got cheap. A working prototype stopped costing weeks and started costing an afternoon. Once the expensive part became the cheap part, the order we had always followed quietly stopped making sense.

A prototype used to take three weeks. Now it takes an afternoon. That part is real, and it genuinely changes what a small team can do in a day.

But it's worth being careful with the numbers people quote. Maze's 2026 report found that 69% of researchers now use AI, and 63% say it speeds up their research. That's research turning around faster not products getting better. Building faster doesn't make us more right. It mostly lets us be wrong more quickly, and at a larger scale.

Those are research cycles, not shipping cycles. There is no evidence that building faster makes products better; it merely speeds up being wrong.

The deeper shift is quieter than speed. We've stopped building from what we watch people actually do, and started building from what the model tells us they would do.

It's a seductive trade. The model is always available, never needs scheduling, and answers at two in the morning in full, confident sentences. But a generated user is a model of a user, not a user — and it's most confident in exactly the places it's wrong. For a familiar problem, its guess is usually fine. For something genuinely new, the distance between the imagined user and the real one is where products quietly die.

For a familiar problem, the guess is fine. For a new one, the gap between the guessed user and the real one is where products quietly fail. As Anushriya Bhardwaj puts it in "Don't build, solve first": make sure you're solving the right problem before you build. The model will help you build the wrong thing, beautifully.

The answer isn't to go back to six-week research phases, and it isn't to ship whatever the model hands us. It's to put the two in the right order build first, then research against the thing you built.

Make two or three rough versions quickly. Put them in front of real people, in production, with analytics running. Let the prototype become the study. People react to something real far more honestly than they answer a question about something imaginary.

Some things sit outside all of this. Money, health, anything regulated, anything you can't undo there, a wrong build isn't a dead feature, it's a cleanup operation. Those still earn their research up front.

We are moving from designing pixels to designing protocols and systems.

There's a second audience now, and it doesn't have eyes. AI agents are starting to use the things we build, and they don't read layout they read labels, structure, and data. An unlabeled delete icon simply doesn't exist to them.

Clear structure has quietly become a functional requirement rather than a finishing touch, and it belongs in the work from day one. It's the shift Anushriya Bhardwaj traces in "Designing for AI". we're moving from arranging pixels to designing the systems and protocols underneath them.

Build faster. Build with the model. Just don't mistake the model's answer for the user's.