La primera vez que ejecutas tres agentes de programación a la vez, la ejecución deja de ser la parte lenta. Le pasas un bug a Claude Code, un refactor a Codex y un hueco de cobertura de pruebas a un tercer Runtime, y cuarenta minutos después tienes tres ramas listas. Entonces empieza la espera de verdad, porque los tres están esperándote a ti. Lees el primer diff, lo apruebas y los otros dos se quedan parados. Tienes ejecución en paralelo y revisión en serie, así que el paralelismo casi no te aporta nada.
Esta es la trampa en la que cae cualquier equipo que se vuelve bueno ejecutando agentes en paralelo. El cuello de botella no desaparece: se desplaza, de «qué rápido puede escribir el código un agente» a «qué rápido puede una persona leer, juzgar y aceptar el resultado». Añadir un cuarto agente lo empeora: una cola más larga de trabajo terminado y el mismo revisor de siempre.
La solución no es revisar más rápido ni confiar más, sino diseñar la revisión como una parte explícita del flujo de trabajo en lugar de un añadido que solo vive en tu cabeza. Ese es el flujo que recorre este artículo y el problema en torno al cual está construido Sharkly: mantener el objetivo, el diff, la evidencia y la revisión de cada ejecución de agente en una sola tarea, para que la cola de revisión sea algo que puedes ver y gestionar en lugar de un montón de pestañas abiertas en el navegador.
Por qué los agentes en paralelo desplazan el cuello de botella a la revisión
La revisión es una cola. Las ejecuciones de agente terminadas llegan a un ritmo, una persona las despacha a otro y, si las llegadas superan a los despachos, la cola crece sin límite. Eso es todo, y por eso el rendimiento bruto de los agentes es la métrica equivocada que optimizar. Si diez agentes terminan en una hora y tú puedes aceptar con cuidado tres cambios por hora, has construido una fábrica cuyo muelle de carga es una sola persona con un portapapeles.
La mayoría de las herramientas ocultan esto. Una pila de pull requests te muestra el trabajo, pero no qué elementos esperan de verdad una decisión, cuáles siguen en ejecución y cuáles ya se fusionaron. La cola existe, pero está repartida entre pestañas, notificaciones y la memoria. El primer objetivo de diseño es hacerla visible, porque no puedes gestionar un cuello de botella que no ves. Un artículo complementario sobre el cálculo de la capacidad de revisión desarrolla qué ocurre a medida que sube la concurrencia.
El modelo operativo: quién asigna, quién ejecuta, quién revisa y quién acepta
Antes de tocar los estados, pon nombre a los cuatro roles. Son trabajos distintos, y confundirlos es lo que hace que la revisión se sienta caótica.
Alguien asigna el trabajo: convierte una intención en una tarea acotada con criterios de aceptación. Algo lo ejecuta: un agente, en un Computer, corriendo en un Runtime, que produce un cambio y un registro de lo que hizo. Alguien revisa el resultado: lee el diff y la evidencia y decide si cumple los criterios. Alguien lo acepta: toma la decisión de fusionar y publicar, que es algo distinto de «el código se ve bien».
Sharkly resume el contrato en una frase que merece un post-it: los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, otorgan autoridad y aceptan el resultado. La automatización se detiene donde hace falta el criterio del equipo. Asignar y aceptar son tareas humanas por diseño. Ejecutar es cosa del agente. Revisar es el trabajo que hay que diseñar con ingeniería, porque es donde se forma la cola.
Una distinción útil: un PR fusionado no es lo mismo que un resultado aceptado. Fusionar es una operación de git. Aceptar es que una persona decide que el cambio hace lo que pedía la tarea. Cuando esas dos cosas se reducen a un solo clic, la calidad de la revisión cae a lo que el revisor tuviera energía para hacer ese minuto.
Roles, estados y gates de revisión
Dale forma a la cola definiendo un conjunto pequeño de estados por los que agentes y personas mueven las tareas. Una tarea es la unidad principal de trabajo: contiene el objetivo, la conversación y la ejecución. La utilidad de los estados es que un agente puede hacer avanzar una tarea hasta el mismísimo gate de revisión, pero solo una persona puede cruzarlo.
| Estado | Quién lo mueve hasta aquí | Significado |
|---|---|---|
| Backlog | Persona | Acotada, sin empezar. Aquí no se ejecuta nada. |
| Ready | Persona | Aprobada para ejecutarse; un agente puede tomarla. |
| In progress | Agente | Hay una ejecución en curso en un worktree aislado. |
| Ready for review | Agente | Ejecución terminada, cambio y evidencia adjuntos, esperando a una persona. |
| Changes requested | Persona | Devuelta con un comentario; una ejecución de seguimiento continúa en la misma tarea. |
| Done | Persona | Aceptada, fusionada, publicada. |
El gate es la transición hacia Ready for review y desde ahí hacia Done. Los agentes pueden llegar al gate por sí solos; no pueden cruzarlo. Esa única regla es lo que te permite ejecutar diez agentes con seguridad: llenan en paralelo la columna Ready for review y tú la vacías al ritmo que te permita no bajar la calidad. La longitud de esa columna es tu cuello de botella, hecho visible.
Y aquí va el par de decisiones honestas. Pon un gate a todo cambio que llegue a los usuarios o toque dinero, autenticación, migraciones de datos o API públicas. No pongas gates a spikes desechables, a código generado que vas a regenerar igualmente ni a trabajo escondido tras un flag al que todavía no llega nadie. Poner un gate a todo devuelve el cuello de botella al revisor por cambios que nunca necesitaron a una persona. El artículo sobre gates de aprobación explica dónde poner el freno en el trabajo de mayor riesgo.
Diseña la revisión para que escale
Revisar el resultado de agentes en paralelo no es lo mismo que revisar el PR de un compañero. Tienes más cantidad, llega a ráfagas y a menudo sabes menos sobre cómo se hizo. Tres movimientos mantienen bajo el coste por elemento para el revisor.
Adjunta la evidencia a la tarea, no a tu memoria. Una ejecución debería devolver el resumen del cambio, la salida del typecheck y de las pruebas, el resultado del build y los límites conocidos, todo registrado. Cuando abres un elemento en Ready for review, estás leyendo un expediente, no reconstruyendo lo que pasó. Esa es la diferencia entre revisar con evidencia a nivel de tarea y volver a ejecutarlo todo tú mismo para recuperar la confianza.
Revisa la decisión, no las pulsaciones de teclas. Lo que una máquina puede comprobar —formato, seguridad de tipos, si pasan las pruebas— debería pasar por un gate automático antes de que la tarea llegue a ti. La guía de revisión de código de Google hace la misma distinción: automatiza lo que una herramienta puede verificar para que la persona dedique su atención al diseño y a la idoneidad. Tu juicio, que es un recurso escaso, se reserva para «¿es este el cambio correcto?», no para «¿compiló?».
Pon un límite al trabajo en curso. Un tope estricto a cuántas tareas pueden estar a la vez en In progress evita que la columna Ready for review se convierta en un muro que nunca vas a poder escalar. Es la idea del límite de WIP del kanban aplicada a los agentes: lanzar una sexta ejecución cuando ya tienes cinco esperándote no añade capacidad, solo esconde la cola. También ayuda monitorizar los agentes en ejecución para distinguir una ejecución atascada de una lenta antes de que llegue al gate.
Un ejemplo práctico, del ticket al PR fusionado
Tomemos una tarea realista, SH-312: «limitar la tasa de peticiones del endpoint público de búsqueda». Una persona la define en Backlog con criterios de aceptación (429 tras N peticiones por minuto y por clave, cabecera documentada, una prueba) y la mueve a Ready.
Tres agentes trabajan en el Space en paralelo. Uno toma SH-312, clona el repositorio configurado en un Computer y se ejecuta en un worktree aislado para que su rama nunca choque con las otras dos ejecuciones en curso. Escribe el limitador, añade una prueba, ejecuta el typecheck y la suite, abre un PR cuyo título incluye el ID de la tarea y mueve SH-312 a Ready for review con el resumen del cambio, la salida de las pruebas que pasan y un límite conocido anotado: el contador es en proceso, no se comparte entre instancias.
Abres la tarea, no quince pestañas. La evidencia está ahí mismo, y la nota sobre el límite conocido es la parte útil: las pruebas pasan, pero el estado compartido entre instancias es una decisión de diseño que tienes que tomar tú. Dejas un comentario y la mueves a Changes requested. Ese comentario arranca una ejecución de seguimiento en la misma tarea; el agente cambia el contador a un almacén compartido y devuelve la evidencia actualizada. Esta vez la aceptas. Mover SH-312 a Done es tu decisión, registrada como un cambio de estado con tu nombre, no como un efecto secundario silencioso de un merge de git.
Mientras tanto, los otros dos agentes están en Ready for review. Como la cola es una columna y no tu bandeja de entrada, los despachas a continuación, en orden y sin perder el hilo.
La frontera que mantienes para las personas
Los agentes en paralelo son un relato de capacidad hasta que la revisión se convierte en la restricción; a partir de ahí, son un relato de colas. Los equipos que sacan valor de muchos agentes tratan la revisión como infraestructura diseñada: estados explícitos, un gate al que los agentes llegan pero no cruzan, evidencia en la tarea, comprobaciones automáticas antes que humanas y un límite a cuánto puede estar en vuelo.
Puedes montarlo a mano con worktrees, una convención para nombrar ramas y disciplina. O puedes dejar que Sharkly gestione el flujo: Agentes asignables, tareas que llevan consigo la ejecución y su evidencia, y un tablero donde Ready for review es una columna que vas vaciando, de modo que los agentes investigan, ejecutan, prueban e informan mientras las personas se quedan con la última decisión. Si ya ejecutas varios agentes, ese es un único lugar donde gestionar sus tareas y resultados en vez de fiarlo todo a la memoria.
Preguntas frecuentes
¿Ejecutar agentes en paralelo ahorra tiempo si la revisión es en serie? Solo hasta el punto en que las ejecuciones terminadas llegan más rápido de lo que puedes aceptarlas. A partir de ahí, los agentes extra hacen crecer la cola de revisión sin entregar nada antes. La ganancia viene de hacer visible la revisión y de poner gates solo a lo que necesita a una persona.
¿Todo cambio de un agente debería pasar por revisión humana? No. Pon un gate a los cambios que llegan a los usuarios o tocan autenticación, datos, dinero o API públicas. Deja pasar el trabajo de bajo riesgo o regenerable solo con comprobaciones automáticas. Poner un gate a todo devuelve el cuello de botella al revisor por cambios que nunca lo necesitaron.
¿No es fusionar el PR lo mismo que aceptar el trabajo? No. Fusionar es una operación de git; aceptar es que una persona decide que el cambio cumple los criterios de la tarea. Mantener ambas cosas separadas preserva la calidad de la revisión cuando el volumen es alto. Consulta agentes de programación con human-in-the-loop para saber dónde mantener la decisión humana.
