Cada unidad de trabajo
debe hacer la siguiente más fácil.
Compound Engineering es la filosofía que Every desarrolló construyendo Cora desde cero. En lugar de acumular deuda técnica, cada ciclo de trabajo enseña algo al sistema y el desarrollo se vuelve progresivamente más rápido. Esta guía lo cubre todo: filosofía, loop, etapas de adopción, plugin, skills y el playbook completo.
Qué es Compound Engineering
Compound engineering nació mientras Every construía Cora, una "AI chief of staff" para tu bandeja de entrada. Probando patrones, agentes y workflows en muchos pull requests, los hacks personales de productividad evolucionaron hacia un enfoque sistemático de desarrollo asistido por IA.
🏗️ El problema que resuelve
En la ingeniería tradicional, cada nueva feature inyecta complejidad: tras años, cada funcionalidad se convierte en una negociación con las antiguas. El código se vuelve más difícil de entender, modificar y confiar, y los equipos pasan más tiempo peleando con el sistema que construyendo sobre él.
🔄 El giro compound
En compound engineering, las features no suman fragilidad: enseñan nuevas capacidades al sistema. Los bug fixes eliminan categorías enteras de bugs futuros. Los patrones codificados se convierten en herramientas. Con el tiempo, el codebase se vuelve más fácil de entender, modificar y confiar.
La prueba: Every opera cinco productos (Cora, Monologue, Sparkle, Spiral y el sitio Every.to) con equipos de ingeniería esencialmente de una persona. El sistema que lo hace posible es el loop de cuatro pasos del compound engineering.
La filosofía central
"Cada unidad de trabajo de ingeniería debe hacer las unidades siguientes más fáciles, no más difíciles." Todo lo demás deriva de esa única frase.
Retorno compuesto
Una hora creando un agente de review ahorra diez horas de review durante el año. Las mejoras de sistema aceleran el trabajo progresivamente. El trabajo de features, solo, no.
Enseñar > hacer
El tiempo dando contexto a los agentes paga dividendos exponenciales. El tiempo tecleando código solo resuelve la tarea que tienes delante.
Shipea más, teclea menos
Tu producción debe medirse por el número de problemas resueltos, no por el número de teclas presionadas.
Esto va más allá de la ingeniería. Los principios aplican al diseño, la investigación e incluso la escritura: cualquier disciplina donde codificar gusto y contexto haga el trabajo futuro más rápido. Los pasos son siempre los mismos: planear, ejecutar, revisar, componer.
El loop principal
Plan → Work → Review → Compound → Repeat. Los tres primeros pasos son familiares para cualquier dev. El cuarto es lo que separa compound engineering del resto: ahí es donde se acumulan las ganancias. Sáltalo y solo habrás hecho ingeniería tradicional con ayuda de IA.
El loop funciona igual para corregir un bug en cinco minutos o construir una feature durante días. Solo gastas más o menos tiempo en cada paso. Haz clic en cada etapa para explorar:
La regla 80/20 del tiempo
Planning y review deben consumir el 80% del tiempo del ingeniero; work y compound, el otro 20%. Es decir: la mayor parte del pensamiento ocurre antes y después de escribir el código. Y mirando el alcance total del trabajo, Every sugiere la regla 50/50: mitad del tiempo construyendo features, mitad mejorando el sistema.
Plans are the new code. El documento de plan es ahora el artefacto más importante que produces. En lugar de codear primero y documentar después, empieza por el plan: se convierte en la fuente de verdad que los agentes usan para generar, probar y validar código. Arreglar ideas en papel es mucho más barato que arreglar código después.
Los 8 principios fundamentales
Las creencias que sustentan este nuevo enfoque de desarrollo de software:
Cada unidad de trabajo facilita la siguiente
Código, documentación y herramientas deben apoyarse entre sí y hacer el trabajo futuro más rápido, nunca más lento.
El gusto pertenece al sistema, no al review
Embebe tu juicio en configuración, schemas y checks automatizados. Si no lo haces, gastarás tiempo verificando manualmente, lo cual no escala.
Enseña al sistema, no hagas el trabajo
El tiempo dando contexto a los agentes paga dividendos exponenciales; el tiempo tecleando código solo resuelve la tarea inmediata.
Construye redes de seguridad, no procesos de review
La confianza en el trabajo con IA viene de infraestructura de verificación, no de gatekeeping manual en cada paso.
Haz el entorno agent-native
Estructura proyectos para que agentes de IA puedan navegarlos y modificarlos autónomamente.
Pensamiento compuesto en todo
Todo artefacto (código, docs, tests, prompts) debe hacer la próxima iteración más rápida.
Abraza la incomodidad de soltar
Delegar en IA exige aceptar resultados imperfectos que escalan, en vez de resultados perfectos que no escalan.
Shipea más valor, teclea menos código
Tu salida se mide por problemas resueltos, no por teclas presionadas.
Creencias a abandonar
Nos entrenaron para creer ciertas cosas sobre el desarrollo de software. Con la evolución de las herramientas de IA, algunas de esas creencias se volvieron obstáculos. Haz clic en cada una para entender por qué abandonarla:
El requisito real de tu trabajo como ingeniero es escribir buen código: código mantenible que resuelve el problema correcto. Quién lo teclea (humano o agente) no importa.
El review manual línea a línea es un método para llegar a código de calidad, pero los sistemas automatizados que atrapan los mismos problemas también lo son. Si no confías en los resultados, arregla el sistema en vez de compensar haciéndolo todo tú mismo.
Cuando la IA investiga enfoques, analiza trade-offs y recomienda opciones, el trabajo del ingeniero pasa a ser añadir taste: saber qué solución encaja en este codebase, este equipo y este contexto.
Un sistema que produce código vale más que cualquier pieza individual de código. Una implementación brillante aislada importa menos que un proceso que produce implementaciones buenas consistentemente.
El trabajo del dev es entregar valor. El código es solo un insumo: planear, revisar y enseñar al sistema también cuentan. Los compound engineers eficientes escriben menos código que antes y entregan más.
Los primeros intentos tienen una tasa de basura de ~95%; los segundos, ~50%. Eso no es fracaso, es el proceso. Apunta a la perfección en el primer intento, pero enfócate en iterar lo bastante rápido para que el tercer intento acierte en menos tiempo del que tomó el primero.
El código nunca fue realmente tuyo: pertenece al equipo, al producto y a los usuarios. Desapegarse es liberador: aceptas mejor el feedback, refactorizas sin vacilar y te saltas las discusiones sobre si el código "está lo bastante bien".
El entendimiento importa más que la memoria muscular. Aprendes revisando, atrapando errores y sabiendo cuándo la IA está equivocada. El dev que revisa diez implementaciones de IA entiende más patrones que quien tecleó dos a mano.
Creencia a adoptar — extrae tu taste al sistema: el taste del equipo suele vivir en la cabeza de los ingenieros senior. Documenta preferencias en CLAUDE.md o AGENTS.md para que el agente las lea en cada sesión, crea agentes especializados y skills que reflejen tu estilo, y apunta el agente a tus guías de estilo y registros de decisión. Cuando la IA entiende cómo te gusta escribir código, produce código que apruebas, no código que tienes que arreglar.
Las 6 etapas de adopción
Cuánto del proceso dejas que la IA asuma depende de dónde estás en la escalera de familiaridad. La mayoría de los devs que se atascan con IA no saben dónde están: oyen hablar de sistemas multi-agente, se sienten abrumados e intentan saltar etapas. Saltar etapas no funciona — cada peldaño construye los modelos mentales y hábitos del siguiente. Descubre dónde estás y evoluciona desde ahí:
Las 3 preguntas de oro
Incluso sin un sistema multi-agente sofisticado, capturas gran parte del beneficio haciendo estas tres preguntas antes de aprobar cualquier output de IA:
Obliga a la IA a revelar dónde están las partes traicioneras y dónde tuvo que hacer juicios.
Muestra las opciones consideradas y ayuda a atrapar malas elecciones.
Hace que la IA admita dónde puede estar equivocada. Los LLM conocen sus debilidades, pero tienes que preguntar.
El plugin oficial
El workflow completo de compound engineering se distribuye como un plugin open source (licencia MIT), mantenido por @kieranklaassen y @tmchow. Son 33 skills cuyos workflows principales despachan subagentes especialistas bajo demanda para investigación, review, planificación e implementación, lo que mantiene todo portátil entre las diferentes herramientas. El proyecto es deliberadamente opinado: su dirección refleja un punto de vista específico sobre cómo debe funcionar la ingeniería asistida por IA.
skills en el inventario completo
agentes especialistas de review en paralelo
herramientas soportadas oficialmente
Instalación
# Claude Code claude /plugin marketplace add EveryInc/compound-engineering-plugin claude /plugin install compound-engineering
¿Ya lo instalaste? El plugin migró a un layout root-native: actualiza el marketplace primero (/plugin marketplace update compound-engineering-plugin) y luego ejecuta /plugin update — ejecutar solo el update te mantiene en la versión vieja.
# No chat do Cursor Agent /add-plugin compound-engineering # ou busque por "compound engineering" no marketplace de plugins
# Codex CLI: registre o marketplace e instale o plugin codex plugin marketplace add EveryInc/compound-engineering-plugin codex plugin add compound-engineering@compound-engineering-plugin
En la Codex App: abre Plugins en la barra lateral → Add marketplace con source EveryInc/compound-engineering-plugin, ref main, luego instala y reinicia. La instalación es autocontenida: reviewers e investigación viven dentro de las skills como assets de prompt.
# Copilot CLI /plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering@compound-engineering-plugin # ou via shell com o binário copilot copilot plugin marketplace add EveryInc/compound-engineering-plugin copilot plugin install compound-engineering@compound-engineering-plugin
En VS Code: Chat: Install Plugin from Source en la paleta de comandos, usando el repositorio EveryInc/compound-engineering-plugin.
# opencode.json (global ou do projeto) { "plugin": ["compound-engineering@git+https://github.com/EveryInc/compound-engineering-plugin.git"] } # reinicie o OpenCode depois de alterar a config
# Kimi Code CLI (o repo tem manifest nativo .kimi-plugin) /plugins install https://github.com/EveryInc/compound-engineering-plugin # depois rode /reload ou inicie uma nova sessão
# Antigravity CLI (agy), sucessor do Gemini CLI agy plugin install https://github.com/EveryInc/compound-engineering-plugin agy plugin list
| Herramienta | Instalación |
|---|---|
| Cline | ./.cline/scripts/install-skills.sh --global + ativar Skills nas configurações |
| Grok Build CLI | grok plugin install EveryInc/compound-engineering-plugin |
| Devin CLI | devin plugins install EveryInc/compound-engineering-plugin |
| Factory Droid | droid plugin marketplace add <repo> + droid plugin install compound-engineering@compound-engineering-plugin |
| Qwen Code | qwen extensions install EveryInc/compound-engineering-plugin:compound-engineering |
| Pi | pi install git:github.com/EveryInc/compound-engineering-plugin (+ pi-subagents para workflows com subagentes) |
| oh-my-pi (omp) | omp plugin marketplace add EveryInc/compound-engineering-plugin + omp plugin install compound-engineering@compound-engineering-plugin |
No necesitas Bun para instalar: solo es necesario para desarrollo del repositorio y mantenimiento del conversor.
Después de instalar
# em qualquer projeto: /ce-setup # reporta capacidades de ferramentas disponíveis, cria .compound-engineering/config.yaml # quando ausente, atualiza o exemplo commitado e adiciona override local ao .gitignore
Dónde viven las cosas
CLAUDE.md es el archivo más importante: cuando algo sale mal, añade una nota ahí para que el agente aprenda. docs/solutions/ construye tu conocimiento institucional — cada problema resuelto se vuelve documentación buscable que las sesiones futuras encuentran automáticamente. Y todos/ organiza los hallazgos de review por prioridad y estado.
Skills y comandos esenciales
El loop central en la versión actual del plugin tiene seis pasos: brainstorm → plan → work → simplify → review → compound. Cada ciclo compone: /ce-compound escribe aprendizajes que el próximo /ce-brainstorm y /ce-plan leen como grounding. Esa flecha de retorno es el punto entero.
| Skill | Rol en el loop |
|---|---|
| /ce-brainstorm core | Q&A interactivo para pensar una feature o problema y escribir un doc de requisitos unificado, antes de la planificación |
| /ce-plan core | Enriquece ideas o docs de requisitos en planes listos para implementar. Dispara tres agentes de investigación en paralelo (codebase, docs del framework, mejores prácticas) y fusiona todo en un plan estructurado |
| /ce-work core | Ejecuta planes listos, nativamente o vía un autor cross-model cualificado, manteniendo verificación, commits y shipping en el host |
| /ce-simplify-code core | Refina el código recién escrito para claridad y reuso antes del review |
| /ce-code-review core | Review multi-agente report-only contra el plan, antes del merge; la aplicación local es explícita. También hay /ce-doc-review para documentos |
| /ce-compound core | Captura el aprendizaje en docs/solutions/ para que el próximo loop empiece más inteligente |
| /lfg | Workflow autónomo completo: describe la feature y el agente planifica, trabaja, simplifica, revisa, aplica fixes, corre tests de browser y abre el PR. Pausa para aprobación del plan y luego corre hands-off |
| /ce-debug | Para bugs en vez de features: reproduce, traza la causa raíz, corrige y prepara el fix para un PR |
| /ce-ideate | Cuando aún no sabes qué construir: investiga (codebase, aprendizajes pasados, prior art, issues abiertas) y entrega ideas ranqueadas y fundamentadas |
| /ce-strategy | Crea y mantiene el STRATEGY.md, leído como grounding por ideate, brainstorm y plan |
| /ce-product-pulse | Reporte con ventana de tiempo sobre lo que los usuarios realmente experimentaron (uso, performance, errores) |
| /ce-pov | Veredicto decisivo y fundamentado sobre adopción, documento o conjunto de enfoques |
| /ce-explain | Convierte un concepto, diff o "¿qué hice esta semana?" en un documento visual denso y autocontenido |
| /ce-dogfood | QA hands-off en browser del diff de la rama activa, con correcciones autónomas |
| /ce-babysit-pr | Vigila un PR abierto y lo mantiene avanzando hacia el merge, reaccionando a comentarios de review y CI conforme llegan |
El catálogo completo tiene 33 skills, incluyendo /ce-commit, /ce-worktree, /ce-prototype, /ce-polish, /ce-test-browser, /ce-handoff, /ce-compound-refresh, /ce-sweep y más.
Ejemplo: el loop estándar en la práctica
# transforme uma ideia vaga em código revisado e shippado /ce-brainstorm tornar os retries de background job mais seguros /ce-plan /ce-work /ce-simplify-code /ce-code-review /ce-compound
# ou o modo autônomo: descreva a feature, aprove o plano, volte para um PR aberto /ce-brainstorm descreva a feature aqui /lfg
/lfg es el piloto automático: corre el loop hands-off — planifica, ejecuta, simplifica, revisa y aplica fixes, corre tests de browser y, si hay remote, abre el PR y vigila el CI con un loop de reparación limitado (no hace merge solo). Córrelo después de /ce-brainstorm para que planifique contra requisitos reales, no contra un prompt de una línea.
Review multi-agente
El paso de review dispara más de 14 agentes especializados en paralelo, cada uno enfocado en un dominio específico. Todo se combina en una única lista priorizada de hallazgos. Los hallazgos reciben prioridad:
P1 · CRÍTICO hay que corregir P2 · IMPORTANTE deberías corregir P3 · MENOR bueno corregir
un solo PR dispara 14+ agentes especialistas en paralelo
🛡️ Seguridad
security-sentinel — escanea el top 10 de OWASP, ataques de inyección, fallos de autenticación y bypasses de autorización.
⚡ Performance
performance-oracle — detecta queries N+1, índices ausentes, oportunidades de cache y cuellos de botella algorítmicos.
🏛️ Arquitectura
architecture-strategist evalúa decisiones de diseño, límites de componentes y dirección de dependencias. pattern-recognition-specialist identifica patrones, anti-patrones y code smells.
🗄️ Datos
data-integrity-guardian valida migraciones, límites de transacción e integridad referencial. data-migration-expert revisa mapeo de IDs, seguridad de rollback y validación en producción.
✨ Calidad
code-simplicity-reviewer (YAGNI, complejidad innecesaria) + reviewers por lenguaje: Rails (dos escuelas: DHH y Kieran), Python (PEP 8, type hints) y TypeScript (type safety, clean architecture).
🚀 Deploy y Frontend
deployment-verification-agent genera checklists pre/post-deploy y planes de rollback. julik-frontend-races-reviewer detecta race conditions en JS/Stimulus. agent-native-reviewer garantiza que las features sean accesibles a agentes, no solo a humanos.
Resolución automatizada: el comando de resolución procesa todos los hallazgos automáticamente — P1 primero, luego P2, cada fix en aislamiento para que uno no pise al otro. Al final aún revisas manualmente los fixes generados. /triage presenta cada hallazgo para decisión humana: aprobar, saltar o personalizar.
Entorno agent-native
Arquitectura agent-native significa dar al agente las mismas capacidades que tú tienes. Si el agente no corre tests, tienes que correrlos tú. Si no ve logs, tienes que debuggear. Toda capacidad que le niegas a la IA se convierte en una tarea tuya. La meta: paridad ambiental total entre devs humanos y de IA.
Checklist de capacidades
Marca lo que tu agente ya puede hacer hoy (haz clic para marcar):
- Correr la aplicación localmente
- Correr la suite de tests
- Correr linters y type checkers
- Correr migraciones y seedear datos de dev
- Crear branches, commits y push al remote
- Crear pull requests y leer comentarios de PR
- Ver logs locales y de producción (read-only)
- Tomar screenshots de la UI
- Inspeccionar network requests
- Acceder a error tracking (Sentry, etc.)
Los 4 niveles de madurez agent-native
Básico
Acceso a archivos, tests y git commits. La base que desbloquea el compound engineering.
Local completo
Browser, logs locales y creación de PRs. Habilita las etapas 3-4 de la escalera.
Visibilidad de producción
Logs de producción (read-only), error tracking y dashboards. El agente debuguea proactivamente.
Integración total
Sistemas de tickets, deploy y servicios externos. Habilita la etapa 5 (ejecución paralela en cloud).
Agent-native también es un mindset. Al construir features, pregunta: "¿cómo interactuará el agente con esto?". Al debuggear: "¿qué necesitaría ver el agente?". Al documentar: "¿el agente entenderá esto?".
Skip permissions
Por defecto Claude Code pide permiso antes de cada acción. La flag --dangerously-skip-permissions apaga esos prompts — el nombre es intencionalmente aterrador para hacerte pensar antes de usarlo. Pero en la etapa 3+, los pedidos constantes de permiso matan el flow.
✅ Cuándo usar
- Confías en el proceso: tienes un buen plan y buenos sistemas de review
- Estás en un entorno seguro (sandbox, nada que afecte usuarios reales)
- Quieres velocidad: los pedidos de permiso rompen el flow
❌ Cuándo NO usar
- Estás aprendiendo: los prompts ayudan a entender qué pasa
- Estás en producción: nunca, porque toca usuarios reales
- No tienes buen rollback: si no puedes deshacer fácil, mantén los prompts
Seguridad sin prompts
🔀 Git es la red de seguridad
Todo lo que el agente hace está en git. git reset --hard HEAD~1 y volviste.
🧪 Los tests atrapan errores
Antes del merge, corre los tests. Si el agente rompió algo, lo capturan.
👀 Review antes del merge
Skip permissions salta prompts de implementación, no el review final del PR.
🌲 Worktrees aíslan riesgo
El trabajo riesgoso ocurre en un directorio aislado vía git worktrees.
El cálculo de productividad: sin skip permissions, un prompt cada 30 segundos, cada uno exigiendo un "y" y perdiendo foco — multiplicado cientos de veces por sesión. Con skip permissions, mantienes el flow state y desbloqueas iteración 5-10x más rápida, y el tiempo ahorrado puede superar dramáticamente el riesgo de ocasionalmente revertir algo.
Vibe coding
Vibe coding es para quienes no les importa el código en sí — quieren resultados. Puede ser un PM prototipando ideas, un diseñador probando una interacción o un proyecto personal que nunca volverás a mirar. La filosofía: saltar la escalera e ir directo a la etapa 4 — describir lo que quieres y dejar que los agentes lo construyan.
Perfecto para
- Proyectos personales
- Prototipos y experimentos
- Investigaciones "¿esto funciona?"
- Herramientas internas
- Exploración de UX
Malo para
- Sistemas en producción con usuarios
- Código que otros mantendrán
- Apps sensibles a seguridad
- Sistemas críticos de performance
La paradoja del vibe coding: puede mejorar tu planificación. Cuando no sabes qué construir, genera prototipos, compártelos con usuarios, recoge feedback, haz clic en ellos. Luego borra todo y empieza de nuevo con un plan de verdad. La división óptima: vibe code para descubrir qué quieres, spec para construir bien. El spec siempre gana en la implementación final, pero el vibe coding acelera el descubrimiento.
# sessão de exemplo: descrever → esperar → testar → corrigir → ship Você: /lfg quero um site onde colo um link do YouTube e ele extrai a transcrição ... agente trabalha por alguns minutos ... Você: funciona, mas o texto está difícil de ler. aumenta a fonte. ... agente corrige ... Você: perfeito. ship it.
Design workflow
El diseño es más fácil de iterar en código que en mockups — puedes hacer clic y sentir las interacciones. Pero no quieres experimentar en el codebase de producción. El flujo: prototipar en proyectos desechables, probar con usuarios y capturar el gusto de diseño para que la IA lo replique.
El enfoque "baby app"
El workflow
- Crea un repo de prototipo: mkdir baby-myapp
- Vibe-codea el diseño sin miedo
- Itera hasta que se sienta bien: "más espacio, toggle más prominente"
- Captura el design system: colores, espaciado, tipografía, patrones
- Transfiere al app principal usando el prototipo como referencia
Loop de descubrimiento UX
Cuando no sabes qué construir: pide cinco versiones diferentes de una pantalla, haz clic en cada una, compártelas con usuarios ("¿este flujo te confundiría?"), recoge feedback en prototipos funcionales (a diferencia de un mockup de Figma, se puede hacer clic) y luego borra todo y empieza de nuevo con un plan de verdad. El prototipo sirve para aprender, no para shippear.
Trabajando con diseñadores
| Flujo tradicional | Flujo compound | |
|---|---|---|
| Proceso | El diseñador crea el mockup → el dev interpreta y construye → el diseñador dice "no está bien así" → idas y vueltas hasta que quizás coincide | El diseñador crea el mockup en Figma → corres /plan con el link → la IA lo construye → el agente figma-design-sync verifica contra el mockup → el diseñador revisa la versión en vivo, no un screenshot → itera hasta la perfección |
| Gusto | Vive en la cabeza del diseñador | Codificado en una skill (colores, espaciado, patrones). La IA produce diseños que coinciden con el gusto del diseñador, incluso sin él involucrado |
Agentes de diseño: design-iterator toma screenshot del diseño actual, analiza qué no funciona, mejora y repite. figma-design-sync trae el diseño de Figma, lo compara con lo construido y corrige diferencias automáticamente. design-implementation-reviewer verifica que las implementaciones coincidan con las specs de Figma antes de llegar a los usuarios.
Colaboración en equipos
Cuando la IA maneja la implementación, la dinámica del equipo cambia. Necesitas nuevos acuerdos: quién aprueba planes, quién es dueño de los PRs y qué revisan los humanos cuando los agentes ya hicieron la primera pasada.
Flujo tradicional
La persona A escribe código → la persona B revisa → discusión en los comentarios del PR → merge tras aprobación.
Flujo compound
La persona A crea el plan → la IA implementa → agentes de IA revisan → la persona B revisa el review de la IA → merge con aprobación humana.
✅ Aprobación de plan
Leer un plan y estar de acuerdo es una decisión. El silencio no es aprobación — es ausencia de decisión. Exige sign-off explícito antes de implementar: un comentario, un tag en el commit u otro marcador.
👤 Dueño del PR
Quien inició el trabajo es dueño del PR, sin importar quién (o qué) escribió el código. Respondes por la calidad del plan, el review, los fixes y el impacto post-merge.
🎯 Foco del review humano
Cuando los agentes ya analizaron el PR, los humanos se enfocan en intención, no implementación: ¿coincide con lo acordado? ¿tiene sentido el enfoque? ¿hay problemas de lógica de negocio? Los errores de sintaxis, seguridad y performance ya son de los agentes.
Patrones de comunicación y escala
📬 Asíncrono por defecto
Los planes pueden crearse, revisarse y aprobarse sin reunión. En vez de "reunámonos a discutir", prueba "creé el plan — comenten hasta fin del día". Handoffs explícitos: estado, qué está hecho, qué falta, contexto y cómo continuar.
🚩 Flags + PRs pequeños
Todos shippeando más rápido = más conflictos de merge. Shippea trozos pequeños, usa feature flags, mergea a main con frecuencia y resuelve conflictos al momento. Y cada feature grande tiene un único dueño, que actualiza al equipo asíncronamente.
Compound docs = conocimiento tribal. No deberías necesitar preguntar a un colega algo que podría estar embebido en el sistema. En vez de "pregúntale a Sarah, ella sabe cómo funciona el auth", Sarah corre /compound después de implementar. La solución queda documentada y cualquiera la encuentra.
Investigación de usuarios que la IA usa
Estructura la investigación para que la IA pueda usarla. Las notas crudas de entrevista son difíciles de aprovechar: los insights necesitan cita, implicación y confianza.
El abismo investigación ↔ desarrollo
Tradicional: el investigador entrevista → escribe reporte → el reporte se pudre en Drive → el dev construye sin leerlo → la feature no coincide con la necesidad del usuario.
Compound: la investigación genera insights estructurados → los insights se vuelven contexto de planificación → la IA referencia insights al planificar → las features son informadas por la investigación → los datos de uso validan los insights → los insights componen.
Insight estructurado
# 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
Personas referenciables + planificación informada
Crea documentos de persona (objetivos, frustraciones, citas) que la IA pueda referenciar y alimenta los planes con contexto de investigación:
/ce-plan adicionar exportação agendada Contexto de pesquisa: - 3/5 usuários entrevistados mencionaram exportação semanal - a persona marketing-manager exporta toda sexta - dor atual: processo manual de exportação Desenhar para: exports semanais automáticos por e-mail
Extracción de patrones de datos
Tus usuarios ya te están diciendo qué construir por cómo usan tu producto. Cada clic es una pista. Solo tienes que prestar atención:
🔥 Uso intenso
Features usadas mucho más de lo esperado; usuarios volviendo a la misma página repetidamente. Señal de que ahí vive valor (o dependencia).
😤 Struggle
Tiempo de permanencia alto en páginas simples; intentos repetidos de la misma acción; loops de error → retry → error.
🛠️ Workaround
Usuarios inventando soluciones porque el producto no hace lo que necesitan: exportar de un lugar e importar en otro, copiar-pegar entre pantallas, varias pestañas abiertas para comparar.
🚪 Abandono
Dónde los usuarios desisten en los flujos: features empezadas pero no completadas.
De patrón a feature: notas que usuarios copian datos de una tabla y los pegan en otra 50 veces por semana → insight: necesitan automatización entre tablas → feature: botón "sincronizar con tabla B". O notas que usuarios crean proyectos "template" y los duplican → insight: quieren templates → feature: soporte de templates de primera clase.
Copywriting
La mayoría de los equipos trata el copy como pensamiento tardío — algo para rellenar después de que la feature está lista. Pero el copy es parte de la experiencia del usuario y merece la misma atención que el código.
📋 Copy en el plan
Incluye el copy en el plan desde el inicio: asunto del email, mensaje de éxito, mensajes de error. Cuando la IA implementa, el copy ya está ahí.
🗣️ Codifica tu voz
Crea una skill definiendo principios ("habla como humano, no como robot"; "los errores deben ayudar, no culpar") y palabras a evitar ("inválido" → "no funcionó"; "exitosamente" → di lo que pasó).
🔎 Revisa copy como código
Añade un agente copy-reviewer al proceso: claridad (¿un usuario no técnico entiende?), utilidad, tono (¿coincide con la guía de voz?) y consistencia con textos similares.
Marketing de producto
Felicidades, shippeaste algo. Ahora cuéntale al mundo: el mismo sistema que construye features puede anunciarlas. Release notes generadas del plan, posts sociales, screenshots automáticos — todo fluye de un solo lugar, nada necesita handoff y nada se escapa.
| Paso del flujo compound |
|---|
| 1 · El ingeniero crea un plan que incluye la propuesta de valor del producto |
| 2 · La IA implementa la feature |
| 3 · La IA genera release notes a partir del plan (beneficio del usuario primero, un ejemplo concreto, breaking changes, menos de 200 palabras) |
| 4 · La IA genera posts sociales a partir de las release notes |
| 5 · La IA genera screenshots con Playwright — sin pedir a ingeniería, nunca desactualizados |
| 6 · El ingeniero revisa y shippea todo junto. Para varias features, /changelog lee los merges recientes y genera el changelog |
Vibe coding vs. ingeniería con IA
Compound engineering es la respuesta estructurada al riesgo del "vibe coding": código que parece funcionar pero no es sostenible. Mira el contraste:
| Vibe Coding | AI Engineering / Compound | |
|---|---|---|
| Entrada | Prompt vago → código "parece ok" | Spec clara + criterios de aceptación |
| Proceso | Sin spec, sin tests, sin review | El agente ejecuta con contexto del repositorio |
| Resultado | Funciona en la demo, se rompe en producción | Review humano + tests |
| Deuda | La deuda técnica crece con cada PR | Aprendizajes documentados (compounding) |
La síntesis: vibe coding es genial para prototipado rápido; la ingeniería con IA es lo que escala en producción. Los equipos que dominan agentes entregan funcionalidades en horas en vez de semanas, pero la velocidad sin proceso se convierte rápidamente en deuda técnica. La pregunta relevante hoy ya no es "¿usas IA?", sino "¿sabes orquestar IA?".
Spec-driven y el stack de 2026
Compound engineering conversa directamente con otra tendencia: el Spec-Driven Development, donde la especificación se vuelve un contrato ejecutable antes de cualquier línea de código. El flujo típico: Constitution (AGENTS.md) → SPEC.md → TASKS.md → Código + PR — exactamente el espíritu de /ce-brainstorm → /ce-plan → /ce-work.
Mapa de herramientas
| Categoría | Ejemplos | Cuándo usar |
|---|---|---|
| IDE AI-first | Cursor, Windsurf, Kiro | Día a día en el editor, plan + agent |
| Agente de terminal | Claude Code, Codex CLI, Aider | Refactors grandes, multi-archivo, CI |
| Inline / PR | GitHub Copilot | Autocomplete + review en el PR |
| Agente cloud | Devin, Jules, Codex Cloud | Tareas largas, tickets, PRs remotos |
| Chat / investigación | Claude, ChatGPT, Gemini | Diseño, trade-offs, aprendizaje |
Stack recomendado (referencia 2026)
| Capa | Sugerencia | Por qué |
|---|---|---|
| IDE principal | Cursor | Plan + Agent + rules + MCP |
| Agente de terminal | Claude Code | Tareas largas, plugins de Compound Engineering |
| Chat / diseño | Claude ou ChatGPT | Trade-offs y especificaciones |
| PR / CI | Copilot + checks automáticos | Review integrado al flujo de GitHub |
| Contexto | AGENTS.md + rules | La base del compounding en el repositorio |
Checklist del día a día
- AGENTS.md / CLAUDE.md actualizado en el repositorio
- Reglas específicas para puntos sensibles (auth, billing, base de datos)
- Plan mode usado antes de features grandes
- Tests y typecheck corridos por el agente
- Diff siempre leído antes del commit
- Aprendizajes documentados (compounding)
- Ningún secreto en el historial del chat
Cuándo no usar IA
Mejor manualmente
- Decisiones arquitectónicas críticas sin criterios definidos
- Hotfixes pequeños que ya entiendes completamente
- Código sujeto a regulación con accountability humana exigida
- Aprender un fundamento por primera vez
Perfecto con IA
- Boilerplate, tests y migraciones
- Explorar una base de código desconocida
- Refactorizaciones mecánicas cubiertas por tests
- Borradores de descripción de PR y documentación
Fuentes
Esta guía fue compilada a partir de:
- Compound Engineering: The AI-native engineering philosophy — la guía completa de Kieran Klaassen en Every
- EveryInc/compound-engineering-plugin — el plugin oficial en GitHub (MIT, 24k+ estrellas)
- Documento interno: Técnicas de Programación con IA: Compound Engineering, Spec-Driven Development y el Stack de 2026