When AI can build anything, taste is the bottleneck

I can now build almost anything in an afternoon. That sentence would have sounded like bragging two years ago. Today it is just Tuesday. I describe a feature to Claude Code, it writes the code, I run it, it works. The bottleneck used to be typing. It is not typing anymore.

So what is the constraint now? It is knowing which of the thousand things I could build is the one worth building. The model hands me infinite options and most of them are mediocre. The scarce skill is recognising the right one and rejecting the other ninety-nine. That skill is taste, and it has quietly become the whole job.

Cheap code makes bad direction expensive

When building was slow, direction was cheap by comparison. You spent three weeks writing the thing, so a day spent arguing about whether it was the right thing felt like a rounding error. The cost of the build dominated everything.

Flip the build cost to near zero and the ratio inverts. Now the expensive mistake is not a slow implementation. It is a fast implementation of the wrong idea. AI will happily build the wrong thing, beautifully and quickly, and hand it to you polished. It has no opinion about whether the thing should exist. It cannot tell you the feature is a distraction. It just builds what you point it at.

That is the trap. When output is free, you generate more of it, and more mediocre output is not progress. It is just more to wade through and eventually delete.

Where taste actually shows up

Taste sounds vague, so let me make it concrete. It is not a mood. It is a series of specific calls that the model cannot make for you.

• The shape of a flow. The model can build a three-step form or a one-screen form. Both work. Knowing that this particular user, doing this particular task on their phone, needs it to be one screen with a big obvious button - that is taste. The code is identical difficulty either way. The judgement is not.
• Naming. A function called handleData and one called recalculatePainScore both compile. One tells the next person what the system is. Good names are a taste decision made a hundred times a day, and the model defaults to the bland one unless you push.
• What to leave out. This is the big one. Restraint is a taste decision. The model never says "you don't need this." It will add the extra setting, the second view, the configurable option nobody asked for, and each one looks reasonable in isolation. Saying no to nine good-looking features so the tenth can breathe is a thing only a human does.
• Done versus technically-works. "It runs without errors" and "I would put my name on this" are different states. The gap between them - the empty state that is actually helpful, the error message a real person can read, the loading case you did not spec - is entirely taste. The model reaches "works" on its own. It does not reach "done" without someone who knows the difference dragging it there.

None of these are hard to implement. All of them are hard to decide. And the deciding is now the expensive part.

You cannot outsource the judgement

The tempting move is to try to make the model have taste for you. Better prompts, more context, a longer spec. It helps at the margins. It does not close the gap.

Because taste is not a fact you can look up. It is a compressed sense of what matters, built from having shipped things and watched real people use them and felt the specific embarrassment of a tool that missed the point. The model has read about that. It has not felt it. So it will confidently produce something plausible and slightly wrong, and only a person who has the taste can see that it is slightly wrong.

I have watched myself accept a generated solution that was clean, correct, and subtly off - it solved the problem I described instead of the problem the client actually had. The code was fine. The direction was mine to get right, and I had pointed it one degree off. No amount of model quality saves you there. The model executed my judgement faithfully. My judgement was the flaw.

The value moved, it did not disappear

There is a fear that when anyone can generate code, the person who used to write it is worth less. I think the opposite happened. The value did not vanish. It concentrated.

The parts of the work that AI does well - the typing, the boilerplate, the wiring - were never the parts a good engineer was really being paid for. They were the tax you paid to get to the decisions. AI paid that tax. What is left is the part that was always the actual value: knowing what to build, knowing what good looks like, knowing when to stop. That part got harder to fake, not easier, because now it is the only thing left that is scarce.

So the skill I lean on most today is not a language or a framework. It is the ability to look at a working thing and know whether it is right, and the nerve to throw out a perfectly functional version because it is not.

When code is cheap, that is what a client is actually buying. Not keystrokes - those are free now, and they know it. They are paying for someone who can tell the right build from the ninety-nine wrong ones, and who will say no to the shiny distraction on their behalf. The typing was never the point. The judgement always was. It just used to be hidden behind the work.

If you have a tool that technically works but you can feel is missing the point, that gap is usually a taste problem, not a code problem. An intro call is a good place to find out which.