Compound Engineering: The Definitive Guide

Puntos clave

1. Definición canónica. la ingeniería compuesta es el enfoque en el que cada unidad de trabajo de ingeniería facilita las unidades posteriores, no las dificulta. Inversión de la trayectoria de complejidad: las correcciones de errores eliminan categorías enteras de errores futuros, los patrones se convierten en herramientas, la base de código se vuelve más fácil con el tiempo.
2. Bucle principal de 7 pasos. Ideate → Brainstorm → Plan → Work → Review → Polish → Compound → (Repeat). Tres fases: decisión humana (¿qué construir?), ejecución del agente (plan/código/pruebas/PR), juicio humano (¿es suficiente el resultado? ¿aprendió el sistema?). 1. Ideate (/ce-ideate): ambigüedad → opciones de producto priorizadas (puntuación de confianza/impacto/complejidad). 2. Brainstorm (/ce-brainstorm): idea vaga → requisitos concretos, guardados en docs/brainstorms/. 3. Plan (/ce-plan): 3 agentes de investigación paralelos (repo, framework-docs, best-practices) + spec-flow-analyzer → plan estructurado en docs/plans/. 4. Work (/ce-work): aislamiento (git worktree), ejecución paso a paso, validaciones, PR. 5. Review (/ce-code-review): revisores especializados en paralelo, hallazgos priorizados P1/P2/P3. 6. Polish (/ce-polish-beta): recorrer realmente la aplicación, lo que "se siente mal" (velocidad, animación, redacción, estados vacíos). 7. Compound (/ce-compound): "el paso crítico" — capturar la solución en docs/solutions/ con frontmatter YAML, actualizar CLAUDE.md, crear agentes. "¿Detectaría el sistema esto automáticamente la próxima vez?"
3. El plugin. (EveryInc/compound-engineering-plugin): 40+ agentes especializados, 30+ comandos de barra, 35+ skills. Review = ~23 revisores (siempre activos: correctness, testing, maintainability, project-standards, agent-native, learnings; condicionales: security, performance, API contract, migrations, reliability, adversarial; específicos de la pila: Rails, Python, TypeScript, Swift/iOS, frontend-races). Instalable en Claude Code, Cursor, Codex (+ Copilot, Factory Droid, Gemini, etc.).
4. Árbol del proyecto. CLAUDE.md/AGENTS.md (el archivo más importante, se lee en cada sesión) + .compound-engineering/config.local.yaml + docs/brainstorms/, docs/plans/, docs/solutions/ (categorizado: performance-issues, security-issues, architecture-patterns, conventions…).
5. /lfg. desarrollo autónomo desde la idea hasta el PR fusionado (Plan → Work → revisión+autofix → pruebas de navegador → commit/push/PR).
6. Regla 50/50 (revisión de la 80/20). 50% del tiempo construyendo funciones, 50% mejorando el sistema (agentes de revisión, documentación de patrones, generadores de pruebas). ROI: 1 hora dedicada a crear un agente de revisión ahorra 10 horas a lo largo del año — las mejoras del sistema se componen, las funciones no.
7. 8 creencias para desaprender. el código debe escribirse a mano / cada línea debe revisarse manualmente / la solución proviene del ingeniero / el código es el artefacto principal / los primeros borradores deben ser buenos ("los primeros intentos tienen una tasa de basura del 95%") / el código es expresión personal ("el código no es realmente tuyo") / cuanto más se escribe más se aprende ("la comprensión importa más que la memoria muscular") / el pensamiento de ingeniería ≠ el pensamiento de producto.
8. 8 creencias para adoptar. extraer el propio criterio hacia el sistema; la regla 50/50; confiar en el proceso + redes de seguridad; el entorno agent-native ("si un desarrollador puede ver o hacer algo, el agente también debería poder"); la paralelización (el nuevo cuello de botella es el cómputo, no la atención humana); "los planes son el nuevo código"; "los ingenieros ahora son gente de producto"; dejar que los agentes trabajen mientras uno está ausente.
9. Escala de adopción de 5 etapas. 0 manual → 1 asistencia por chat → 2 agéntico con revisión línea por línea (la mayoría se estanca aquí) → 3 plan-first, revisión a nivel de PR (transición clave: la ingeniería compuesta comienza aquí) → 4 idea→PR (1 máquina) → 5 ejecución paralela en la nube (multi-función, multi-dispositivo).
10. Agent-native — 4 niveles. (1) desarrollo básico (archivos, pruebas, commits); (2) local completo (navegador, logs, PR); (3) visibilidad de producción (logs de solo lectura, seguimiento de errores); (4) integración completa (tickets, despliegue) → desbloquea la etapa 5.
11. Skip permissions. alias cc='claude --dangerously-skip-permissions'; el nombre es deliberadamente alarmante; redes de seguridad = git reset, pruebas, revisión de PR, worktrees. Ganancia de 5-10× en el flujo. Nunca en producción ni mientras se aprende.
12. 3 preguntas sin herramientas. "¿Cuál fue la decisión más difícil?" / "¿Qué alternativas se rechazaron y por qué?" / "¿De qué se está menos seguro?"
13. Mejores prácticas detalladas. baby app desechable para iterar sobre el diseño; figma-design-sync + design-iterator; codificación del criterio de diseño/redacción en skills; investigación de usuarios estructurada (personas, frontmatter) legible por IA; extracción de patrones de uso (heavy/struggle/workaround/abandonment); la redacción = UX (codificación de la voz); marketing de producto automatizado (notas de versión + capturas de Playwright a partir del plan).
14. Fuerte vínculo con cobertura previa. texto de consolidación de la filosofía difundida por [[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 de revisión v260 [[chow-compound-engineering-v260-review-pipeline-2026-03-31]]; nivel 5 "Workflows / harness" de [[taylor-entis-every-eight-levels-ai-adoption-2026-06-02]].