Compound Engineering: The Definitive Guide

Puntos clave

1. Definición canónica. compound engineering es el enfoque en el que cada unidad de trabajo de ingeniería facilita las unidades siguientes, en lugar de dificultarlas. Invierte la trayectoria de la 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 por agentes (planificar/codificar/probar/PR), juicio humano (¿el resultado es suficiente? ¿el sistema aprendió?). 1. Ideate (/ce-ideate): ambigüedad → opciones de producto priorizadas (puntuación de confianza/impacto/complejidad). 2. Brainstorm (/ce-brainstorm): idea difusa → requisitos concretos, guardados en docs/brainstorms/. 3. Plan (/ce-plan): 3 agentes de investigación en paralelo (repo, framework-docs, mejores prácticas) + 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): navegar realmente la aplicación, lo que "se siente mal" (velocidad, animación, textos, 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. "¿El sistema detectaría esto automáticamente la próxima vez?"
3. El plugin. (EveryInc/compound-engineering-plugin): más de 40 agentes especializados, más de 30 comandos slash, más de 35 skills. Review = ~23 revisores (siempre activos: corrección, testing, mantenibilidad, estándares de proyecto, agent-native, aprendizajes; condicionales: seguridad, rendimiento, contrato de API, migraciones, fiabilidad, adversarial; específicos de stack: 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, leído en cada sesión) + .compound-engineering/config.local.yaml + docs/brainstorms/, docs/plans/, docs/solutions/ (categorizados: performance-issues, security-issues, architecture-patterns, conventions…).
5. /lfg. desarrollo autónomo desde la idea hasta el PR fusionado (Plan → Work → revisión + autocorrección → pruebas de navegador → commit/push/PR).
6. Regla 50/50 (revisión de la 80/20). 50% del tiempo construyendo funcionalidades, 50% mejorando el sistema (agentes de revisión, documentación de patrones, generadores de tests). ROI: 1 hora creando un agente de revisión ahorra 10 horas a lo largo del año — las mejoras del sistema se acumulan, las funcionalidades no.
7. 8 creencias a 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") / escribir más significa aprender más ("la comprensión importa más que la memoria muscular") / el pensamiento de ingeniería ≠ pensamiento de producto.
8. 8 creencias a adoptar. extraer el propio criterio hacia el sistema; regla 50/50; confiar en el proceso + redes de seguridad; entorno agent-native ("si un desarrollador puede ver o hacer algo, el agente también debería poder hacerlo"); 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 estás ausente.
9. Escala de adopción de 5 niveles. 0 manual → 1 asistencia por chat → 2 agéntico con revisión línea por línea (la mayoría se estanca aquí) → 3 planificación primero, revisión a nivel de PR (transición clave: compound engineering comienza aquí) → 4 idea→PR (1 máquina) → 5 ejecución paralela en la nube (multi-funcionalidad, multi-dispositivo).
10. Agent-native — 4 niveles. (1) desarrollo básico (archivos, tests, 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 el nivel 5.
11. Skip permissions. alias cc='claude --dangerously-skip-permissions'; nombre deliberadamente alarmante; redes de seguridad = git reset, tests, revisión de PR, worktrees. Ganancia de flujo de 5-10×. Nunca en producción ni durante el aprendizaje.
12. 3 preguntas sin herramientas. "¿Cuál fue la decisión más difícil?" / "¿Qué alternativas rechazaste y por qué?" / "¿De qué tienes menos confianza?"
13. Buenas prácticas detalladas. baby app desechable para iterar sobre el diseño; figma-design-sync + design-iterator; codificación del criterio de diseño/textos en skills; investigación de usuarios estructurada (personas, frontmatter) legible por IA; extracción de patrones de uso (uso intensivo/dificultad/workaround/abandono); los textos = UX (codificación de la voz); marketing de producto automatizado (notas de versión + capturas de pantalla de Playwright generadas a partir del plan).
14. Fuerte vínculo con la veille. texto de consolidación de la filosofía difundido en [[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.