Compounding Teams

Groups of engineers leveraging AI agents to create self-improving development systems that generate exponentially increasing productivity through recursive tool-building

Key insight: Small teams of 2-3 engineers producing output of 10-15+ traditional engineers through recursive tool-building and knowledge accumulation.

Originator: Sam Schillace (“I Have Seen the Compounding Teams”)

Fundamental Principle

Compounding teams operate on the principle that “the best tool for building a tool is a tool”—creating a recursive self-improving system where:

AI Agent → Builds Tool → Uses Tool to Build Better Tool → Builds Better Tools  
                              ↑___________________________|  

Each iteration compounds: tools become more capable, agents become more powerful, system accelerates.

Core Architecture

Compounding teams don’t use AI models directly—they build frameworks around models:

The Framework Layer

Contains:

• Callback hooks – Control AI decision points
• Tool calling – Define available actions
• Flow control – Orchestrate workflows
• Plumbing – Like Claude Code or Codex infrastructure

Purpose: Proactive system that runs independently, not reactive tool for direct use

The Infrastructure Layer

Built on low-level programmer tools (and increasingly adopted for all knowledge work):

• Filesystem access – Read/write/organize files
• Git version control – Track changes, commit history
• Markdown – Structured documentation
• Kubernetes – Infrastructure orchestration
• XML/JSON – Data structures

Why these tools: Models are already highly successful with them, so they’re natural interfaces for AI-driven action

The Recursive Tool-Building Mindset

How It Works

Compounding teams operate by instructing the AI system:

“You’ll need a tool for that—go ahead and build and use it.”

Cycle:

1. Team identifies capability gap
2. Instructs AI to build a tool for it
3. AI builds, tests, and commits tool to git
4. Tool becomes permanent infrastructure
5. Future iterations build on this tool
6. Each new tool creates new capabilities

Example: Build Tool Meta-Level

Need: Better code organization  
  ↓  
Build: Code organization tool  
  ↓  
Use: Organize existing codebase  
  ↓  
Discover: Need for refactoring patterns  
  ↓  
Build: Pattern detection tool  
  ↓  
Use: Automatically refactor  
  ↓  
Discover: Need for performance analysis  
  ↓  
Build: Performance tool  
  ↓  
... exponential capability expansion  

Result: System keeps building more powerful tools, becoming progressively more capable

Observable Characteristics

Teams operating at compounding level exhibit distinct patterns:

1. Overwhelming Idea Abundance

Bottleneck shifts from execution to human attention

Traditional team: "How do we implement this?"  
Compounding team: "Which 5 of our 50 ideas do we implement?"  

• 5-10 parallel processes simultaneously
• More ideas than humans can review
• Execution capacity exceeds planning capacity

2. Extreme API Spend

• Hundreds to thousands of dollars per day
• Continuous model usage at scale
• Token spend as efficiency metric (like Software Factory)
• Agents run constantly improving systems

3. Minimal Human Code Interaction

• Some shipping products without human code review in months
• Team members treat code review as “counterproductive”
• One team reportedly calls code review “a firing offense because it means you’re in the way of the tool”
• Focus shifts to orchestration, not implementation

4. Small, Specialized Teams

• 2-3 engineers designing at high level
• Well-defined but isolated functionality
• Specialization amplifies agent capability
• More effective than larger mixed teams

Example: Two engineers producing output of fifteen through orchestration, not traditional teamwork

5. Modular Boundaries

• Can’t mix traditional hand-coding with agent approach in single repo
• Clean separation between human-coded and agent-coded components
• Different workflows incompatible

Context Refinement: The Operational Game

The operational game compounding teams play is called “context refinement” or context engineering”.

How It Works

Engineers structure and refine the AI system’s context:

• Metadata – Structured information about system
• Instructions – Clear operational guidelines
• Knowledge – Encoded lessons and patterns
• Constraints – Boundaries and requirements

The Process

Define clear context  
    ↓  
Agent operates within context  
    ↓  
Outcomes improve based on context quality  
    ↓  
Refine context based on learnings  
    ↓  
Agent operates more effectively  
    ↓  
Compounding improvement  

Outcome

As context improves, systems become progressively more effective:

• Initial shots at objectives have low success rate
• With refined context, success rate climbs
• Non-experts can enter projects at higher capability levels
• Persisted context becomes increasingly valuable competitive advantage

Quality Assurance & Constraints

Despite extraordinary autonomy, compounding systems maintain rigorous controls:

Hard Constraints

• Code must execute – No theoretical code, only working implementations
• Tests must pass – Acceptance tests are constant and meaningful
• Problems must decompose – Break into solvable pieces before execution

Soft Expectations

• Not fully trusting models (yet)
• Humans still make final decisions
• Quality thresholds maintained
• Safety first, speed second

Note: These constraints expected to relax as models improve and strategies evolve

Beyond Code: Knowledge Work Universalization

Sam Schillace suggests this pattern applies to all knowledge work:

Already Being Applied To

• Research – Creating multiple artifact types
• Product planning – Connecting user feedback into proactive systems
• Marketing – AI-generated campaigns and content
• Bug fixing – Automated issue analysis and fixes

Core Principles Transfer

