Code you didn't write

When you write code by hand, most of your taste gets used without your noticing. You pick a name, decide a function is getting too long, notice that two cases are really one case. These decisions happen at typing speed, which is slow, so there's time to make them. If you have bad taste, you make bad decisions slowly, and the slowness limits the damage.

AI coding tools take away the slowness. You can now get a few hundred lines of plausible code in less time than it takes to read them. So what happens to taste when you're no longer the one typing?

The obvious answer is that it becomes a filter. The model proposes, you judge. That's true as far as it goes, and it already makes taste matter more than it did, because you're judging far more code than you'd ever have written, and judging is harder than writing. When you write a function yourself you know why each line is there. When you read one someone else wrote, you have to reconstruct that, and code that looks fine is the hardest kind to check, because nothing makes you stop.

But I think the filter view misses the bigger part. By the time you're reviewing output, most of the important choices have already been made: what to build, how to split it up, what to leave out. If you ask for the wrong thing, the model will build the wrong thing well, and good taste at review time can only tell you it's well built. So the taste that matters most comes earlier, in knowing what to ask for. Suppose you ask for a caching layer when the real problem is that you're fetching the same data in three places. You'll get a nice cache. What you needed was to delete two of the fetches.

Won't the models just develop taste themselves? I suspect they'll get very good at one kind of it. They already know the idioms of most languages better than most programmers, and local judgment about code (this loop should be a map, this name is misleading) is the sort of thing you can learn from lots of examples. What's harder to learn from examples is taste about your particular problem: which complexity is essential and which is accidental, what users will actually do, which part of the system is going to change next year. That depends on knowing what the program is for, and that knowledge mostly lives with the people who own it.

So the kind of taste worth developing is shifting. Being able to tell clean code from messy code is still useful, but it's becoming the part the tools can help with. Knowing what shape a program should have before anyone writes it is the part they can't do for you yet, and it's also the part with the biggest effect, since every line the model writes inherits it.

Which suggests something slightly odd. If AI writes most of the code, the best way to get better at AI coding might be to spend more time thinking about problems and less time thinking about prompts. I'm not sure how far that goes. But if I had to bet on which programmers will get the most out of these tools, I'd bet on the ones who already knew what they wanted.