What AI Lacks: Why 'Taste' Matters in Software Architecture
AI can write code, but it can't make the judgment calls that distinguish good architecture from working code. Why experience-based 'taste' remains irreplaceable.
Jason Overmier
Innovative Prospects Team
George Hotz, 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:
// 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. We’ve been making these judgment calls for years, and we bring that experience to every project.
