Subagentes de Claude Code: de una idea al merge en Rydger

Respuesta corta: uso los subagentes de Claude Code para implementar stories de Rydger mientras Opus coordina las dependencias. Sonnet hace buena parte del trabajo, Haiku entra en tareas sencillas y Fable sirve de asesor cuando hay una decisión difícil. Lo que me permite apartarme del ordenador durante horas es dejar claro qué puede empezar, desde qué rama y cómo se comprueba el resultado.

En la épica del primer trayecto de Rydger, la story de Android está bloqueada por la de iOS. Una tiene que dejar first-ride-check-cases.json; la otra lo necesita para comprobar la misma regla en Kotlin. Separar las plataformas no las hace independientes.

El ejemplo más claro lo tengo en Rydger, mi app para llevar el mantenimiento y los gastos de la moto o del coche. Nació en iOS y he creado también la versión Android.

Ahora dedico más tiempo a decidir qué tiene que conseguir la app. Sigo entrando en los detalles técnicos, pero ya no quiero ser quien reparte cada fichero a mano.

He podido dejar agentes escribiendo y ejecutando tests, con pruebas de UI en los simuladores de iOS y Android, mientras yo hacía otras cosas. No tengo una medición de horas ahorradas ni una comparativa entre modelos. Lo que sí he ganado es margen para dejar de dirigir cada paso de la implementación.

La especificación me decía qué construir; faltaba decidir para qué

Con OpenSpec primero preparaba la especificación y después la implementaba. Me sigue sirviendo. Lo que me faltaba estaba un paso antes: discutir una idea hasta convertirla en algo que mereciera implementarse.

Ahora empiezo hablando con Opus 5.5. Le voy planteando ideas, discutimos el alcance y acabamos con un objetivo de negocio. De ahí salen las épicas y, dentro de cada épica, las stories, que apruebo antes de ponerlas a trabajar.

No he inventado la gestión de proyectos por tener un terminal abierto. El cambio práctico es que las dependencias que antes interpretaba yo pasan a ser instrucciones que el orquestador puede consultar. Si una story necesita el resultado de otra, esa relación queda escrita en GitHub.

OpenSpec conserva su sitio: la story describe el resultado que alguien podrá usar y sus criterios de aceptación; el tasks.md de OpenSpec mantiene la checklist de ingeniería. Una story que cambia comportamiento enlaza el cambio y las tareas que cubre. No sustituyo una lista por otra ni doy por terminado el objetivo porque las casillas estén marcadas.

Con las skills /epics, /stories y /pickup paso del objetivo a las stories y de ahí a implementarlas. Son instrucciones de mi proyecto, no comandos que aparezcan por instalar Claude Code.

Android tenía que esperar a una fixture de iOS

Una épica real se llama «Activar en la primera salida»: ayudar a quien acaba de configurar los kilómetros automáticos a comprobar que su primer trayecto se ha registrado.

Dentro hay una pareja de stories que explica el sistema mejor que cualquier dibujo de agentes trabajando en paralelo:

La primera crea first-ride-check-cases.json. La siguiente pasa esos casos en Kotlin. El objetivo no era que dos agentes inventaran cada uno qué significa «primer trayecto registrado», sino que las dos plataformas comprobaran la misma regla.

Hay diferencias que no se pueden copiar: iOS tiene una comprobación manual del Atajo; Android tiene sus permisos de Bluetooth y notificaciones. Compartir los casos de la regla no convierte las integraciones de las dos plataformas en iguales.

En GitHub, la story de Android depende expresamente de la de iOS. Lanzarlas a la vez habría obligado a un agente a trabajar contra algo que todavía podía cambiar. Dos tareas para plataformas distintas también pueden tener una dependencia.

Opus coordina; los demás reciben un trabajo acotado

Lanzo el agente principal y después dejo que Claude vaya decidiendo cómo delegar dentro del alcance acordado. Uso Opus como orquestador, Sonnet para implementar y Haiku para cosas más sencillas. Es mi reparto actual, no el resultado de un benchmark.

Primero exploran el código y después implementan la parte asignada. El encargo tiene que incluir el contexto que afecta a esa story; no basta con confiar en que el subagente conozca todo lo que he hablado con el principal. La documentación de subagentes explica su contexto separado y cómo definirlos.

Para las decisiones difíciles tengo .claude/agents/advisor.md, configurado con Fable. Inspecciona el repo y propone una recomendación concreta que el ejecutor lleva a cabo.

Ese asesor tiene una instrucción de solo lectura, pero incluye Bash: la frase «no modifiques» no equivale a quitarle técnicamente toda capacidad de hacerlo.

