Compound Engineering: filosofía de ingeniería nativa de IA

• Una metodología de desarrollo de software compuesta en la que cada unidad de trabajo de ingeniería facilita el trabajo posterior, con un bucle de 4 etapas (planificar → ejecutar → revisar → componer) que sistematiza la colaboración con agentes de IA como eje central
• En el bucle iterativo, el 80% del tiempo del ingeniero debe asignarse a planificación y revisión, y el 20% a ejecución y composición
• Se distribuye en formato de plugin con 26 agentes especializados, 23 comandos de flujo de trabajo y 13 habilidades, y puede instalarse en Claude Code, OpenCode y Codex
• Presenta 8 ideas convencionales del desarrollo de software existente (el código debe escribirse a mano, cada línea debe revisarse manualmente, etc.) como creencias que hay que abandonar, y propone adoptar nuevos principios para codificar preferencias dentro del sistema
• Distingue el nivel de adopción de IA por parte del desarrollador desde nivel 0 (desarrollo manual) hasta nivel 5 (ejecución paralela en la nube), y ofrece un marco integral que incluye cómo subir de nivel en cada etapa y extenderlo a colaboración de equipo, diseño, investigación y marketing

---

Filosofía central

• El principio central es que cada unidad de trabajo de ingeniería debe hacer más fácil el trabajo posterior
• En una base de código tradicional, la complejidad aumenta cada vez que se añade una función, por lo que después de 10 años se termina dedicando más tiempo a pelear con el sistema
• En Compound Engineering, las funciones enseñan nuevas capacidades al sistema, las correcciones de errores eliminan categorías enteras de bugs futuros y los patrones se convierten en herramientas, de modo que la base de código se vuelve más fácil de entender, modificar y confiar con el paso del tiempo

Bucle principal: Plan → Work → Review → Compound

• El equipo de Every opera 5 productos (Cora, Monologue, Sparkle, Spiral, Every.to) principalmente con equipos de ingeniería de una sola persona, y lo que lo hace posible es este bucle de 4 etapas
• Las primeras 3 etapas (planificación, ejecución y revisión) son comunes, pero la etapa 4, Compound, es el diferenciador clave donde se acumulan los beneficios compuestos
• Ya sea una corrección de error de 5 minutos o el desarrollo de una función de varios días, se usa el mismo bucle; lo único que cambia es el tiempo invertido en cada etapa

• Etapa 1: Plan (planificación)

  • Entender los requisitos: identificar qué se va a construir, por qué y bajo qué restricciones
  • Investigar la base de código: analizar cómo funcionan funciones similares y los patrones existentes
  • Investigación externa: revisar la documentación del framework y las mejores prácticas de la industria
  • Diseñar la solución: definir el enfoque y los archivos que se modificarán
  • Validar el plan: comprobar la integridad y coherencia del plan completo

• Etapa 2: Work (ejecución)

  • Configurar un entorno aislado: separar el trabajo con un Git worktree (copia aislada del repositorio) o una rama
  • Ejecutar el plan: el agente implementa paso a paso
  • Ejecutar verificaciones: después de cada cambio, correr pruebas, linting (revisión automática de código) y type check
  • Seguir el progreso y ajustar el plan si surgen problemas
  • Si confías en el plan, no hace falta vigilar cada línea de código

• Etapa 3: Review (revisión)

  • Varios agentes revisan el código en paralelo
  • Los hallazgos se priorizan como P1 (corrección obligatoria), P2 (corrección recomendada), P3 (mejora)
  • El agente corrige los problemas con base en el feedback de la revisión y valida los resultados
  • Registrar patrones: documentar qué salió mal para evitar que vuelva a ocurrir

• Etapa 4: Compound (composición) — la etapa más importante

  • El desarrollo tradicional termina en la etapa 3, pero en la etapa Compound se acumulan mejoras del sistema
  • Si las primeras 3 etapas producen funciones, la etapa 4 produce un sistema que crea mejores funciones
  • Tareas que se realizan:
    • Capturar qué fue efectivo y qué no, y qué ideas reutilizables surgieron
    • Añadir metadatos, etiquetas y categorías con YAML frontmatter para que sea fácil de buscar
    • Agregar nuevos patrones a CLAUDE.md y, si hace falta, crear nuevos agentes
    • Verificar: "¿La próxima vez el sistema podrá detectar este problema automáticamente?"

