Compound Engineering: The Definitive Guide

Punti chiave

1. Definizione canonica. il compound engineering è l'approccio in cui ogni unità di lavoro ingegneristico rende più facili, non più difficili, le unità successive. Inversione della traiettoria di complessità: le correzioni di bug eliminano intere categorie di bug futuri, i pattern diventano strumenti, il codebase diventa più facile nel tempo.
2. Loop principale in 7 fasi. Ideate → Brainstorm → Plan → Work → Review → Polish → Compound → (Repeat). Tre fasi: decisione umana (cosa costruire?), esecuzione dell'agente (pianificare/scrivere codice/testare/PR), giudizio umano (l'output è sufficiente? il sistema ha imparato?). 1. Ideate (/ce-ideate): ambiguità → opzioni di prodotto prioritizzate (punteggio confidenza/impatto/complessità). 2. Brainstorm (/ce-brainstorm): idea vaga → requisiti concreti, salvati in docs/brainstorms/. 3. Plan (/ce-plan): 3 agenti di ricerca paralleli (repo, framework-docs, best-practices) + spec-flow-analyzer → piano strutturato in docs/plans/. 4. Work (/ce-work): isolamento (git worktree), esecuzione passo dopo passo, validazioni, PR. 5. Review (/ce-code-review): revisori specializzati in parallelo, risultati prioritizzati P1/P2/P3. 6. Polish (/ce-polish-beta): navigare effettivamente l'app, ciò che "sembra sbagliato" (velocità, animazione, copy, stati vuoti). 7. Compound (/ce-compound): "la fase critica" — catturare la soluzione in docs/solutions/ con frontmatter YAML, aggiornare CLAUDE.md, creare agenti. "Il sistema lo rileverebbe automaticamente la prossima volta?"
3. Il plugin. (EveryInc/compound-engineering-plugin): oltre 40 agenti specializzati, oltre 30 slash command, oltre 35 skill. Review = ~23 revisori (always-on: correttezza, testing, manutenibilità, standard di progetto, agent-native, lezioni apprese; condizionali: sicurezza, performance, contratto API, migrazioni, affidabilità, adversarial; specifici per stack: Rails, Python, TypeScript, Swift/iOS, frontend-races). Installabile su Claude Code, Cursor, Codex (+ Copilot, Factory Droid, Gemini, ecc.).
4. Albero del progetto. CLAUDE.md/AGENTS.md (il file più importante, letto ad ogni sessione) + .compound-engineering/config.local.yaml + docs/brainstorms/, docs/plans/, docs/solutions/ (categorizzati: performance-issues, security-issues, architecture-patterns, conventions…).
5. /lfg. sviluppo autonomo dall'idea alla PR mergiata (Plan → Work → review+autofix → test browser → commit/push/PR).
6. Regola del 50/50 (revisione dell'80/20). 50% del tempo a costruire funzionalità, 50% a migliorare il sistema (agenti di revisione, documentazione dei pattern, generatori di test). ROI: 1 ora spesa a creare un agente di revisione ne fa risparmiare 10 nel corso dell'anno — i miglioramenti al sistema si accumulano, le funzionalità no.
7. 8 convinzioni da disimparare. il codice deve essere scritto a mano / ogni riga deve essere rivista manualmente / la soluzione viene dall'ingegnere / il codice è l'artefatto primario / le prime bozze devono essere buone ("i primi tentativi hanno un tasso di scarto del 95%") / il codice è espressione di sé ("il codice non è davvero tuo") / più si scrive più si impara ("la comprensione conta più della memoria muscolare") / il pensiero ingegneristico ≠ il pensiero di prodotto.
8. 8 convinzioni da adottare. estrarre il proprio gusto nel sistema; la regola del 50/50; fidarsi del processo + reti di sicurezza; l'ambiente agent-native ("se uno sviluppatore può vedere o fare qualcosa, dovrebbe poterlo fare anche l'agente"); la parallelizzazione (il nuovo collo di bottiglia è il calcolo, non l'attenzione umana); "i piani sono il nuovo codice"; "gli ingegneri ora sono persone di prodotto"; lasciare che gli agenti lavorino in propria assenza.
9. Scala di adozione a 5 livelli. 0 manuale → 1 assistenza chat → 2 agentico con revisione riga per riga (la maggior parte si ferma qui) → 3 plan-first, revisione a livello di PR (transizione chiave: il compound engineering inizia qui) → 4 idea→PR (1 macchina) → 5 esecuzione parallela nel cloud (multi-funzionalità, multi-dispositivo).
10. Agent-native — 4 livelli. (1) sviluppo di base (file, test, commit); (2) locale completo (browser, log, PR); (3) visibilità in produzione (log in sola lettura, error tracking); (4) integrazione completa (ticket, deployment) → sblocca lo stadio 5.
11. Skip permissions. alias cc='claude --dangerously-skip-permissions'; il nome è deliberatamente allarmante; reti di sicurezza = git reset, test, revisione delle PR, worktree. Guadagno di 5-10× nel flow. Mai in produzione o durante l'apprendimento.
12. 3 domande senza strumenti. "Qual è stata la decisione più difficile?" / "Quali alternative hai scartato e perché?" / "Di cosa sei meno sicuro?"
13. Best practice dettagliate. baby app usa e getta per iterare sul design; figma-design-sync + design-iterator; codificare il gusto di design/copy in skill; ricerca utente strutturata (personas, frontmatter) leggibile dall'IA; estrazione dei pattern d'uso (heavy/struggle/workaround/abandonment); copy = UX (codificare la voce); marketing di prodotto automatizzato (note di rilascio + screenshot Playwright dal piano).
14. Forte collegamento con la copertura precedente. testo di consolidamento della filosofia diffusa da [[shipper-klaassen-compound-engineering-every-agents-2025-12-11]], [[klaassen-stop-coding-start-planning-every-2025-11-06]], [[klaassen-teach-ai-think-senior-engineer-every-2025-11-07]]; pipeline di revisione v260 [[chow-compound-engineering-v260-review-pipeline-2026-03-31]]; livello 5 "Workflows / harness" da [[taylor-entis-every-eight-levels-ai-adoption-2026-06-02]].