Taste — knowing what's good before you can prove it

1. The thing nobody can define

Taste is the skill of looking at a piece of work and knowing whether it's good, before you have an argument for why. A senior engineer reads a pull request and says "this is wrong" — and only after, sometimes the next day, can they tell you exactly which line and exactly why.

The model doesn't have taste. It has averages. It produces the seventy-fifth-percentile version of every pattern. Average is what you want for boilerplate. Average is what you don't want for the parts that matter.

Taste is the human contribution that can't be automated. Not because it's mystical — because it's built from a kind of experience the model wasn't trained on: knowing which of two technically-correct options is the one that won't bite you in six months.

2. Why CS programs don't teach it

Computer science programs teach algorithms, data structures, complexity, languages, theory. They don't teach taste. There's a reason: taste isn't a thing you can grade. There's no answer key. Two senior engineers will disagree on which of two solutions is better, and both will be right in different contexts. A professor can't write that exam.

So you graduate knowing how to implement quicksort and not knowing which of three styles of error handling is the one your codebase should use. Both matter; only one was on the test.

3. What taste looks like in code

Taste shows up at the small decisions. Where to put the boundary between two modules. Whether to name this variable data or pendingApprovals. Whether to use a generic helper or write the inline two-liner. Whether to add this argument as positional, keyword, options-object, or environment.

Examples of taste calls — none of them have a right answer in the abstract:

• A function takes seven parameters. Wrap them in a config object, or split the function into three smaller ones?
• A new feature could go in the existing module that's loosely related, or in a new module that's clean but adds a directory.
• The model produced a working solution that uses three nested ternaries. It compiles, it's correct. Refactor it, or leave it alone?

Each of those, an engineer with taste decides in three seconds. An engineer without taste flips a coin or asks the model, which flips a different coin.

4. How taste is built

Read code. That's the whole answer. Read a lot of code.

The mechanism: every piece of code you read is a data point. Code that was nice to read enters your good bucket. Code that was painful enters your bad bucket. Over time, you stop comparing new code to a definition (because there is no definition) and start comparing it to the thousand examples in your head.

That comparison is taste. The model can do this too, badly, because it read code in training. It can't update its comparisons based on what worked in your codebase last quarter. You can.

5. Where to read code, deliberately

Three sources, in order of leverage:

Your codebase's history. Read pull requests that landed. Read the ones that got reverted, and figure out why. The institutional memory of your team is the highest-leverage code reading you can do, because it tells you what this team considers good.

Open-source projects you depend on. Pick a library you use. Read its source. Not the README — the source. The patterns you see there are battle-tested across thousands of users.

The standard library of your main language. It was written by people who think about this all day. The style is conservative, deliberate, and the patterns generalize.

You don't need to finish reading anything. Read a function, ask yourself would I have written it this way? If yes, why. If no, why not. Then close the tab.

6. The hard part

Taste takes a long time to build and you can't shortcut it by reading about taste. Books on "writing good code" help a little. Reading actual code helps a lot more. Watching another engineer review a PR and explain what they'd change is the fastest acceleration there is.

You won't have taste when you start your first AI engineering job. You'll have it three years in, if you read deliberately the whole time. The model's outputs will improve over those three years too — but the judgment of which output to ship, that's yours.

The next unit is about the skill that taste turns into when you write it down: specification.