Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Taste

Pattern

A reusable solution you can apply to your work.

“I can’t define it, but I know it when I see it.” — A common sentiment, originally from Justice Potter Stewart

Understand This First

  • Application – taste is always relative to context and purpose.

Context

This is a strategic pattern. Alongside judgment, the ability to choose well, there’s a companion capacity: the ability to recognize what is good. That’s taste.

In software, taste shows up everywhere. It’s the sense that a function is too long before any linter flags it. It’s the recognition that an API feels awkward even though it’s technically correct. The instinct that a user interface has too many options, or that a variable name is misleading, or that an architecture has an elegance that will make future changes easy.

Taste isn’t a luxury. In agentic coding workflows, where AI agents can produce large volumes of code quickly, taste becomes the primary quality filter. The agent generates; the human evaluates. Without taste, you can’t tell good output from plausible output.

Problem

AI agents can produce code that compiles, passes tests, and meets stated requirements, yet still feels wrong. It might be bloated, inconsistent, over-engineered, or subtly misaligned with the conventions of the codebase. Mechanical correctness is necessary but not sufficient.

How do you evaluate quality beyond what automated checks can measure?

Forces

  • Taste is subjective, which makes it hard to teach, discuss, or enforce.
  • But taste isn’t arbitrary. Experienced practitioners converge on similar assessments of quality, suggesting shared underlying principles.
  • You want consistency across a codebase, but taste varies between individuals.
  • AI agents have no taste of their own. They optimize for explicit criteria and statistical patterns in training data.
  • Over-relying on taste without articulating reasons can feel like gatekeeping.

Solution

Develop taste through exposure and reflection. Read good code. Read bad code. Notice what makes the difference. Over time, you build pattern recognition that operates faster than conscious analysis, but the underlying judgment can be articulated when needed.

Taste in software tends to cluster around a few recurring qualities:

Clarity. Good code communicates its intent. Names are accurate. Structure follows logic. A reader can understand what is happening and why.

Coherence. The parts of a system feel like they belong together. Naming conventions are consistent. Abstractions operate at the same level. There are no jarring shifts in style or approach.

Proportionality. The complexity of the solution matches the complexity of the problem. Simple problems have simple solutions. Taste recoils from over-engineering as much as from under-engineering.

Appropriateness. The solution fits its context: the team, the timeline, the user, the platform. A prototype has different taste standards than a production system.

When reviewing AI-generated code, apply taste as a filter. The agent may produce something that works but doesn’t feel right. Trust that feeling, then articulate what’s off. “This function does too many things.” “These names are generic.” “This abstraction doesn’t earn its complexity.” That articulation turns taste into actionable feedback you can give back to the agent.

Tip

When an AI agent produces code that feels off but you can’t immediately explain why, try describing the code to someone else (or to the agent itself). The act of explaining often surfaces the specific quality issue that your taste detected but your conscious mind hadn’t yet named.

How It Plays Out

An agent generates a utility module with fifteen helper functions. Each function works correctly. But a developer with taste notices that five of the functions are near-duplicates with slightly different signatures, three are never called, and the naming mixes camelCase with snake_case. The module is correct but incoherent. The developer asks the agent to consolidate the duplicates, remove dead code, and unify the naming. The result: seven clean, consistent functions.

Another developer asks an agent to design a configuration system. The agent produces an elaborate YAML-based config with inheritance, overrides, environment-specific profiles, and validation schemas. The developer recognizes that the project is a small CLI tool used by one person. The solution is technically impressive but disproportionate. Taste says: use a simple JSON file with sensible defaults.

Consequences

Taste produces software that isn’t just correct but good: coherent, maintainable, and pleasant to work with. Codebases shaped by taste accumulate less cruft and are easier to extend.

The cost is that taste takes time to develop and is hard to standardize. Two experienced developers may disagree on matters of taste, and both may be right within their respective contexts. Taste also creates tension in teams where some members have more refined sensibilities than others.

In agentic workflows, taste is the human’s irreplaceable contribution. AI agents will get better at generating correct code. They’ll get better at following conventions. But the ability to recognize what’s appropriate in a particular context — to sense that something should be simpler, or bolder, or more restrained — remains a human capacity. Cultivating it is one of the most valuable investments you can make.

  • Complements: Judgment — judgment chooses among options; taste recognizes quality.
  • Refines: Tradeoff — taste informs which tradeoffs produce clean results.
  • Enables: Acceptance Criteria — taste helps you decide which qualities are worth encoding as criteria.
  • Depends on: Application — taste is always relative to context and purpose.