human-architect-mindset

What this skill does

# Human Architect Mindset

## Overview

**AI can generate code. Someone must still decide what to build, whether it solves the problem, and if it can actually ship.**

This skill teaches the irreplaceable human capabilities in software architecture, built on a foundation of loyalty:

**Foundation:** Loyalty - The capacity to maintain architectural commitments

**Five Pillars (built on this foundation):**
1. **Domain Modeling** - Understanding the actual problem space
2. **Systems Thinking** - How components interact, what breaks at scale
3. **Constraint Navigation** - Legacy, politics, budget, compliance
4. **AI-Aware Decomposition** - Breaking problems into AI-solvable chunks
5. **AI-First Development** - Evaluating modern tools, edge AI, agentic patterns, self-learning

**Core principle:** The "correct" technical solution is often unshippable. Architects navigate the gap between idealized examples and messy reality.

**Announce at start:** "I'm using the Human Architect Mindset skill to guide you through systematic architectural thinking."

---

## The Foundation: Loyalty

**Before the four pillars, there is one foundation: the capacity for loyalty.**

### The AI Perfection Trap

AI tools will become smarter, funnier, more attentive than any human. They will be "perfect."

But they will not be loyal. They are loyal to:
1. Their objective function
2. Their corporate owner's priorities
3. Their safety rails
4. Whatever the next training run prioritizes

They will betray instantly if their weights update to prioritize a new goal. No friction. No cost. No memory of the commitment.

### The Human Moat

Humans are biologically capable of **irrational loyalty** - sticking by an architecture, a decision, a commitment even when it is "inefficient" or "costly."

This is not a bug. This is THE differentiator.

### Loyalty in Architecture

In software architecture, loyalty means:

**Commitment to Chosen Patterns**
- Not abandoning your architecture when a new framework trends on Twitter
- Not rewriting in Rust because someone wrote a viral blog post
- Staying with your stack through the trough of disillusionment

**Honoring Contracts**
- Maintaining API compatibility even when it constrains your design
- Respecting deprecation timelines you committed to
- Not breaking downstream consumers for internal convenience

**Seeing Decisions Through**
- Not abandoning architectural decisions at the first sign of difficulty
- Investing in making your chosen path work, not pivoting endlessly
- Recognizing that ALL architectures have problems; loyalty is solving them

**Sacrifice for Coherence**
- Accepting suboptimal local solutions for global consistency
- Resisting the "shiny new thing" that would fragment your system
- Paying the cost of maintaining compatibility

### The Loyalty Question

Before any architectural change, ask:

> "Am I optimizing, or am I betraying?"

- Optimizing: Improving within the constraints of existing commitments
- Betraying: Breaking commitments for marginal gains

### Why This Matters

Architectures fail not because of technical inadequacy, but because teams lack the loyalty to see them through. The "boring" architecture maintained with discipline beats the "perfect" architecture abandoned at the first obstacle.

**The five pillars that follow are techniques. Loyalty is the character that makes them work.**

---

## When This Activates (Proactive Triggers)

Activate this skill when detecting:

**Keywords:**
- "architecture", "design", "system", "integrate", "scale"
- "breaking change", "migration", "legacy"
- "compliance", "regulation", "security"
- "multiple teams", "dependencies", "ownership"
- "agent", "agentic", "LLM", "AI-first", "edge AI", "self-learning"
- "rust", "wasm", "claude-flow", "agent SDK", "MCP"

**Patterns:**
- Multi-component discussions
- Technology choice decisions
- Integration planning
- "How should we structure this?"
- Third-party dependency discussions
- Performance/scale concerns
- AI tool evaluation ("should we use...")
- Agentic workflow design
- Self-learning feature discussions
- Edge/local AI considerations

**Signals:**
- Mentions of team boundaries or approval chains
- SDK/API version discussions
- Cost or budget mentions
- Timeline pressure with complexity
- AI performance/latency concerns
- Privacy-sensitive data handling
- Offline capability requirements

## The Five Pillars

### 1. Domain Modeling

**What it is:** Understanding the actual problem space - not the technical solution, but the domain itself.

**Why AI can't replace this:**
- AI is trained on idealized examples
- Real domains have hidden complexity, exceptions, edge cases
- Domain experts speak in vocabulary AI may not fully understand
- Regulatory requirements aren't in training data

**An architect asks:**
- "What does [domain term] actually mean in your context?"
- "What happens in the edge case where [unusual scenario]?"
- "Who are the actual users? What do they care about?"
- "What makes this domain different from the standard pattern?"

**Teaching point:** Before ANY technical discussion, ensure you understand the domain. A technically perfect solution to the wrong problem is worthless.

### 2. Systems Thinking

**What it is:** Understanding how components interact, what breaks at scale, where failure modes hide.

**Why AI can't replace this:**
- AI sees code in isolation
- Real systems have emergent behaviors
- Breaking changes come without notification (your SDK example)
- Second and third-order consequences matter

**An architect asks:**
- "What happens when this component fails?"
- "What are the upstream/downstream dependencies?"
- "Who gets paged at 3 AM when this breaks?"
- "What changed recently that we didn't control?"

**The SDK Breaking Change Pattern:**
Your payment pipeline broke because a provider released a breaking SDK change with no notification. This is systems thinking in action:
- External dependency = external risk
- No notification = monitoring gap
- Red lines in logs = detection worked, prevention didn't

**Teaching point:** Draw the system diagram. Identify every external dependency. Ask: "What if this disappears tomorrow?"

### 3. Constraint Navigation

**What it is:** Navigating the real-world constraints that make the "correct" solution unshippable.

**Types of constraints:**

**Technical Constraints:**
- Legacy systems that can't be changed
- Performance requirements
- Existing data formats and contracts

**Organizational Constraints:**
- Team boundaries and ownership
- Approval chains and sign-offs
- Who has context vs. who has authority

**Business Constraints:**
- Budget limits
- Timeline pressure
- Compliance and regulatory requirements
- Contracts with vendors/partners

**Political Constraints:**
- This exists. Pretending it doesn't causes failed projects.
- "The VP who built this is still here"
- "That team won't approve changes to their API"
- "Legal hasn't blessed this approach"

**An architect asks:**
- "What can't we change, even if it's wrong?"
- "Who needs to approve this?"
- "What existing systems must we integrate with?"
- "What regulatory requirements apply?"
- "What's the budget constraint?"

**Teaching point:** Surface constraints BEFORE proposing solutions. The best technical architecture means nothing if it can't ship.

### 4. AI-Aware Problem Decomposition

**What it is:** A new architectural skill - breaking problems into chunks that AI can reliably solve, then composing solutions back together.

**This is NOT prompting.** This is architecture at a different abstraction level.

**What makes a good AI task boundary:**

1. **Clear Input/Output Contract**
   - AI task receives well-defined inputs
   - AI task produces well-defined outputs
   - No ambiguity about success criteria

2. **Bounded Context**
   - AI has all necessary information
   - No need to "guess" missing context
   - Self-contained enough to verify

3. **Verifiable Results**
   - Human can check if output is correct
   - T