← All Notes January 2, 2025

Human-AI Collaboration Methodology

Problem discovery meets solution architecture

This document captures a collaboration pattern that emerged from building Yggdrasil and the Bragi ecosystem. It describes how human structural intuition and AI pattern-matching can complement each other in solving complex problems.

This isn’t the only way to work with AI — it’s one workflow that has proven powerful for a particular kind of person: someone with deep domain intuition who knows their strengths and wants to AI to complement them.

The Core Insight

Problem-solving divides into two distinct activities:

Problem Discovery - Understanding the shape of the problem space itself
Solution Architecture - Finding solutions that fit that shape

These require different capabilities. Humans with strong structural intuition often excel at the first. AI systems with vast exposure to solution patterns often excel at the second. The interesting question is: how do you combine them?

One Collaboration Pattern

What follows is a pattern that works well when the human has strong domain intuition but may struggle to verbalize it, and the AI has broad pattern exposure but may miss subtle boundary conditions.

Human Role: Problem Discovery

The human brings:

Shape recognition - Identifying the geometric structure of problems
Invariant awareness - Holding fundamental constraints from math, physics, CS
Boundary sensing - Feeling when a solution doesn’t fit the problem shape
Wrong-shape rejection - Immediate recognition of structural defects

This often operates below the level of language. The human sees that something is wrong before being able to articulate why.

AI Role: Solution Architecture

The AI brings:

Pattern library - Exposure to vast numbers of solution instances
Articulation - Expressing what the human sees but struggles to verbalize
Search efficiency - Quickly traversing solution-space when given direction
Implementation knowledge - Knowing how solutions manifest in code

The Handoff

Human points direction
    → AI surfaces candidate solutions
        → Human validates fit (feels boundaries)
            → Iterate until snug fit

The human doesn’t need to know the solution. The AI doesn’t need to discover the problem. Each contributes their strength.

Note: This can also run in reverse. Some people use AI to help articulate the problem, and once they hear it clearly stated, they already know the solution. The key is understanding your own strengths and structuring the collaboration accordingly.

Two Principles

1. Solution Fitness

Solutions have boundaries. Problems have boundaries. The quality of a solution is determined by how well these boundaries align.

Fit	Description	Consequence
Snug	Solution boundary matches problem boundary	Elegant, scales fractally
Loose	Gaps and overlaps at boundaries	Works at some scales, breaks at others
Wrong	Fundamental shape mismatch	Complexity leaks everywhere

When you “zoom in” on an elegant solution, it remains fitted at every level of detail. Poorly-shaped solutions reveal gaps and overlaps as you examine them more closely.

2. Complexity Cannot Solve Complexity

Adding more code can only add more complexity. If you’re adding complexity to patch a “complexity leak,” you’re likely working with the wrong primitives.

The only way to reduce complexity is to find the right abstraction at the right layer. Then code disappears rather than accumulates.

Corollary: When you find yourself writing more code to manage the consequences of previous code, step back. The problem is in the primitives, not the implementation.

The Hard Requirement: Shared Primitives

This collaboration pattern only works when both parties share a primitive vocabulary.

Effective primitives:

Mathematical structures (orthogonality, invariants, transformations)
Physical constraints (conservation laws, entropy, causality)
Computer science fundamentals (state machines, graphs, recursion)

Why this matters: The human’s structural intuition is expressed in terms of these primitives. The AI can only pattern-match against solutions if it understands the constraints being described. Shared primitives are the common language.

What doesn’t work:

Domain jargon without grounding in fundamentals
Vague analogies that don’t map to precise structures
“Best practices” divorced from underlying constraints

Case Study: Two Approaches to Frontend State

Consider two different approaches to the same problem: managing state and rendering in a frontend framework.

Approach A: Surface-First

Great DX abstraction (JSX)
    → Need to know when things change
        → VDOM diffing as change detection
            → DOM and state become coupled
                → Side-effect management layer needed
                    → Complexity grows with application size

This path starts with an excellent developer experience choice (JSX), then works backward to the mechanics. Each subsequent decision is constrained by the previous one. The result can work well, but complexity tends to accumulate as applications grow.

Approach B: Invariant-First

Starting invariant: DOM and state must be orthogonal

DOM and state are orthogonal (invariant)
├── Want JSX-like DX → Template engine as pure function
├── Need state updates → Use browser primitives (events)
├── Need render timing → Game loop approach (dirty flag, requestAnimationFrame)
├── Need fine-grained updates → Cache keys to rendering engine
└── Result: Two orthogonal tracks that don't leak into each other

This path starts from a structural constraint and lets the solution emerge from it. The invariant constrains the solution space to only shapes that will actually fit the problem.

The Difference

Neither approach is “right” or “wrong” — they represent different trade-offs. The surface-first approach optimizes for immediate developer experience and ecosystem adoption. The invariant-first approach optimizes for long-term complexity management.

The interesting observation: when you start from invariants, the solution space is smaller but the solutions tend to be more robust. When you start from surface features, you have more flexibility but may need to manage emergent complexity later.

Recognizing Poor Fit

How do you know when something doesn’t fit?

It’s often a feeling first. Discomfort, resistance, a sense that “this will cause problems.” The articulation comes later.

Triggers:

Having to think about the abstraction every time you use it
Exceptions and edge cases multiplying
Workarounds that require understanding internals
The sensation that you’re “fighting” the tool

What the feeling means: The solution boundary doesn’t match the problem boundary. Somewhere there’s a gap (under-solving) or overlap (over-engineering). The complexity will leak.

The override: This intuition can be consciously suppressed when necessary (work requirements, learning exercises, time constraints). But suppressing it doesn’t make the structural defect go away — it just defers the consequences.

Implications for Human-AI Collaboration

This methodology suggests one model for productive collaboration:

Know your strengths - Are you better at sensing problems or generating solutions? Structure the collaboration to amplify what you’re already good at.
Build shared vocabulary - Ground discussions in math/physics/CS fundamentals, not framework-specific jargon. This gives the AI something precise to pattern-match against.
Iterate on fit, not features - The question isn’t “does this solution work?” but “does this solution’s shape match the problem’s shape?”
Trust the feeling, then articulate - When something feels wrong, it probably is. The AI can help articulate why.
Use the loop for learning - Each iteration doesn’t just refine the solution — it builds your intuition for the next problem.

Summary

Aspect	Human	AI
Strength	Problem shape recognition	Solution pattern matching
Operates via	Structural intuition	Vast exposure to instances
Contribution	Invariants, constraints, boundaries	Candidates, articulation, implementation
Limitation	May struggle to verbalize	May miss boundary mismatches

The collaboration works because:

Problems have objective shapes (not just opinions)
Solutions either fit those shapes or they don’t
Humans can sense fit; AI can search for candidates
Shared primitives enable communication

One methodology: Point direction → Surface candidates → Validate fit → Iterate

Your methodology might be different. The key is understanding your own strengths and building the collaboration around them.