Taste Is a Technical System

Designers call taste intuition. Engineers call taste subjective. Both claims serve the same function: they make taste exempt from scrutiny. If taste is intuition, no one can question it. If taste is subjective, no one has to implement it. The designer gets authority without accountability. The engineer gets permission to ignore aesthetics. Everyone loses.

Taste is not intuition. Taste is pattern recognition applied to quality — the accumulated result of exposure, reflection, and refinement compressed into rapid judgment. A trained taster who recognizes a Burgundy’s regional character does not operate on mystical instinct. That taster has sampled thousands of wines, encoded structural relationships between terroir and flavor, and built an internal evaluation framework that produces fast, reliable assessments.¹ The speed of the judgment obscures the system behind it.

The system decomposes into four components. Constraints determine what you remove. Evaluation criteria determine what you measure. Pattern recognition determines what you notice. Coherence determines how parts relate to the whole. Four components, each encodable. Taste is four things working in concert.

Constraints: What You Remove

Dieter Rams spent four decades at Braun asking one question: what can I remove? The SK 4 radio-phonograph stripped away wood veneer cabinets, decorative fabric, and symmetrical-but-functionless knob placement. What remained was a white metal case with a transparent Perspex lid. The lid was not minimal. The lid was honest — Rams believed that if the mechanism is not shameful, hiding it is dishonest.²

Rams articulated ten principles. Principle ten — “Good design is as little design as possible” — functions as a scope constraint. Not an aesthetic preference. A scope constraint. It bounds the solution space by requiring that every element justify its presence. You remove any element that does not serve the user, regardless of how attractive it looks or how much effort produced it.

Constraints like Rams’ operate identically to engineering constraints. A memory budget constrains which data structures are viable. A latency target constrains which algorithms are acceptable. The mechanism is the same: reduce the solution space until only defensible options remain.

In my own infrastructure, constraints manifest as hooks. A hook that rejects passive voice in blog posts is a constraint on prose style. A hook that blocks TODO and FIXME in committed code is a constraint on deferred quality. A hook that enforces semantic HTML is a constraint on structural honesty. Each hook encodes a specific taste decision into a deterministic check. A human with context and judgment made the decision once. The enforcement runs forever, at machine speed, without drift.

Ninety-five hooks enforce 95 taste decisions. Each hook traces back to a moment where I noticed a failure pattern and decided the pattern was unacceptable. The hook is the scar. The judgment that produced the hook is the taste (from Claude Code Hooks).³

Evaluation Criteria: What You Measure

Kenya Hara draws a distinction between simplicity and emptiness. A Henckels knife is simple: the handle tells you where to grip, the blade angle tells you what to cut, every element reduces ambiguity. A yanagiba sushi knife is empty: the plain wooden handle does not instruct you where to hold it, and that absence of instruction is the entire point. “You can hold it in any way you wish,” Hara explains. “This simple and plain handle receives all the incredible technique of the Japanese sushi chef.”⁴

You measure simplicity by what you removed. You measure emptiness by what you made possible. Two different evaluation criteria producing two different kinds of reduction. Rams evaluates by asking “does every element serve a function?” Hara evaluates by asking “does the absence create space for the user?”

Evaluation criteria encode these questions into repeatable assessments. My evidence gate is a six-criteria evaluation framework. Every non-trivial change must produce evidence for all six criteria before I mark the work complete: follows codebase patterns, simplest working solution, edge cases handled, tests pass, no regressions, solves the actual problem. The gate does not ask “is the code good?” The gate asks six specific questions that, together, define what “good” means in my system.

The specificity is what makes taste transmissible. “Good code” is subjective. “Code that follows the exponential backoff pattern established in fetch_semantic_scholar() at line 241” is objective. The evidence gate translates aesthetic judgment into structural verification. “Does the code feel right?” becomes “does the code match the established pattern, handle the edge cases, and pass the tests?” Taste becomes measurable when the evaluation criteria are concrete enough to produce binary outcomes.

Hara’s evaluation maps to a negative-space criterion: not “what features does the product have?” but “what assumptions does the product impose?” An API with dozens of required parameters imposes dozens of assumptions about how the developer will use it. An API with a handful of required parameters and many optional ones imposes fewer assumptions and offers more possibilities. Assumption count is concrete, measurable, and encodes Hara’s philosophy of emptiness into interface design.

Pattern Recognition: What You Notice

Charles Eames did not design the molded plywood chair by selecting from existing options. Eames and Ray spent years experimenting with plywood molding techniques, failing repeatedly, discovering what the material would and would not permit.⁵ The final design emerged from accumulated knowledge about grain direction, adhesive behavior, compound curves, and stress distribution. The chair looks effortless. The effortlessness required thousands of hours of noticing.

Pattern recognition operates by exposure and attention. A typographer who has set thousands of pages notices kerning errors that a novice does not see. A structural engineer who has reviewed hundreds of bridge designs notices load distribution problems that a junior engineer misses. The noticing is not innate gift alone. The noticing is the residue of sustained, deliberate observation.⁶

In engineering infrastructure, pattern recognition maps to quality loops. My quality loop is a seven-step cycle: implement, review every line, run the evidence gate, apply the pride check, fix every issue, zoom out, repeat. The loop forces a second look at work that the first pass declared finished. Each pass surfaces patterns the previous pass missed: an inconsistent naming convention, an unhandled timeout, a test that verifies the happy path but ignores the error path. The infrastructure compensates for the experience gap by mandating the attention pattern that produces recognition.

