Taste Is Fast (and Earned) Orientation

Taste is one of the most abused words in software development.

People use it when they mean judgment. They use it when they mean preference. They use it when they mean “instinct,” hunch, gut feeling, vibe, or “I have an idea.” Sometimes they are pointing at something real. Sometimes they are trying to end the conversation before the thinking starts.

In software, taste is not magic. It is fast orientation. It is pattern recognition built from experience, consequences, mistakes, production failures, painful rewrites, good reviews, bad reviews, and years of watching systems either hold together or come apart.

But taste only becomes useful when it is examined.

Taste can tell you where to look. It does not get to be the evidence.

Taste Has Many Names

Engineers do not always say “taste.” They say, “This feels wrong.” They say, “My gut says this is risky.” They say, “I have a hunch this will not scale.” They say, “My instinct is to split this out.” They say, “This gives me bad vibes.” They say, “I have an idea for a cleaner way.” They say, “This just feels better.”

Those are all signals. Some are valuable. Some are noise. None of them are proof by themselves.

This matters because the same language means different things depending on who is using it. A senior engineer saying “this feels wrong” may be compressing twenty years of pattern recognition into one sentence. A junior engineer saying “this feels like a good idea” may be skipping the work of examining an untested preference.

The words sound similar. The underlying mechanism is not.

Senior Taste Is Fast Orientation

In The Loop Is the Easy Part, I wrote about John Boyd’s OODA loop: Observe, Orient, Decide, Act. The part everyone skips is Orient. Orientation is the model you use to make sense of reality. It is the context, experience, training, standards, and judgment that tell you what matters.

That is what good senior taste is: orientation running fast.

The senior engineer looks at a pull request and spots a smell before they can fully explain it. The controller is too thick. The name is misleading. The dependency points the wrong way. The abstraction is trying too hard. The test setup is painful. The business rule is hiding in the UI. The code technically works, but something about it is going to make the next change harder.

That can look mystical from the outside. It’s actually a process known as thin-slicing. Malcolm Gladwell popularized that term in Blink: the ability to make quick judgments from narrow slices of information. Good engineers do this in code reviews all the time. They see a small signal and recognize the shape of a future problem.

That ability is real. It is also dangerous when it becomes a verdict instead of a signal.

Taste Still Needs Evidence

I recently showed some team members how to use GitHub Copilot to work with databases. I asked it to inspect a database and identify the three largest views by SQL length. The largest view was over 1,900 lines.

My taste said that was suspect. Not wrong or automatically broken, but suspect.

That distinction matters. A 1,900-line SQL view is not proof of a problem, but it is absolutely a reason to look closer. So I asked Copilot to analyze the view for performance and general best practices. It came back with concrete findings, including more than 90 sub-selects and duplicate rows.

That is the right use of taste. The feeling pointed at the place worth investigating. The evidence came from analysis.

If I had stopped at “this looks bad,” I would have been arguing from taste. If I had ignored the signal because it was only a feeling, I would have missed a useful inspection point. The discipline is in the middle: notice the signal, then force it to produce evidence.

Taste can tell you where to look. It does not get to be the evidence.

Junior Taste Is Usually A Hypothesis

Junior developers should be encouraged to have reactions and ideas. They may even call those reactions instincts. They should also be taught that those “instincts” are hypotheses, not conclusions.

I saw a website delivered with monster methods in the controller and thousands of lines of JavaScript. AI prompts were hardcoded. Display logic was integrated with data processing. The boundaries between interface, behavior, data access, and AI interaction were smeared together.

When asked about the approach, the developer said it felt better because everything was integrated and there were not too many unnecessary layers. That sounds reasonable if you have not been burned by that shape before. Layers can become ceremony. Abstractions can become waste. Splitting code apart can absolutely be overdone.

But “integrated” was doing too much work in that explanation. What looked integrated was actually tangled. What looked simple was actually inseparable. What looked like avoiding unnecessary layers was really erasing boundaries the system needed in order to change safely.

The developer saw layers as overhead. A more experienced engineer sees good boundaries as preserved optionality.

The difference is experience. The senior has seen what happens later. The controller grows. The JavaScript becomes unreviewable. The hardcoded prompts become operational risk. Display changes threaten data logic. A small feature request turns into a scavenger hunt through unrelated concerns.

The junior’s taste was not malicious. It was not mature enough yet, and it needed examination.

Senior Taste Can Calcify

Experience does not make taste automatically reliable. Sometimes experience hardens into dogma.

I had a senior engineer who felt that anything that did not follow domain-driven design was wrong. Not “DDD is useful when domain complexity justifies the structure.” Not “bounded contexts would help clarify this area.” Not “this business concept deserves an explicit model.” Anything not DDD was wrong.