Estructura del plugin

• 26 agentes especializados: revisión (14), investigación, diseño, flujo de trabajo, documentación, etc., cada uno enfocado en tareas específicas
• 23 comandos de flujo de trabajo: bucle principal + utilidades
• 13 habilidades: aportan especialización de dominio, como arquitectura nativa para agentes y guías de estilo
• Puede instalarse sin configuración en Claude Code, OpenCode (experimental) y Codex (experimental)

• Estructura de archivos

  • CLAUDE.md: el archivo más importante, que los agentes leen al inicio de cada sesión, donde se guardan preferencias, patrones y contexto del proyecto
  • docs/solutions/: los problemas resueltos se acumulan como documentos consultables, creando conocimiento institucional
  • docs/brainstorms/: guarda la salida del comando brainstorm
  • docs/plans/: guarda la salida del comando plan
  • todos/: seguimiento de elementos de trabajo según prioridad y estado

Comandos clave

• /workflows:brainstorm

  • Comando que se usa cuando no está claro qué se va a construir
  • Tras una investigación ligera del repositorio, aclara uno por uno el objetivo, los usuarios, las restricciones y los casos límite mediante preguntas
  • La IA propone enfoques, y el resultado se guarda en docs/brainstorms/ para pasarlo a /workflows:plan

• /workflows:plan

  • Devuelve un plan de implementación si describes lo que quieres
  • Ejecuta 3 agentes de investigación en paralelo: repo-research-analyst (patrones de la base de código), framework-docs-researcher (documentación), best-practices-researcher (estándares de la industria)
  • El agente spec-flow-analyzer analiza el flujo del usuario y los casos límite
  • Al activar el modo ultrathink, se ejecuta automáticamente /deepen-plan, poniendo en marcha más de 40 agentes de investigación en paralelo

• /workflows:work

  • Etapa en la que el agente escribe el código real
  • 4 fases: quick start (crear Git worktree y configurar rama) → execute (implementar por tarea con seguimiento del progreso) → quality check (opcionalmente activar 5 o más agentes revisores) → ship it (ejecutar linting, crear PR)

• /workflows:review

  • El PR es revisado simultáneamente en paralelo por más de 14 agentes especializados
  • Incluye seguridad (security-sentinel), rendimiento (performance-oracle), arquitectura (architecture-strategist), integridad de datos (data-integrity-guardian), calidad de código (code-simplicity-reviewer), revisores por framework (DHH-rails, Kieran-rails/python/typescript), validación de despliegue, race conditions de frontend y revisor nativo para agentes, entre otros
  • La salida es una única lista priorizada, clasificada como P1 (crítico), P2 (importante), P3 (menor)
  • El comando /resolve_pr_parallel corrige automáticamente los hallazgos (priorizando P1, con cada corrección ejecutada en aislamiento)
  • Con el comando /triage, es posible filtrar los hallazgos aprobándolos, omitiéndolos o personalizándolos uno por uno

• /workflows:compound

  • Documenta los problemas resueltos para referencia futura
  • Activa 6 subagentes en paralelo: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • Genera Markdown consultable con YAML frontmatter

• /lfg

  • Si describes una función, el agente realiza planificación, implementación y revisión, y entrega un PR listo para merge
  • Encadena todo el pipeline de plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
  • Tras la aprobación del plan, se pausa y luego se ejecuta de forma autónoma, activando más de 50 agentes a lo largo de todas las etapas

8 creencias que hay que abandonar

• "El código debe escribirse a mano"

  • El requisito real es escribir buen código que sea mantenible y resuelva el problema correcto; no importa quién lo teclee

• "Cada línea debe revisarse manualmente"

  • La revisión manual línea por línea es solo una forma de garantizar la calidad, y los sistemas automatizados que detectan los mismos problemas también son válidos
  • Si no puedes confiar en el resultado, no lo compenses haciéndolo tú mismo; hay que arreglar el sistema

• "La solución debe venir de los ingenieros"

  • Como la IA puede investigar enfoques, analizar trade-offs y recomendar opciones, el rol del ingeniero es aportar criterio (taste): decidir qué solución encaja con esta base de código, este equipo y este contexto