• Autonomous problem decomposition
• Tool-building
• Recursive improvement
• Knowledge accumulation

The compounding teams methodology isn’t just for software—it’s a universal approach to knowledge work acceleration.

Organizational Challenges

Primary Challenge: Coordination

Compounding systems work best with deep specialization and isolation, but create coordination challenges:

The Problem:

• Different teams have different mental models
• Conflicting workflows create friction
• Integration points become bottlenecks
• Coordination overhead negates benefits

Why it matters:

• Small, focused teams outperform large heterogeneous groups
• Deep specialization incompatible with generalist coordination
• Different tools, languages, frameworks conflict

Future Solution

Sam Schillace suggests multiple competing model providers reviewing each other’s work:

• Provider A builds features
• Provider B audits for quality
• Provider C checks for security
• Multiple perspectives catch errors individual systems miss
• Competitive improvement drives quality

Comparison: Individual vs Compounding Performance

Traditional Engineer

Year 1: Productive, learning curve  
Year 2-3: Productive, good knowledge  
Year 4+: Productive but hitting limits  
Ceiling: Individual capability limit  

Compounding Team Member

Week 1: Building initial knowledge base  
Week 2-3: Tools start accumulating  
Week 4-8: Knowledge compounds, velocity visible  
Month 3+: Exponential acceleration  
Ceiling: Keeps rising (no limit observed)  

The difference isn’t the person—it’s the system compounding around them.

Metrics for Compounding Teams

Velocity Metrics

• Features per week (should accelerate)
• Time to feature (should decrease exponentially)
• Team size relative to output (should diverge)

Quality Metrics

• Bugs per feature (should decrease)
• Code review time (should approach zero)
• Testing coverage (should increase)
• User satisfaction (should improve)

Knowledge Metrics

• Tools created (should grow)
• Reuse rate (should increase)
• Time for new person to contribute (should decrease)
• Knowledge base value (should accelerate)

System Health

• Model API efficiency (tokens per unit of work)
• Tool execution success rate
• Architectural coherence
• Technical debt trend

Economic Implications

Staffing

• 2-3 people do work of 10-15
• Dramatic reduction in headcount
• Higher per-person compensation justified
• Quality improves while cost decreases

Time to Market

• Features ship 5-10x faster
• Competitive advantage through speed
• Can iterate based on user feedback rapidly
• Market responsiveness unprecedented

Scaling

• Same team ships 2x output next quarter
• 4x output by end of year
• Compound effect accelerates growth
• Organizational scaling challenges emerge

Challenges & Limitations

1. Onboarding New Team Members

• System is highly tuned to current team
• Context loss when people leave
• New people don’t understand accumulated knowledge
• Takes time to rebuild relationships with AI system

2. Maintaining Code Quality

• How to ensure AI-generated code doesn’t decay
• Testing burden increases with automation
• Need mechanisms to catch AI errors
• Risk of technical debt accumulation

3. Managing Tool Proliferation

• Too many tools becomes hard to manage
• Tool interactions can conflict
• Deprecating old tools difficult
• Maintenance burden grows

4. Dependency on AI Models

• Entirely dependent on model quality
• Model changes break workflows
• Can’t switch providers easily
• Vendor lock-in risk

Future Evolution

Near Term (2026-2027)

• More teams adopting compounding methodology
• Tools become more specialized
• Context management becomes discipline
• Multiple provider systems emerge

Medium Term (2027-2029)

• Autonomous tool-building (agents create tools without instruction)
• Self-healing systems (proactively fix issues)
• Cross-team knowledge sharing (standards emerge)
• Industry adoption accelerates

Long Term (2029+)

• Systems improve faster than they grow in complexity
• “Software” becomes ambient intelligence
• Knowledge becomes strategic moat
• Traditional hiring models become obsolete

Getting Started: Building a Compounding Team

Phase 1: Foundation (Month 1)

1. Adopt planning-first mindset
2. Choose one focused area (not entire codebase)
3. Set up Claude Code or equivalent
4. Create knowledge base structure (git repo)

Phase 2: Initial Compounding (Months 2-3)

1. Build first features with agent
2. Document every lesson
3. Create reusable tools
4. Measure velocity improvements

Phase 3: Expansion (Months 4+)

1. Scale to second team member
2. Specialize responsibilities
3. Build more sophisticated tools
4. Grow toward 2-3 person optimal size

Key Resources

People & Voices

• Sam Schillace – Originator of concept
• Every – Practitioners with public results
• Cursor – Primary tool platform
• Claude Code – Orchestration engine

Reading

• Sam Schillace: “I Have Seen the Compounding Teams”
• Dan Shapiro: “Five Levels from Spicy Autocomplete to the Software Factory”
• Luke PM: “The Software Factory”

Related Concepts

• Compound Engineering – The methodology
• Software Factory – Related but enterprise-focused
• Agentic Development – Core mechanisms
• Context Graphs – Knowledge persistence
• Sam Schillace – The thinker behind the concept

References

• Sam Schillace: “I Have Seen the Compounding Teams” (Sunday Letters from Sam)
• Every company’s compound engineering practices
• Claude Code and Cursor implementations
• Multiple emerging compounding teams (not all public)