That is not taste. It is a frozen heuristic.

DDD can be useful. So can clean architecture, event sourcing, microservices, factories, orchestrators, rich domain models, anemic models, server-rendered UI, SPAs, and a dozen other tools engineers argue about as if the tool itself contains the answer.

The answer is always context.

A good heuristic says, “DDD helps when the domain is complex, the business language matters, and the team understands the boundaries.” A bad heuristic says, “Everything should be DDD.” Good heuristics reduce thinking. Bad heuristics replace thinking.

That is why senior taste needs examination too. A senior engineer may have earned fast orientation, but they still owe the team an explanation. Experience gives you the ability to notice quickly. It does not give you the right to stop reasoning.

Code Review Is Where Taste Becomes Teachable

This shows up constantly in code review.

A senior engineer reads a pull request and writes, “Can this be cleaner?” They may be right. They may be seeing a real code smell. The problem is that the comment does not teach anything yet.

Cleaner how?

Is the method doing too much? Is the class carrying more than one reason to change? Is the dependency direction wrong? Is the name hiding the business concept? Is the mapping happening in the controller? Is the test hard to write because the code has too many concrete dependencies? Is the condition duplicated in three places? Is the code mixing display logic with data processing?

The smell has to be named.

Taste becomes useful when the senior explains which heuristic fired and why it matters.

“Can this be cleaner?” becomes, “This controller is doing mapping, orchestration, validation, and persistence. Split the mapping out so the controller owns request flow instead of data transformation.”

“This feels risky” becomes, “This prompt is hardcoded inside the UI path. Put it behind a service boundary so prompt changes can be reviewed, tested, and versioned independently.”

“I do not like this abstraction” becomes, “This abstraction has only one implementation and hides the business rule. It adds indirection without reducing coupling.”

That is the move: do not ask people to trust your taste. Translate your taste into judgment they can use.

Decompile The Feeling

The work is to decompile taste.

That is what my ai_tools repo does. It takes the things I used to recognize quickly in code review and turns them into standards, patterns, scorecards, and AI instructions that human developers and AI agents can follow.

“Keep the architecture clean” becomes dependency rules: dependencies point inward, the domain layer has zero external dependencies, and infrastructure concerns are isolated behind abstractions and injected through DI.

“Do not let controllers become junk drawers” becomes controller standards: use request DTOs, return response DTOs, map exceptions to ProblemDetails, and keep EF Core types out of the application layer.

“Do not smear mapping logic everywhere” becomes DTO and mapping standards: never map in controllers, use mapper classes or cached repositories, and choose Mapperly for simple property mapping while using static mapper methods for custom logic.

“Do not guess” becomes a golden rule: verify, ask, and understand before modifying.

That is taste made portable. It does not remove engineering judgment. It preserves it in a form other people can use: a junior developer can learn from it, a senior developer can challenge it, a reviewer can enforce it, and an AI agent can load it into context before writing code.

This is why standards beat preference. Standards matter because they make judgment explicit.

The same thing is true of scorecards. I do not want code quality conversations trapped in “looks good to me” or “feels messy.” I want evidence. Architecture, coupling, complexity, testability, dependency direction, security, and maintainability all give us ways to inspect the thing our taste pointed toward.

Not everything important can be reduced to a number, but the conversation gets better when taste has to answer to evidence.

The Standard

Taste is allowed in software. Feel is allowed. What people call instinct is allowed. Hunches are allowed. Vibes are allowed. Ideas are allowed.

They just do not get to be the final answer. The junior developer’s reaction is a hypothesis to test, the senior engineer’s reaction is a signal to examine, the architect’s preferred pattern is a tool to justify, and the code-review smell is a heuristic to name.

That is deliberate engineering.

You observe the code. You orient through experience. You decide what risk might exist. Then you act by producing evidence, naming the heuristic, and teaching the standard.

Taste can tell you where to look. It does not get to be the evidence.

Receipts

• Thin-slicing: Malcolm Gladwell’s Blink describes thin-slicing as rapid judgment from a narrow slice of information. This essay uses that idea as a software analogy: senior engineers often recognize code smells quickly, but the signal still needs evidence before it becomes a conclusion.
• OODA and orientation: This essay extends The Loop Is the Easy Part, especially the argument that orientation is the part of the loop that determines whether speed produces judgment or fast nonsense.
• Standards as portable judgment: The examples in the final section come from the public ai_tools agentic coding standards, including architecture, controller, DTO mapping, and golden-rule modules.
• Related essays: This piece also connects to Disciplina: Standards Beat Preference, Good Code Isn’t Taste. It’s Measurable., and Results Are the Only Thing That Matters.