Compound Engineering

Summary

Compound Engineering is a methodology where each unit of engineering work makes subsequent units easier, not harder. The main loop: Plan > Work > Review > Compound > Repeat. The fourth step — Compound — is what distinguishes this from conventional development: codify learnings into reusable systems (solutions docs, CLAUDE.md updates, specialized agents, skills). Time allocation: 80% planning and review, 20% execution and compounding. The framework ships as a plugin with 26 specialized agents, 23 workflow commands, and 13 skills. Key commands: /workflows:plan, /workflows:work, /workflows:review, /workflows:compound, and /lfg (idea to merge-ready PR).

Why This Was Bookmarked

“compound engineering. Something I think we are already doing, but good to document the source of the term.”

We are already doing this. Our vault compilation, skill creation, and CLAUDE.md refinement are all compound steps. This article gives us the vocabulary and a more systematic framework for what we’re doing intuitively.

Key Ideas

• Main loop: Plan > Work > Review > Compound > Repeat
• 80/20 split: 80% planning and review, 20% execution — thinking before and after coding
• The Compound step: capture solutions, add YAML frontmatter for searchability, update CLAUDE.md, create specialized agents, verify learnings are captured
• 14+ parallel review agents: security, performance, architecture, data, quality — each examining code simultaneously
• Five adoption stages: manual (0) > chat copy-paste (1) > agentic line-by-line review (2) > plan-first PR-only review (3) > idea-to-PR automation (4) > parallel cloud execution (5)
• Eight mindset shifts: code doesn’t need manual writing, solutions don’t need to originate from engineers, code isn’t the primary artifact, typing isn’t learning
• 50/50 rule: equal time on feature building and system improvement
• Plans as primary artifacts: planning documents as source of truth, not code

Connections

This is the term and framework for what we’re doing with 06-reference/concepts/compounding-knowledge. Our vault is the compound step — every document we add, every wikilink we create, every skill we build is compounding.

The Plan > Work > Review > Compound loop maps directly to our operating model in SOUL.md: skills (reusable building blocks created during compound steps), loops (recurring work cycles), dedicated instances (the review agents running in parallel).

The 14+ review agent pattern connects to 06-reference/2026-03-31-block-hierarchy-to-intelligence — parallel specialized agents at the same level, coordinated by an orchestrator.

The adoption stages framework (0-5) gives us a benchmark. We’re operating at stage 3-4: plan-first development with PR-only review, with some idea-to-PR automation. Stage 5 (parallel cloud execution) connects to the localhost article — we’d need cloud dev environments.

See also 06-reference/concepts/skills-as-building-blocks — the plugin’s 26 agents + 23 commands + 13 skills is a mature example of the skill-based architecture.

Open Questions

• Should we adopt the /workflows: command structure for our own development loop?
• Can we formalize our compound step — currently ad hoc vault updates — into a consistent post-work ritual?
• What would our equivalent of the 14+ parallel review agents look like?
• Where are we on the 0-5 adoption scale, and what’s blocking the next level?