• "El código es el principal entregable"

  • El sistema que produce código vale más que el código individual
  • Más importante que una implementación sobresaliente es un proceso que produzca implementaciones buenas de forma consistente

• "Escribir código es la tarea principal"

  • El trabajo del desarrollador es entregar valor (ship value), y el código es solo uno de los insumos
  • Planificación, revisión y entrenamiento del sistema también son parte del trabajo

• "El primer intento tiene que salir bien"

  • La tasa de falla del primer intento es del 95%, y la del segundo también es del 50%
  • Esto no es fracaso, sino proceso; hay que enfocarse en iterar rápido para que el tercer intento se complete más rápido que el primero

• "El código es una forma de expresión personal"

  • El código pertenece al equipo, al producto y a los usuarios; si no ves el código como autoexpresión, se vuelve más fácil aceptar feedback, refactorizar y debatir sobre calidad

• "Cuanto más tecleo, más aprendo"

  • Hoy en día entender importa más que la memoria muscular
  • Un desarrollador que revisa 10 implementaciones de IA entiende más patrones que otro que tecleó 2 por su cuenta

Los desafíos psicológicos de la transición

• Sentir que trabajas menos cuando tecleas menos: en realidad, dar instrucciones a un agente exige más pensamiento que implementar directamente
• La ansiedad ante la ejecución autónoma: no se trata de renunciar al control, sino de codificar el control en restricciones, reglas y procesos de revisión
• La duda de “¿esto lo hice yo?”: planificar, revisar y asegurar estándares de calidad son precisamente ese trabajo; la IA solo se encarga de escribir

Creencias que hay que adoptar

• Extraer el criterio al sistema

  • Las preferencias del desarrollador, como convenciones de nombres, patrones de manejo de errores o enfoques de testing, por lo general no están documentadas y viven en la cabeza de los ingenieros senior
  • Hay que registrar esas preferencias en CLAUDE.md o AGENTS.md, y construir agentes y skills especializados para revisión, pruebas y despliegue, de modo que la IA produzca por sí misma código digno de aprobación

• La regla 50/50

  • El 50% del tiempo de ingeniería debe asignarse al desarrollo de funciones y el otro 50% a mejorar el sistema
  • Tradicionalmente es 90% funciones / 10% otras cosas, pero crear agentes de revisión, documentar patrones y construir generadores de pruebas son inversiones que facilitan las funciones futuras
  • Una inversión de 1 hora en un agente de revisión puede ahorrar 10 horas de revisión a lo largo de un año

• Confiar en el proceso y construir redes de seguridad

  • Para que la asistencia de IA escale, no se puede pretender que un humano revise todas las líneas, así que la clave es construir guardrails como pruebas, revisiones automáticas y monitoreo
  • Si no puedes confiar en un resultado, no vuelvas a la revisión manual; agrega un sistema que haga confiable esa etapa

• Configurar el entorno como agent-native

  • Todo lo que un desarrollador puede ver o hacer, un agente también debería poder hacerlo: ejecutar pruebas, revisar logs de producción, depurar con screenshots, crear PRs, etc.
  • Toda tarea que no permitas al agente tendrás que hacerla tú manualmente

• Aprovechar el paralelismo

  • Antes, el cuello de botella era la atención humana (una tarea a la vez); ahora, el nuevo cuello de botella es el cómputo (cuántos agentes pueden ejecutarse al mismo tiempo)
  • Ejecuta varios agentes y varias funciones en paralelo, y realiza revisión, testing y documentación también en paralelo

• El plan es el nuevo código

  • El documento de planificación es ahora el entregable más importante
  • En vez de escribir primero el código y documentarlo después, si escribes primero el plan, los agentes pueden usarlo como fuente de verdad para generar, probar y validar el código
  • Corregir ideas sobre el papel es más barato que corregirlas en código

• Resumen de principios clave

  • Que cada unidad de trabajo facilite el trabajo posterior
  • Incorporar el criterio en el sistema, no en la revisión
  • No hacer el trabajo uno mismo, sino enseñarle al sistema
  • Construir redes de seguridad, no procesos de revisión
  • Estructurar el entorno para que sea agent-native
  • Aplicar pensamiento compuesto en todas partes
  • Aceptar la incomodidad de delegar y elegir resultados imperfectos pero escalables en lugar de resultados perfectos pero que no escalan
  • Escribir menos código y entregar más valor
  • Estos principios pueden extenderse más allá de la ingeniería, a diseño, research, escritura y cualquier campo donde ayude codificar criterio y contexto

