Waiting Breaks Thought

The limits that matter here are old. Response-time research going back to Robert Miller in 1968, later popularized by Jakob Nielsen, gives three rough thresholds: about 0.1 second feels instant, about 1 second keeps your train of thought intact, and past about 10 seconds your attention wanders.

Early code generation lived on the wrong side of that last line. You prompted, waited, checked email, came back, and rebuilt the problem in your head. Every iteration cost a context switch.

Fast models like Gemini 3.5 Flash shrink the wait enough that you stay with the problem. That changes how you work more than how much you ship.

Skip the Picture

Front-end work used to run in sequence. Wireframe, static mockup, approval, then a developer rebuilds it in HTML and CSS. Each handoff loses something.

When generating a working interface is about as fast as drawing one, the mockup stops earning its place. You design in the real thing: real layout, real states, real responsiveness, from the first prompt.

You stop approving pictures of software and start reacting to software.

Work in Small Loops

Fast loops reward small prompts. One giant spec means a long wait and a big change that's hard to judge. Small steps keep every change easy to evaluate.

Clarity Is the Limit

When the wait shrinks, the bottleneck moves to you: how clearly you know what you want.

Fast loops help there too. Seeing a working version is often how you find out what you meant. Build it, look at it, say what's wrong, repeat.