Coherence: How Parts Relate to the Whole

Tadao Ando designs buildings where concrete walls, natural light, water, and empty space exist in deliberate relationship. The Church of the Light in Osaka uses a cruciform slit in the concrete wall to admit sunlight, creating a cross of light on the interior wall. Remove the slit, and the building is a concrete box. Remove the concrete, and the light has no surface to reveal itself against. Neither element works alone. The coherence between material and void produces the experience.⁷

Coherence is the highest-order component of taste because it requires understanding the whole, not just the parts. A hook can enforce a constraint on a single file. An evidence gate can evaluate a single change. A quality loop can surface patterns in a single module. Coherence requires evaluating how every part relates to every other part — and to the purpose of the system as a whole.

In software, architectural review serves the coherence function. A module that works correctly in isolation but violates the system’s dependency direction is incoherent. A feature that passes every test but contradicts the product’s design language is incoherent. Coherence defects are invisible to local evaluation. They only surface when someone zooms out.

My quality loop includes a “zoom out” step for exactly this reason. After the evidence gate passes and the pride check clears, the loop requires checking integration points, imports, and adjacent code for regressions. The Steve + Jiro doctrine I operate under makes this a dual standard: Jiro governs evidence, rigor, and craft (the local qualities); Steve governs worthiness, taste, and whole-widget integrity (the global qualities). If Jiro fails, stop. If Steve fails, rebuild. The dual standard ensures that local correctness never overrides global coherence.

The Map

Four components of taste. Four pieces of engineering infrastructure.

Rams becomes a hook. Hara becomes an evaluation criterion. Eames becomes a quality loop. Ando becomes an architectural review. The design philosophies I have profiled across 32 designers are not decoration for a portfolio site. Each profile is a case study in one or more of these four components, and each component maps to infrastructure I run in production.

Beauty and Brutalism documents the specific CSS decisions behind this site, each one a constraint. White typography on #000000. Opacity layers at 5%, 10%, 40%, 65%. No gradients, no illustrations, no decorative elements. Each decision is a Rams-style removal encoded into a stylesheet that every page inherits. The constraints are executable.

The Dark Factory Problem

Dan Shapiro’s dark factory model describes five levels of AI coding autonomy, from manual (Level 0) through fully autonomous (Level 5). At Level 5, code is generated by machines, verified by machines, and deployed without a human reading a single line.

Taste presents the dark factory with a problem that correctness does not. Correctness can be verified by tests. Performance can be verified by benchmarks. Security can be verified by static analysis. Taste cannot be verified by any existing automated system because the coherence component requires understanding the whole system, not just the diff.

At every level below 5, a human provides the coherence evaluation. Remove the human, and coherence evaluation must be encoded or it disappears. Constraints survive automation (hooks run without humans). Evaluation criteria survive (evidence gates run without humans). Pattern recognition partially survives (quality loops run, though a human wrote the pride check questions). Coherence does not survive unless someone encodes the architectural intent in a format that an evaluation agent can query. An autonomous system without taste constraints will optimize for passing tests — and as Justin McCarthy’s StrongDM team discovered, agents wrote return true to pass test suites while producing worthless code.⁸ The tests are green. The output has no craft, no consideration, no coherence.

The Thesis

Taste is infrastructure, and infrastructure is the last human advantage in a world where machines can write, design, and deploy at the speed of inference. But taste is only an advantage if you encode it. Unencoded taste is a bottleneck — a single person whose judgment every decision must pass through, who becomes the limiting factor on how fast the system can move. Encoded taste is a moat: constraints, evaluation criteria, pattern-recognition loops, and coherence checks that every output must satisfy, running at machine speed, improving with every failure that produces a new hook.

Every autonomous agent session that runs without taste constraints produces output that drifts toward the median. Every hook, every evidence gate criterion, every quality loop step, every architectural review encodes a specific judgment that resists the drift. Quality is the only variable. Taste is what defines what quality means.

Designers who gatekeep taste as intuition will find their intuition irrelevant when machines generate faster than any human can review. Engineers who dismiss taste as subjective will find their systems producing correct, performant, architecturally sound mediocrity. The path forward requires both: the designer’s accumulated judgment, decomposed into components, encoded into infrastructure, and enforced at the speed the machines demand.

Taste is not a feeling. Taste is a technical system. Build the system, or watch the taste disappear.

FAQ

Can taste really be reduced to four components?

The four components — constraints, evaluation criteria, pattern recognition, and coherence — are a decomposition, not a reduction. Taste in practice involves all four operating simultaneously, and the interaction between components produces emergent qualities that no single component captures. The decomposition is useful because each component maps to a specific type of engineering infrastructure, making the abstract concrete and the subjective implementable.

How do hooks differ from a design system?

A design system defines tokens, components, and usage guidelines. Hooks enforce behavioral constraints at the point of creation. A design system says “use 16px body text.” A hook blocks a commit that sets body text to 14px. The design system is reference material. The hook is a gate. Both are useful. The hook is what makes the design system’s decisions non-negotiable during autonomous generation.

Does encoding taste make it rigid?

Encoding taste makes the encoded judgments consistent, not frozen. My hook count has grown from zero to 95 over nine months because each failure pattern I noticed became a new constraint. Rigidity would mean refusing to add new hooks. Growth means every failure that offends your taste becomes infrastructure that prevents the next occurrence.

Sources