Etapas de crecimiento del desarrollador (escalera de 5 niveles)

• Stage 0: desarrollo manual

  • Escribir código línea por línea sin IA, investigar con documentación y Stack Overflow, y depurar con sentencias print
  • Así se ha creado buen software durante décadas, pero en 2025 ya no es lo bastante rápido

• Stage 1: asistencia basada en chat

  • Hacer preguntas a ChatGPT, Claude o Cursor para obtener snippets de código y copiar/pegar lo útil
  • La IA acelera la investigación y la generación de boilerplate, pero sigues revisando cada línea por tu cuenta y mantienes el control total

• Stage 2: herramientas agénticas + revisión línea por línea

  • Herramientas agénticas como Claude Code, Cursor Composer o Copilot Chat leen archivos y hacen cambios directamente en la base de código
  • Tu rol es ser el gatekeeper que aprueba o rechaza todo lo que propone el agente
  • La mayoría de los desarrolladores se estanca en esta etapa y no obtiene los beneficios de delegar en la IA

• Stage 3: primero el plan, revisión a nivel PR

  • Esta es la etapa donde todo cambia: coescribir con la IA un plan detallado que incluya requisitos, enfoque y casos límite
  • Una vez hecho el plan, la IA implementa sin supervisión y la salida se revisa como PR
  • Compound Engineering empieza aquí: la planificación, implementación y revisión de cada ciclo entrenan el sistema para que el siguiente ciclo sea más rápido y más fácil

• Stage 4: idea → PR (una sola máquina)

  • Tú das una idea y el agente se encarga de todo: investigar la base de código, planificar, implementar, probar, autorrevisarse, resolver issues y crear el PR
  • Tu participación se reduce a 3 pasos: proponer la idea, revisar el PR y hacer merge
  • Aun así, todo corre de a una cosa por vez en una sola computadora

• Stage 5: ejecución paralela en la nube (múltiples dispositivos)

  • Llevar la ejecución a la nube para trabajar en paralelo
  • Asignar 3 agentes a 3 funciones al mismo tiempo y revisar cuando los PRs estén listos
  • Los agentes incluso pueden monitorear feedback y proponer correcciones por iniciativa propia
  • Tu rol deja de ser el de contribuidor individual para pasar a dirigir una flota de agentes

Guía para subir de nivel

• 0 → 1: empezar a colaborar

  • Elegir una herramienta (Cursor with Opus 4.5 o Claude Code, etc.) y usarla todos los días
  • Antes de escribir código, pedirle a la IA que explique el código existente para comprobar la comprensión
  • Delegar primero el boilerplate, como pruebas, archivos de configuración y funciones repetitivas
  • Revisar cada línea para aprender
  • Trabajo de interés compuesto: registrar continuamente los prompts que funcionaron bien

• 1 → 2: permitir acceso al agente

  • Cambiar al modo agéntico y darle al agente permisos de acceso al sistema de archivos
  • Empezar con cambios acotados de un solo archivo y un solo objetivo, como "agrega pruebas a esta función"
  • Construir intuición de confianza aprobando o rechazando cada acción
  • Revisar el diff para concentrarte en lo que cambió
  • Trabajo de interés compuesto: crear un archivo CLAUDE.md y agregar notas cuando el agente se equivoque

• 2 → 3: confiar en el plan (cambio clave)

  • Escribir los requisitos, el enfoque y los casos límite como un plan explícito
  • Permitir que la IA lea el codebase, encuentre patrones y proponga un enfoque
  • Después de escribir el plan, dejar que el agente implemente y alejarte hasta que termine
  • Revisar a nivel de PR, no de pasos individuales ni de líneas de código
  • Trabajo de interés compuesto: documentar después de cada implementación qué cosas no contempló el plan

