🏗️ The problem it solves

In traditional engineering, every new feature injects complexity: after years, each feature becomes a negotiation with the old ones. Code gets harder to understand, modify and trust, and teams spend more time fighting their system than building on it.

🔄 The compound flip

In compound engineering, features don't add fragility: they teach the system new capabilities. Bug fixes eliminate entire categories of future bugs. Codified patterns become tools. Over time, the codebase gets easier to understand, modify and trust.

Compound returns

An hour spent creating a review agent saves ten hours of review over the year. System improvements make work progressively faster. Feature work alone doesn't.

Teaching > doing

Time spent giving agents context pays exponential dividends. Time spent typing code only solves the task in front of you.

Ship more, type less

Your output should be measured by the number of problems solved, not the number of keystrokes you logged.

skills in the full inventory

specialist review agents in parallel

officially supported tools

🛡️ Security

security-sentinel — scans the OWASP top 10, injection attacks, authentication flaws and authorization bypasses.

⚡ Performance

performance-oracle — detects N+1 queries, missing indexes, caching opportunities and algorithmic bottlenecks.

🏛️ Architecture

architecture-strategist evaluates design decisions, component boundaries and dependency directions. pattern-recognition-specialist identifies patterns, anti-patterns and code smells.

🗄️ Data

data-integrity-guardian validates migrations, transaction boundaries and referential integrity. data-migration-expert checks ID mappings, rollback safety and production validation.

✨ Quality

code-simplicity-reviewer (YAGNI, unnecessary complexity) + language reviewers: Rails (two schools: DHH and Kieran), Python (PEP 8, type hints) and TypeScript (type safety, clean architecture).

🚀 Deploy & Frontend

deployment-verification-agent generates pre/post-deploy checklists and rollback plans. julik-frontend-races-reviewer detects race conditions in JS/Stimulus. agent-native-reviewer ensures features are accessible to agents, not just humans.

Basic

File access, tests and git commits. The base that unlocks compound engineering.

Full local

Browser, local logs and PR creation. Enables stages 3-4 of the ladder.

Production visibility

Production logs (read-only), error tracking and dashboards. The agent debugs proactively.

Full integration

Ticket systems, deployment and external services. Enables stage 5 (parallel cloud execution).

✅ When to use

• You trust the process: you have a good plan and good review systems
• You're in a safe environment (sandbox, nothing affecting real users)
• You want velocity: permission requests break your flow

❌ When NOT to use

• You're learning: the prompts help you understand what's happening
• You're in production: never, because it touches real users
• You don't have good rollback: if you can't undo easily, keep the prompts

🔀 Git is the safety net

Everything the agent does is in git. git reset --hard HEAD~1 and you're back.

🧪 Tests catch mistakes

Before merging, run your tests. If the agent broke something, they catch it.

👀 Review before merge

Skip permissions skips implementation prompts, not the final PR review.

🌲 Worktrees isolate risk

Risky work happens in an isolated directory via git worktrees.

Perfect for

• Personal projects
• Prototypes and experiments
• "Can this even work?" investigations
• Internal tools
• UX exploration

Not great for

• Production systems with users
• Code others will maintain
• Security-sensitive apps
• Performance-critical systems

The workflow

1. Create a prototype repo: mkdir baby-myapp
2. Vibe-code the design without fear
3. Iterate until it feels right: "more spacing, toggle more prominent"
4. Capture the design system: colors, spacing, typography, patterns
5. Transfer to the main app using the prototype as reference

UX discovery loop

When you don't know what to build: ask for five different versions of a screen, click through each, share with users ("would this flow confuse you?"), collect feedback on functional prototypes (unlike a Figma mockup, they can actually click around) and then delete everything and start over with a proper plan. The prototype is for learning, not shipping.

Traditional flow

Person A writes code → Person B reviews → discussion in PR comments → merge after approval.

Compound flow

Person A creates the plan → AI implements → AI agents review → Person B reviews the AI review → merge after human approval.

✅ Plan approval

Reading a plan and agreeing with it is a decision. Silence is not approval — it's the absence of a decision. Require explicit sign-off before implementation: a comment, a commit tag or another marker.

👤 PR ownership

The person who initiated the work owns the PR, regardless of who (or what) wrote the code. You're responsible for plan quality, reviewing the work, fixing issues and the impact after merge.

🎯 Human review focus

When agents have already analyzed the PR, humans focus on intent, not implementation: does this match what we agreed? does the approach make sense? any business logic issues? Syntax errors, security and performance are already the agents' job.

📬 Async by default

Plans can be created, reviewed and approved without a meeting. Instead of "let's meet to discuss", try "I've created a plan — please comment by end of day". Explicit handoffs: status, what's done, what's left, context and how to continue.

🚩 Flags + small PRs

Everyone shipping faster = more merge conflicts. Ship small pieces, use feature flags, merge to main frequently and resolve conflicts immediately. And each major feature has one owner, who updates the team asynchronously.

The research ↔ development gap

Traditional: researcher interviews → writes report → report rots in Drive → dev builds without reading it → feature doesn't match user needs.

Compound: research generates structured insights → insights become planning context → AI references insights when planning → features are informed by research → usage data validates insights → insights compound.

Structured insight

# research/interviews/user-123.md
### Insight: ritual matinal de dashboard
Quote: "Primeira coisa de manhã, procuro bandeiras vermelhas."
Implicação: dashboard precisa surfacar problemas rápido.
Confiança: 4/5 participantes

🔥 Heavy usage

Features used way more than expected; users returning to the same page repeatedly. A signal that value (or dependency) lives there.

😤 Struggle

High dwell time on simple pages; repeated attempts at the same action; error → retry → error loops.

🛠️ Workaround

Users inventing solutions because the product doesn't do what they need: exporting from one place and importing elsewhere, copy-pasting between screens, multiple tabs open to compare.

🚪 Abandonment

Where users drop off in flows: features started but not completed.

📋 Copy in the plan

Include copy in your plans from the start: email subject, success message, error messages. When the AI implements, the copy is already there.

🗣️ Codify your voice

Create a skill defining principles ("talk like a human, not a robot"; "errors should help, not blame") and words to avoid ("invalid" → "didn't work"; "successfully" → just say what happened).

🔎 Review copy like code

Add a copy-reviewer agent to the process: clarity (can a non-technical user understand?), helpfulness, tone (does it match the voice guide?) and consistency with similar text.

Better manually

• Critical architectural decisions without defined criteria
• Small hotfixes you already fully understand
• Regulated code requiring clear human accountability
• Learning a fundamental for the first time

Perfect with AI

• Boilerplate, tests and migrations
• Exploring an unknown codebase
• Mechanical refactors covered by tests
• Drafts of PR descriptions and documentation