Every designer I know can see more than they can build.
You look at something and know it's wrong before you can say why. You look at someone else's work and know exactly what's carrying it. Then you sit down to make your own version and out comes a slightly worse relative of the thing in your head.
That gap is the job, and nobody warns you about it, because the discourse is all about developing taste and developing taste is the easy half. Taste turns up years before skill does. You will spend a long time able to recognize work you can't yet produce, which is a miserable and completely normal place to be.
What's changed recently is where the gap sits.
The old gap was execution
Five years ago the distance between seeing it and having it was mostly labor. You knew how the interaction should feel. Getting there meant a week in Figma, a spec, a conversation with an engineer, two rounds of “not quite,” and a build that was maybe 80% of the idea and shipped anyway because the sprint ended.
Most of what died in that pipeline died from cost rather than from being wrong. The idea was fine and it wasn't worth finding out.
So teams got good at guessing instead. You'd argue about a prototype in a meeting because building two versions and comparing them was more expensive than having an opinion about them.
The new gap is judgment
That cost is mostly gone and I don't think the field has caught up to what it means yet.
We build real prototypes now. Not clickable mockups, actual running code with keyboard behavior and state that persists. Working out the editor's navigation, we built seven of them, each arguing a different model, each named, all of them still running today so you can open two in adjacent tabs and argue about the real difference rather than about what you remember version two feeling like. That was not available to a company our size in 2021. It now costs an afternoon.
Sounds like the gap closed. It moved. When producing options is cheap, having options stops being the constraint and choosing between them becomes the constraint, and choosing is exactly as slow as it has always been, because it's made of judgment and judgment doesn't have a productivity curve.
Volume looks like progress
The failure here is easy to describe and very hard to notice from inside.
You generate five directions in a morning and it feels tremendous. You show all five. Everyone reacts to all five, shallowly, because there are five, and now you're holding twenty pieces of feedback spread across five artifacts with no way to reconcile them. So you build a sixth thing that averages the first five, and it's worse than any of them were.
The tell is a review where nobody disagrees strongly. Real disagreement needs a real proposal to disagree with. If everything on the table is provisional then everyone stays polite, and polite reviews produce mush.
What we do about it is require every prototype to argue one thing, in a sentence, written before the build. Not “improvements to the editor.” One activity stream read three ways. Navigation as configuration rather than as a sidebar. If the sentence is fuzzy then the prototype will be fuzzy, and you'll have spent a day making something nobody can react to. The test is whether a reviewer could disagree with the sentence without opening the thing.
What actually got cheaper
Being wrong faster. That's the whole benefit, and it's a large one, but it's worth saying plainly because “we ship faster” usually gets said as though speed were the point. Speed isn't the point. The wrong idea getting found on day two instead of week six is the point.
Some things that got cheap: trying an idea you're only 30% sure about, building the version you expect to lose just to have something to compare against, and keeping a version alive after it's lost.
The last one turned out to matter more than we expected. We had a prototype whose entire thesis was removing the sidebar. A reviewer said plainly that she liked the sidebar, and the thesis lost. But that same prototype had invented a navigation composer, a staged draft model, and derived live-state, all of which carried into the version that won. A version can lose its argument and still donate its machinery, which is only true if losing doesn't mean deleting.
What got harder
Knowing when to stop, mainly.
When the marginal prototype costs a week, you stop without having to decide to. When it costs an afternoon, nothing stops you, and a team can spend a month in a state of extremely productive-looking indecision.
There's also a subtler thing, which is that everything looks finished now. A generated prototype arrives with real type, real spacing, plausible copy, states you hadn't thought about. It reads as much further along than it is, and reviewers respond to the finish instead of the idea. You ask about the model and get feedback on a button radius. We handle this by being explicit about what's under review and blunt about what's fake, and it half works.
Designers who merge code
Our designers work in the codebase. Not in a design-tokens-are-code sense. They open PRs.
Less radical than it sounds by now, and more consequential than people expect. Two things come out of it.
The handoff stops being a document. A spec is never complete, and the gaps get filled by whoever implements it either way; the difference is whether that happens invisibly or on purpose. One of our commit messages puts it better than I can: where the design was silent I chose and noted. As an artifact that beats a spec, because it records the decisions a spec by definition couldn't contain.
The second thing is that engineers get their attention back for problems only they can solve, and nobody's week goes into translating a Figma frame into flexbox.
There's a real cost too. A designer in the codebase is a designer not looking at the whole, and someone still has to hold the system. That doesn't happen automatically, and if you don't name whose job it is then it's nobody's, which we found out the slow way.
The part that doesn't change
None of this makes taste arrive any faster.
You still develop it the same way, by looking at an enormous amount of work closely, making things that fall short, and noticing the specific way they fall short. There's no shortcut in there and the tools don't supply one. If anything they raise the stakes, because when execution is cheap the only thing separating your output from anybody else's is the quality of your judgment about what to make. Good outcome if you have taste. Bad one if you were relying on being fast.
I find that clarifying, most days. The gap between what you can see and what you can build used to be filled with labor and now it's filled with decisions, which has made the work more interesting and considerably less forgiving.