• 3 → 4: presentar resultados, no instrucciones

  • Dar el resultado (outcome), como "agrega notificaciones por email a los comentarios nuevos", y dejar que el agente decida cómo implementarlo
  • Como el agente conoce el codebase y hace investigación, el plan también pasa a ser responsabilidad del agente
  • Revisar el enfoque antes de implementar para bloquear temprano una dirección equivocada
  • Trabajo de interés compuesto: construir una biblioteca de instrucciones centradas en resultados que hayan funcionado bien

• 4 → 5: paralelizarlo todo

  • Mover la ejecución a la nube para eliminar el cuello de botella de la máquina local
  • Asignar 3 funciones a 3 agentes al mismo tiempo
  • Organizar ideas, bugs y mejoras en una cola para que los agentes las resuelvan en orden
  • Habilitar que los agentes monitoreen el feedback de usuarios y propongan funciones por iniciativa propia
  • Trabajo de interés compuesto: distinguir y documentar qué tareas pueden ejecutarse en paralelo y cuáles son inherentemente seriales

3 preguntas antes de aprobar resultados de IA

• "¿Cuál fue la decisión más difícil aquí?" — impulsa a la IA a revelar las partes complicadas y los puntos de juicio
• "¿Qué alternativas descartaste y por qué?" — permite verificar las opciones consideradas y detectar malas elecciones
• "¿En qué parte tienes menos confianza?" — hace que el LLM admita sus debilidades, pero solo responde si se le pregunta directamente

Arquitectura nativa de agentes

• La clave es darle al agente las mismas capacidades que a un desarrollador
• Si el agente no puede ejecutar pruebas, tú tendrás que ejecutarlas; si no puede ver logs, tú tendrás que depurar, así que toda capacidad no permitida se convierte en trabajo manual

• Checklist nativo de agentes

  • Entorno de desarrollo: ejecutar apps locales, correr la suite de pruebas, ejecutar linter y type checker, migraciones de DB, sembrado de datos de desarrollo
  • Trabajo con Git: crear ramas, hacer commits, push al remoto, crear PR, leer comentarios de PR
  • Depuración: consultar logs locales/de producción (solo lectura), capturas de pantalla de la UI, inspección de solicitudes de red, acceso a error tracking (como Sentry)

• Adopción gradual de lo nativo de agentes

  • Level 1 (desarrollo básico): acceso a archivos, ejecución de pruebas, commits de Git — hace posible Compound Engineering básico
  • Level 2 (entorno local completo): acceso a navegador, logs locales y creación de PR — habilita Stage 3~4
  • Level 3 (visibilidad de producción): logs de producción (solo lectura), error tracking, dashboard de monitoreo — permite depuración proactiva por parte del agente
  • Level 4 (integración total): sistema de tickets, capacidad de despliegue, integración con servicios externos — habilita Stage 5

• Mentalidad nativa de agentes

  • Al construir una función: "¿Cómo va a interactuar el agente con esto?"
  • Al depurar: "¿Qué debería poder ver el agente?"
  • Al documentar: "¿Puede el agente entender esto?"

Skip Permissions

• La bandera --dangerously-skip-permissions de Claude Code desactiva las solicitudes de permisos que preguntan en cada acción
• El nombre es intencionalmente alarmante para hacer que lo pienses bien antes de usarla

• Cuándo usarlo

  • Recomendado: cuando hay un buen sistema de planificación y revisión, cuando se trabaja en un entorno sandbox, cuando se necesita velocidad
  • Mejor evitarlo: cuando todavía estás aprendiendo (las solicitudes de permiso ayudan a entender), al trabajar con código de producción, cuando no hay un mecanismo de rollback

• Mecanismos de seguridad al omitir permisos

  • Git como red de seguridad: el trabajo del agente queda registrado en Git y puede restaurarse con git reset --hard HEAD~1
  • Las pruebas detectan errores: ejecutar pruebas antes del merge
  • Revisión antes del merge: se pueden omitir permisos durante la implementación, pero la revisión final es obligatoria
  • Aislar riesgo con Worktree: experimentar tareas riesgosas en un directorio aislado

• Cálculo de productividad

  • Sin omitir permisos, aparece un prompt aproximadamente cada 30 segundos, y escribir "y" cada vez rompe la concentración
  • Al omitir permisos, es posible mantener el estado de flow, logrando iteraciones de 5 a 10 veces más rápidas y ahorrando mucho más tiempo que el riesgo ocasional de tener que hacer rollback

