Cargando

Sesiones paralelas y subagentes

Lección 74 min

Un ingeniero puede impulsar varios flujos de trabajo a la vez.

Una sesión paralela es otra instancia completa de Claude Code, trabajando en una tarea separada en su propio worktree de Git. Cada sesión independiente no sabe nada de las demás, y lo único que comparten es el ingeniero que las dirige.

Un subagente se ejecuta dentro de una sola sesión como un ayudante acotado con su propia ventana de contexto y límites de herramientas, y es adecuado para trabajos que se repiten en varias tareas, como verificar que la aplicación funciona como se espera.

Las sesiones paralelas aumentan el número de tareas que un ingeniero puede tener en curso, mientras que los subagentes mantienen cada sesión enfocada en su propia tarea. El trabajo del ingeniero es dirigir y revisar todas ellas.

Qué cambia

TradicionalNativo de IA
Un ingeniero trabaja en una tarea a la vez y dedica una parte significativa de su día/semana a compilaciones, pruebas y revisiones. Es posible cambiar entre tareas mientras se espera, pero el cambio de contexto es lo bastante agotador como para que pocas personas lo elijan.Un ingeniero ejecuta varias sesiones de Claude a la vez, cada una en su propio worktree en su propia tarea. Los trabajos repetidos se convierten en subagentes con su propio contexto y límites de herramientas. El trabajo del ingeniero pasa a ser orquestar y, eventualmente, construir y monitorear bucles.

Primeros pasos

  • Requisitos previos: El CLAUDE.md, ya que todas las sesiones leen el archivo. El bucle de retroalimentación (Etapa 4: Probar) también ayuda aquí, porque se necesita menos supervisión del ingeniero cuando una sesión puede verificar su propio trabajo.
  • Infraestructura: Un repositorio Git, ya que el aislamiento proviene de los worktrees, y configuraciones de permisos ajustadas para que las sesiones no estén esperando indicaciones de aprobación para comandos que la organización considera seguros.

Cómo ejecutarlo

  1. El ingeniero divide el trabajo en tareas que tocan archivos diferentes, usando el plan de la jugada del modo de planificación (Etapa 3: Construir) para ver dónde el trabajo es independiente. Las tareas que comparten archivos se ejecutan en una sola sesión, una tras otra.
  2. Cada tarea paralela obtiene su propio worktree, por ejemplo claude --worktree feature-auth en una terminal y claude --worktree fix-rate-limit en otra. Un worktree es un checkout separado en su propia rama, lo que evita que las sesiones colisionen en los archivos.
  3. Dos o tres sesiones es un punto de partida razonable. El límite práctico es cuántos flujos puede revisar adecuadamente una persona, así que agrega sesiones solo mientras la revisión pueda seguir el ritmo.
  4. Convierte los trabajos repetidos en subagentes, definidos en archivos Markdown en .claude/agents/, cada uno con un nombre, una descripción de cuándo usarlo y las herramientas que puede tocar. Los ejemplos incluyen un simplificador de código que elimina la complejidad innecesaria después de que el agente principal termina, un verificador que ejecuta la aplicación y comprueba el comportamiento, y un investigador que explora la base de código e informa sin saturar el contexto principal. Registra las definiciones en Git para que todo el equipo las comparta.

Cómo se ve

.claude/agents/verifier.md:

markdown
---

name: verifier
description: Runs the app and checks the change works before the session reports done
tools: Bash, Read

---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

Consideraciones de gobernanza

Más sesiones significa más producción, así que los controles deben provenir de la configuración en el repositorio. Los hooks y las configuraciones de permisos allí se aplican a todas las sesiones, y lo que hace una sesión queda registrado y atribuido al ingeniero que la ejecutó.

Cómo medirlo

  • Indicador adelantado: Sesiones concurrentes por ingeniero mientras se mantiene la calidad de la revisión, contadas a partir de la exportación de OpenTelemetry, y la proporción del día dedicada a dirigir en lugar de esperar.
  • Indicador rezagado: Cambios fusionados por ingeniero por semana, leídos junto con la tasa de retrabajo según se determina a partir del historial de PR.