[George Hotz](https://geohot.github.io), legendary hacker and founder of comma.ai, has made an observation worth repeating: AI has no taste. It can generate code that works, but it can't make the judgment calls that distinguish elegant architecture from functional spaghetti.

This isn't a temporary limitation that more training data will solve. It's a fundamental gap between what AI does (pattern matching) and what architectural taste requires (judgment in novel situations).

Understanding this gap explains why senior architects remain valuable in an AI-accelerated world.

## What Is 'Taste' in Software?

Taste in software isn't about aesthetics. It's about judgment that produces better outcomes over time.

### Components of Taste

| Component | What It Means | Example |
|-----------|---------------|---------|
| **Appropriate abstraction** | Knowing when to abstract and when to keep simple | Not building a framework for one feature |
| **YAGNI judgment** | Balancing preparation vs. over-engineering | Adding flexibility only where uncertainty is real |
| **Trade-off navigation** | Choosing between imperfect options | Consistency vs. availability in distributed systems |
| **Context sensitivity** | Adapting decisions to specific situation | What works for startup vs. enterprise |
| **Long-term thinking** | Optimizing for lifecycle, not just now | Choosing boring technology over exciting |

### What Taste Looks Like

| Decision | AI Might Suggest | Taste Suggests |
|----------|------------------|----------------|
| **State management** | Complex library that handles everything | Simple solution that handles current needs |
| **API design** | REST, GraphQL, and gRPC for different clients | One approach, consistent experience |
| **Testing strategy** | 100% coverage | Strategic coverage of critical paths |
| **Service boundaries** | Microservices for "scalability" | Monolith until boundaries are clear |
| **Build vs buy** | Implement for control | Integrate when undifferentiated |

The AI suggestion isn't wrong. It just lacks context and judgment.

## Why AI Lacks Taste

### Pattern Matching vs. Judgment

AI generates code by predicting what comes next based on patterns in training data. This produces:

| AI Strength | AI Limitation |
|-------------|---------------|
| **Reproduces known patterns** | Can't judge if pattern fits *your* situation |
| **Suggests common solutions** | Can't deviate from training distribution |
| **Considers immediate context** | Misses broader system implications |
| **Optimizes for correctness** | Doesn't optimize for maintainability |

### The Training Data Problem

AI is trained on open-source code. This creates systematic biases:

| Training Bias | Effect on Suggestions |
|---------------|----------------------|
| **Trend-chasing code** | Suggests new frameworks over proven ones |
| **Over-engineered samples** | Suggests complex solutions to simple problems |
| **Inconsistent patterns** | Different suggestions for similar problems |
| **Missing context** | Doesn't know why decisions were made |

A senior architect's "taste" comes from seeing the consequences of decisions over years. AI sees code, not consequences.

### The Novelty Problem

Taste matters most in novel situations where patterns don't apply:

| Situation | Pattern-Based Approach | Taste-Based Approach |
|-----------|------------------------|----------------------|
| **New domain** | Apply similar domain patterns | Understand domain, adapt approach |
| **Legacy integration** | Rewrite in modern stack | Incremental migration, preserve value |
| **Scale jump** | Architect for expected scale | Design for current scale, plan evolution |
| **Team constraints** | Ideal architecture | Pragmatic architecture team can execute |

When there's no training data pattern for your situation, AI has no basis for judgment.

## Where Taste Matters Most

### 1. System Boundaries

Deciding where to draw lines between components requires taste:

| Question | AI Answer | Taste Answer |
|----------|-----------|--------------|
| "Should this be a service?" | "Services are scalable" | "Only if the boundary is stable" |
| "Should we use a message queue?" | "Queues enable async" | "Only if we need async semantics" |
| "Should we cache this?" | "Caching improves performance" | "Only if stale data is acceptable" |

### 2. Technology Selection

AI can list options. Taste picks the right one:

| Factor | AI Consideration | Taste Consideration |
|--------|------------------|---------------------|
| **Team expertise** | Technology popularity | What team can maintain |
| **Hiring market** | Common technologies | Available talent pool |
| **Longevity** | Current trends | Technology lifecycle stage |
| **Risk** | Known vulnerabilities | Operational complexity |

### 3. Technical Debt Management

AI doesn't understand the concept of debt:

| Decision | AI View | Taste View |
|----------|---------|------------|
| **Quick fix vs refactor** | Implement requested fix | Consider if fix creates future cost |
| **Feature deadline pressure** | Ship fastest solution | Balance speed with debt incurred |
| **Legacy system handling** | Suggest rewrite | Incremental modernization |

### 4. Team Dynamics

Architecture affects teams. AI doesn't consider people:

| Factor | AI Ignores | Taste Considers |
|--------|------------|-----------------|
| **Cognitive load** | N/A | How much can team understand? |
| **Onboarding** | N/A | How quickly can new devs contribute? |
| **Bus factor** | N/A | Is knowledge distributed? |
| **Morale** | N/A | Is architecture frustrating the team? |

## Examples of Taste in Action

### Example 1: The Caching Decision

**Request:** "Add caching to improve performance"

**AI approach:**
```typescript
// Add Redis cache for all database queries
const cachedResult = await cache.get(key);
if (cachedResult) return cachedResult;
const result = await db.query(...);
await cache.set(key, result, TTL);
return result;
```

**Taste approach:**
- Which queries are actually slow?
- Is stale data acceptable for this use case?
- What's the cache invalidation strategy?
- Are we adding operational complexity for minimal gain?
- Should we fix the query instead of caching?

The taste approach might conclude: "The query is slow because of missing index. Add index, skip cache."

### Example 2: The Microservices Question

**Request:** "Should we use microservices?"

**AI answer:** "Microservices enable independent deployment, scaling, and team autonomy. Consider using Kubernetes for orchestration..."

**Taste answer:**
- What's our team size? (5 engineers)
- How often do we need independent deployment? (Weekly at most)
- Do we have DevOps capacity? (No dedicated DevOps)
- Are boundaries clear? (Still evolving)

"Microservices would add operational overhead we can't support. Stay with monolith, organize by modules."

### Example 3: The Abstraction Level

**Request:** "Build a notification system"

**AI approach:** Generic notification abstraction with providers, templates, queues, preferences, scheduling...

**Taste approach:**
- What notifications do we actually need today? (3 types)
- What's likely to change? (More notification types)
- What's unlikely to change? (Email as primary channel)

Build for today with clear extension points. Don't over-abstract.

## Developing Taste

Taste isn't innate. It develops through:

| Experience Type | What It Teaches |
|-----------------|-----------------|
| **Lived with past decisions** | Consequences of architectural choices |
| **Seen many codebases** | Patterns that work, patterns that fail |
| **Made mistakes** | What seemed right but wasn't |
| **Seen scale changes** | What breaks, what doesn't |
| **Team variability** | What's maintainable by others |

### Accelerating Taste Development

| Practice | How It Helps |
|----------|--------------|
| **Post-mortems** | Learn from failures systematically |
| **Architecture reviews** | See others' decisions and reasoning |
| **Codebase diversity** | Read code outside your domain |
| **Long-term ownership** | Live with your decisions for years |
| **Mentorship** | Learn from those with more experience |

## The AI + Taste Combination

The winning combination isn't AI vs. taste. It's AI plus taste:

| Phase | AI Role | Taste Role |
|-------|---------|------------|
| **Problem understanding** | Summarize patterns | Frame the actual problem |
| **Solution generation** | Propose options | Evaluate which fits |
| **Implementation** | Generate code | Guide direction, verify |
| **Review** | Find surface issues | Judge architectural fit |
| **Evolution** | Suggest refactorings | Decide what to change |

AI accelerates implementation. Taste ensures it's the right implementation.

## Common Mistakes

| Mistake | Why It Hurts |
|---------|--------------|
| **Accepting AI architecture suggestions** | AI optimizes for patterns, not your context |
| **Replacing senior judgment with AI** | Loses the taste that prevents problems |
| **Over-engineering with AI tools** | AI makes complex solutions easy to generate |
| **Not reviewing AI architecture** | AI suggestions look plausible but may be wrong |
| **Undervaluing experience** | Taste comes from time, not tools |

---

AI can generate code, but it can't replace the judgment that distinguishes good architecture from working code. If you're looking for a development partner who brings both AI acceleration and architectural taste, [book a consultation](https://innovativeprospects.com/contact). We've been making these judgment calls for years, and we bring that experience to every project.