Flujo de trabajo de diseño

• Enfoque Baby App

  • Crear un proyecto desechable (baby app) en el que puedas iterar libremente sin preocuparte por pruebas, arquitectura o cambios incompatibles
  • Cuando el diseño te convenza, extraer colores, espaciado, tipografía y patrones de componentes para llevarlos al proyecto principal

• Loop de exploración UX

  • Generar varias versiones, compartir prototipos funcionales con usuarios para recopilar feedback mediante clickthrough
  • A diferencia de un mockup de Figma, se puede hacer clic de verdad
  • Los prototipos sirven para aprender y luego se vuelven a construir desde cero con una planificación adecuada

• Colaboración con diseñadores: flujo Compound

  • Flujo tradicional: mockup del diseñador → interpretación del desarrollador → repetición de correcciones
  • Flujo Compound: mockup de Figma del diseñador → pasar el link de Figma a /plan → implementación con IA → el agente figma-design-sync verifica si la implementación coincide con el mockup → el diseñador revisa una versión en vivo en lugar de capturas de pantalla

• Codificar el gusto de diseño

  • Trabajar junto con el diseñador en algunas funciones y registrar en archivos de skills los patrones descubiertos (colores preferidos, layouts de formularios, etc.)
  • La IA puede producir diseños acordes al gusto del diseñador incluso sin que el diseñador esté presente

• Agentes de diseño

  • design-iterator: analiza capturas del diseño actual e itera mejoras para refinarlo gradualmente
  • figma-design-sync: trae el diseño desde Figma, lo compara con la implementación y corrige automáticamente las diferencias
  • design-implementation-reviewer: revisa si la implementación coincide con las especificaciones de Figma para detectar bugs visuales antes de que lleguen a los usuarios

Vibe Coding

• Un enfoque para personas que solo quieren el resultado, no el código en sí: product managers, diseñadores, proyectos personales, etc.
• Se salta la escalera y va directo a Stage 4: describes lo que quieres → el agente se encarga del plan, código, pruebas, revisión y PR
• Cuándo encaja: proyectos personales, prototipos, experimentos, investigación de "¿esto se puede hacer?", herramientas internas, exploración UX
• Cuándo no encaja: sistemas de producción con usuarios, código que otras personas tendrán que mantener, apps sensibles a la seguridad, sistemas críticos de rendimiento

• La paradoja del vibe coding

  • El vibe coding incluso puede mejorar la capacidad de planificar
  • Cuando no sabes qué construir, generas un prototipo, recopilas feedback de usuarios y luego borras todo y vuelves a empezar con una planificación adecuada
  • Distribución óptima: descubrir con vibe coding, construir con especificaciones — en la implementación final, las especificaciones siempre ganan

Colaboración en equipo

• Nuevas dinámicas de equipo

  • Tradicional: la persona A escribe código → la persona B revisa → discusión en comentarios del PR → aprobación y luego merge
  • Compound: la persona A genera el plan → la IA implementa → un agente de IA revisa → la persona B revisa la revisión de la IA → aprobación humana y luego merge

• Estándares del equipo

  • Aprobación del plan: el silencio no significa aprobación, así que se requiere sign-off explícito antes de implementar
  • Propiedad del PR: sin importar quién haya escrito el código, la persona que inició el trabajo es dueña del PR, y es responsable de la calidad del plan, la revisión, las correcciones y el impacto después del merge
  • Enfoque de la revisión humana: en un PR ya analizado por un agente de revisión de IA, el humano revisa la intención (intent), no errores de sintaxis, seguridad, rendimiento ni estilo — "¿coincide con lo acordado?", "¿el enfoque es razonable?", "¿hay problemas en la lógica de negocio?"

• Patrones de comunicación

  • Asíncrono por defecto: no hacen falta reuniones para generar, revisar y aprobar planes, "ya hice el documento del plan, por favor comenta hoy"
  • Handoff explícito: debe incluir estado, lo completado, lo pendiente, el contexto y cómo continuar