Tampoco doy permiso para cualquier cosa por arrancar el orquestador. La regla escrita del proyecto reserva los merges al fundador; si le encargo uno a un agente, esa autorización es concreta. Publicar en las tiendas y los pasos marcados como founder-action siguen reservados para mí.

Los worktrees evitan pisarse mientras editan; los conflictos llegan al integrar

Cada implementación va en un worktree diferente. Eso separa los directorios de trabajo, pero no hace desaparecer los cambios incompatibles.

Me ha pasado: los agentes creen que van a tocar cosas diferentes y acaban cambiando algún fichero común. Luego hay que resolver el conflicto al integrar en la rama padre o en la rama de la épica.

No me ha roto el sistema. Es parte del trabajo que sigue existiendo.

Hay un ejemplo más discreto en la PR de Android del primer trayecto. Al regenerar las traducciones desaparecían unas cadenas que otro trabajo había añadido directamente a strings.xml. Hubo que incorporarlas al manifiesto que alimenta el generador.

No era un conflicto de Git: el código se podía integrar y aun así perder contenido en la siguiente generación.

Por eso una asignación necesita una rama base y una explicación de qué artefactos produce. Si usas el aislamiento automático de Claude Code, comprueba también desde qué rama crea el worktree; no des por hecho que será la rama de tu épica. La guía de worktrees cubre el mecanismo; el orden de integración lo tienes que decidir tú.

El test que pasa en una rama aún tiene que sobrevivir al merge

La objeción es inmediata: «Si los agentes escriben el código y sus tests, pueden ponerse de acuerdo en estar equivocados».

Sí. En este caso los criterios de aceptación y la fixture compartida dan una referencia concreta, pero no prueban por sí solos que todos los dispositivos se comporten bien. Cada PR deja constancia de lo que se comprobó.

La de iOS registra un fallo inicial en el test de UI nuevo y una ejecución posterior que pasó tras corregirlo. La de Android registra tests unitarios y una comprobación manual en el emulador; también dice que esa parte no añadió tests instrumentados.

Y la prueba en carretera con el Atajo real sigue siendo una comprobación aparte. No voy a llamar «cobertura automática de extremo a extremo» a esa mezcla.

Mi regla para copiar este flujo es exigir el comando ejecutado, su resultado y lo que quedó sin comprobar. Al integrar, repetir las comprobaciones que pueda afectar la combinación.

Un informe del agente diciendo «todo bien» no sustituye esa evidencia. Es la misma separación entre generar y comprobar que conté en el artículo del harness.

Empieza con una story que otro agente pueda entender

No empezaría desplegando una cuadrilla de subagentes. Cogería una story y le escribiría este encargo, antes de abrir otro contexto:

Resultado visible y criterios de aceptación:
Dependencias y evidencia de que ya están integradas:
Rama base y worktree asignado:
Ficheros o área de responsabilidad; fuente de los generados:
Comprobaciones que debe ejecutar y evidencia que debe devolver:
Decisiones pendientes y condición para parar y consultarme:
Destino de la PR; quién puede aprobar e integrar:

Te dejo el kit descargable, con esa ficha en ambos idiomas, un encargo para el orquestador y un asesor limitado a herramientas de lectura. Es una adaptación para este artículo; no es el repo privado de Rydger ni un scheduler listo para funcionar sin configuración.

Los prompts piden un comportamiento, no lo garantizan.

Empieza con una story y revisa qué ha hecho el agente y cómo lo ha comprobado. Después añade otra independiente. Si ambas necesitan el mismo fichero generado, acabas de encontrar una decisión que conviene resolver antes de darles trabajo en paralelo.

Y mira el consumo: cada subagente cuenta para el límite de uso, aunque su trabajo no termine sirviendo. Elegir Sonnet o Haiku para una parte no demuestra que el flujo completo sea más barato: también cuentan la exploración repetida y los reintentos.

Anthropic lo recoge en su guía de costes. Yo puedo afirmar que he ganado autonomía; todavía no puedo ponerle una cifra de ahorro.

Antes de dejar la próxima sesión trabajando sola, escribe qué resultado te tiene que traer y en qué punto debe parar para preguntarte. Ese es el primer encargo que probaría.

Fuentes

• Anthropic: subagentes personalizados, sesiones paralelas con worktrees y gestión del consumo, consultadas el 21 de octubre de 2026.
• Caso propio: flujo de entrega y skills de Rydger, épica #166, stories #192 y #193 y PR #247 y #250. El repositorio es privado; las comprobaciones de esas PR son evidencia de esas ejecuciones, no una nueva ejecución hecha para este artículo.

Lectura relacionada: las skills con las que organizo mi flujo de código y cómo conecto ese proceso con los loops.

P.D. ¿Qué te ha dado más trabajo al juntar subagentes: repartir las stories o integrar lo que vuelve? Cuéntamelo en Twitter/X.