Agentes en segundo plano y en paralelo
Una vez que confías en un para una tarea delimitada, el siguiente paso es obvio: ejecutar varios a la vez. Las herramientas modernas te permiten lanzar agentes en segundo plano — cada uno en su propia rama o worktree (una copia de trabajo separada del proyecto, para que las ediciones de un agente nunca choquen con las de otro) — de modo que tres o cuatro tareas delimitadas avanzan mientras haces otra cosa.
Esto es una aceleración real, pero solo para trabajo independiente. El costo contra el que estás negociando es la coordinación. Dos agentes editando el mismo archivo producirán diffs en conflicto, y fusionarlos a mano puede costar más de lo que ahorraste.
- Divide por límites, no por número de líneas. Dale a cada agente un trozo que no se superponga con los demás — módulos separados, funcionalidades separadas, archivos separados. "El agente A hace la funcionalidad de exportación, el agente B escribe la documentación" es limpio. "Ambos agentes editan
app.js" es un dolor de cabeza de fusión esperando a suceder. - Aísla los espacios de trabajo. Ejecuta cada agente en su propia rama o worktree de para que no puedan pisarse los cambios sin confirmar del otro. Fusiónalos de vuelta uno a la vez, ejecutando tus verificaciones en cada fusión.
- Mantén el conteo honesto. Sigues teniendo que revisar cada resultado. Cuatro agentes ejecutándose son cuatro diffs por leer y cuatro conjuntos de pruebas en los que confiar. Pasado un puñado, la de revisión — no los agentes — se convierte en tu cuello de botella.
Cada agente trabaja en su propio worktree aislado para que sus ediciones nunca choquen; los fusionas de vuelta uno a la vez, ejecutando verificaciones en cada puerta:
┌─────────────────────────────┐
│ YOU split by boundary │
└──────────────┬──────────────┘
┌────────────────┼────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ AGENT A │ │ AGENT B │ │ AGENT C │
│ worktree-a/ │ │ worktree-b/ │ │ worktree-c/ │
│ export feat │ │ docs │ │ settings page│
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ branch-a │ branch-b │ branch-c
└────────────────┼────────────────┘
▼
┌──────────────────┐
│ MERGE one-by-one │ run checks at each merge
│ → main │
└──────────────────┘
isolated copies = no collisions · review queue is the real limit
El error es tratar el paralelismo como gratuito. No lo es — has movido el trabajo de escribir a revisar e integrar. A menudo un gran intercambio, pero solo si de verdad haces la revisión.