• Patrones de escalamiento

  • Propiedad clara + actualizaciones asíncronas: cada funcionalidad principal tiene una persona responsable de planear, monitorear, revisar, hacer merge y actualizar al equipo
  • Feature flag + PR pequeños: cuanto más rápido despliega todo el mundo, más aumentan los conflictos de merge; despliega en unidades pequeñas, haz merge a main con frecuencia y resuelve los conflictos de inmediato
  • La documentación de Compound = conocimiento informal (tribal knowledge): en vez de "pregúntale a Sarah, sabe bien de auth", Sarah ejecuta /compound para documentar la solución y así cualquiera puede encontrarla

Investigación de usuarios

• Brecha entre investigación y desarrollo

  • Tradicional: la persona investigadora hace entrevistas → redacta un reporte → queda abandonado en Google Drive → el equipo de desarrollo no lo revisa → la funcionalidad no refleja las necesidades del usuario
  • Compound: la investigación genera insights estructurados → esos insights se usan como contexto del plan → la IA consulta esos insights al planear → los datos de uso validan los insights → los insights se acumulan de forma compuesta

• Estructuración de la investigación

  • Convierte notas de entrevistas sin procesar en Markdown estructurado para que la IA pueda usarlas: información de participantes, insights clave, citas, implicaciones y nivel de confianza (n/5 participantes)

• Documentos de persona

  • Crea documentos de persona con objetivos, frustraciones y citas para que la IA pueda consultarlos

• Planificación basada en investigación

  • Al ejecutar /workflows:plan, incluye contexto de investigación (resultados de entrevistas, patrones de personas, pain points actuales) para que los insights de investigación se conecten directamente con funcionalidades

Extracción de patrones de datos

• La forma en que las personas usan el producto da pistas sobre qué construir

• Tipos de patrones a observar

  • Patrones de uso excesivo: funcionalidades que se usan mucho más de lo esperado, visitas repetidas a la misma página
  • Patrones de dificultad: mucho tiempo de permanencia en una página simple, intentos repetidos de la misma acción, bucle de error → reintento → error
  • Patrones de workaround: exportar datos en un lugar para volver a importarlos en otro, copiar y pegar entre pantallas, mantener varias pestañas abiertas al mismo tiempo para comparar
  • Patrones de abandono: abandono dentro de un flujo, funcionalidades iniciadas pero no completadas

• De patrón a funcionalidad

  • Las personas copian y pegan datos entre tablas 50 veces por semana → se convierte en la funcionalidad "sincronizar con la tabla B"
  • Las personas crean proyectos "template" y luego los duplican → se convierte en soporte de templates de primera clase

Copywriting

• Incluir el copy en el plan

  • La mayoría de los equipos trata el copy como algo secundario que se rellena después de construir la funcionalidad, pero el copy es parte de la experiencia de usuario
  • Si incluyes desde la etapa de planificación el asunto de un email, mensajes de éxito, mensajes de error y demás copy orientado al usuario, cuando la IA implemente la funcionalidad el copy ya estará listo

• Codificar la voz

  • Redacta en un archivo de skills los principios (hablar como una persona, los mensajes de error deben ayudar, frases cortas, palabras claras) y las palabras que deben evitarse (Invalid → didn't work, Error → explicar qué pasó, etc.)

• Revisión del copy

  • Agrega revisión de copy al proceso /workflows:review: un agente copy-reviewer que evalúa con 4 criterios: claridad, utilidad, tono y consistencia

Marketing de producto

• Flujo Compound

  • La persona de ingeniería crea un plan con la propuesta de valor del producto → la IA implementa la funcionalidad → la IA genera release notes a partir del plan → a partir de esas release notes genera posts para redes sociales → con Playwright captura screenshots automáticamente → la persona de ingeniería revisa y publica todo junto
  • Como todo fluye en un solo lugar, no hacen falta handoffs y no hay huecos

• Generación de release notes

  • Como la IA tiene el plan, los cambios de código y las pruebas, puede entender exactamente qué se construyó
  • Primero los beneficios para el usuario, incluir 1 ejemplo concreto, mencionar breaking changes y mantenerlo por debajo de 200 palabras

• Generación del changelog

  • Con el comando /changelog, revisa los merges recientes a main y lee cada plan/PR para generar un changelog atractivo

• Screenshots automáticos

  • Usa Playwright para capturar screenshots de marketing automáticamente, sin necesidad de pedir screenshots al equipo de ingeniería, y elimina el problema de los screenshots desactualizados