Un agente de programación capaz de abrir un pull request es útil. Un agente de programación capaz de fusionarlo mientras nadie mira es un riesgo con permisos de commit. La distancia entre esas dos frases es todo el problema. En cuanto un agente puede hacer push a una rama, ejecutar tests y pulsar fusionar, la pregunta deja de ser «¿puede hacer el trabajo?» y pasa a ser «¿dónde termina su autoridad?».
La mayoría de los equipos responde a esa pregunta por accidente. El agente tiene los permisos que le haya dado su entorno de ejecución, la revisión ocurre en el terminal en el que se lanzó la ejecución y el registro de quién aprobó qué vive en el scrollback de una sola persona. Eso aguanta hasta que tienes tres agentes repartidos entre dos repositorios y un despliegue de viernes publica algo que nadie leyó. La solución es una puerta de aprobación, pero solo si es un punto de control real dentro de un sistema compartido y no una costumbre que esperas que todo el mundo mantenga.
Ese sistema compartido es lo que ofrece Sharkly. Ya tienes agentes de programación; Sharkly convierte sus ejecuciones en Tareas con estados, Asignados y un paso de revisión que una persona debe completar a propósito. Este artículo repasa el modelo operativo que hay detrás: quién asigna el trabajo, quién lo ejecuta, quién lo revisa, quién lo acepta y exactamente en qué punto debe estar la parada para que un agente nunca fusione su propio cambio sin revisión.
Qué es realmente una puerta de aprobación
Una puerta de aprobación es un punto en el ciclo de vida de una tarea en el que la ejecución automatizada se detiene y espera a que una persona decida el siguiente paso. No es un aviso ni una línea de log que puedes pasar de largo con el scroll: es un estado en el que el trabajo permanece hasta que un humano lo mueve.
La distinción que más importa es la que hay entre que un agente proponga un cambio y que lo integre. Abrir un pull request es una propuesta. Fusionarlo es una decisión sobre producción. Son actos de autoridad distintos, y en el segundo es donde debe residir el criterio del equipo. Sharkly hace explícito ese límite: incluso con GitHub conectado, fusionar un pull request no cambia el estado de la Tarea. La fusión sigue siendo una acción humana registrada, no un efecto colateral que el agente desencadena al terminar.
Ten presente ese límite, porque la mayoría de las historias de «el agente rompió producción» son en realidad historias sobre una puerta que faltaba entre la propuesta y la integración.
El modelo operativo: asignar, ejecutar, revisar, aceptar
Sharkly divide una tarea en cuatro roles, cada uno con una única función. El contrato es claro: los Agentes investigan, ejecutan, prueban e informan; las Personas marcan la dirección, otorgan la autoridad y aceptan el resultado.
- Asignar. Una persona describe la necesidad y establece el Asignado. Una Tarea lleva dos asignaciones independientes: las Personas implicadas y un único Asignado de ejecución, que es el Agente o Crew que realiza el trabajo. Cambiar una no cambia la otra.
- Ejecutar. El Asignado de ejecución hace el trabajo en un worktree de git aislado, de modo que las ejecuciones en paralelo no tocan los archivos de las demás. El progreso, los bloqueos y los resultados vuelven a la Tarea.
- Revisar. Cuando el Agente termina, deja la Tarea esperando revisión humana en lugar de cerrarla. El diff, la salida de los tests y el resumen del cambio quedan adjuntos a la Tarea, no a un terminal.
- Aceptar. Una persona lee las evidencias y decide: solicitar cambios, o aceptar y fusionar. La aceptación es el movimiento final, y solo una persona lo realiza.
El valor aquí no está en que Sharkly ejecute al agente, sino en que los cuatro roles permanezcan visibles en un mismo sitio en lugar de diluirse en el terminal que estuviera abierto en ese momento. Para profundizar en la mitad dedicada a la revisión, consulta human-in-the-loop coding agents.
Convierte la puerta en un estado, no en una costumbre
Una puerta que tienes que recordar es una puerta que acabarás saltándote. Así que codifícala en el ciclo de vida de la tarea.
Los estados de Sharkly aportan significado sistémico a través de sus categorías. Backlog es un estado de aparcamiento: una Tarea ahí no se ejecuta ni aunque tenga un Agente asignado. Moverla a una categoría lista para el trabajo es lo que permite que arranque la ejecución. Completed es un estado terminal, y llegar a él es un movimiento humano, no algo que el Agente se conceda a sí mismo.
El estado de la Tarea está deliberadamente separado del estado de trabajo del Agente. Mientras el estado del ciclo de vida marca In Progress, el Agente que hay debajo puede estar trabajando, esperando una respuesta humana, esperando revisión humana o informando de un error. Esa separación es la puerta: el Agente puede terminar su ejecución y mostrar «esperando revisión humana» sin que la Tarea llegue a cruzar nunca a un estado que implique que se ha desplegado. El trabajo vuelve a la Tarea y se detiene ahí hasta que alguien lo acepta.
Esto es también lo que hace seguro ejecutar varios agentes a la vez. Cuando cinco agentes en paralelo en worktrees aislados acaban en la misma columna de revisión, tienes un único sitio donde clasificarlos en lugar de cinco terminales que vigilar.
Un ejemplo práctico: del ticket al PR fusionado
Recorramos una única Tarea de principio a fin, usando el formato de identificador SH-312 de Sharkly.
- Créala. Una persona crea
SH-312, una tarea de bug: «La búsqueda devuelve resultados obsoletos tras cambiar un filtro». La descripción incluye el objetivo, la reproducción del fallo y los criterios de aceptación. Asignado: un Agente de Claude Code vinculado al repositorio de búsqueda. - Dale forma. El Agente investiga el código y el historial relacionado, confirma el alcance y publica su plan en la Tarea. La persona lee el plan y saca
SH-312de Backlog hacia un estado listo, que es la señal para empezar. - Ejecútala. El Agente reclama la Tarea y trabaja en un worktree nuevo. Escribe la corrección, ejecuta el typecheck y la suite de tests, y abre un pull request cuyo título incluye
SH-312para que Sharkly vincule el PR con la Tarea. - Detente en la puerta. El Agente no fusiona. Adjunta el resumen del cambio, la salida de los tests superados y cualquier limitación conocida, y deja
SH-312esperando revisión humana. El trabajo ha vuelto a la Tarea. - Revísala. Una persona abre
SH-312, lee el diff y las evidencias en una sola vista, y se da cuenta de que la corrección tocó un helper de consulta compartido. Deja un comentario pidiendo un cambio más acotado. En una Tarea con un Asignado Agente listo, ese comentario vuelve a encolar la ejecución, de modo que el ciclo de solicitud de cambios queda en el registro en lugar de reiniciarse en un chat privado. - Acepta y fusiona. La segunda ejecución pasa la revisión. La persona aprueba el pull request, lo fusiona y mueve
SH-312a Completed. Como la fusión no cierra la Tarea automáticamente, la aceptación y la fusión son dos decisiones humanas registradas, no una única cascada automática.
Cada paso de esa cadena se puede inspeccionar después, que es justo el objetivo de un flujo de trabajo trazable de requisitos a código: puedes responder «quién aprobó esto y con qué evidencias» sin tener que hacer arqueología en el scrollback de nadie.
Dónde no poner una puerta
Más puertas no son automáticamente más seguras; añaden una fricción que acaba entrenando a la gente para hacer clic sin leer. Pon una puerta donde el coste de una fusión errónea sea real. Para un cambio pequeño, bien definido y de bajo riesgo asignado a un único Agente, la parada de revisión antes de fusionar es suficiente, y no necesitas una Crew ni pasos de aprobación adicionales por encima. Añade una revisión más exigente cuando el radio de impacto sea grande: código compartido, migraciones, cualquier cosa que toque la autenticación o la facturación.
La única puerta que nunca se quita es la de la fusión. Un Agente puede investigar, escribir, probar y proponer todo el día. Que su cambio llegue a tu rama principal es una decisión humana, y debe seguir siéndolo incluso cuando el Agente acierte la mayoría de las veces. Combina la revisión a nivel de tarea de Sharkly con tu protección de ramas actual para que la plataforma haga cumplir lo que pretende el flujo de trabajo, y conserva las herramientas que tu equipo ya usa: conecta GitHub y asigna el ticket a un agente de IA sin rehacer tu proceso.
Si ya estás ejecutando varios agentes de programación y has perdido la cuenta de cuál terminó, cuál falló y cuál te está esperando, esa columna de revisión es la razón para probar Sharkly. Haz pasar tus agentes actuales por ella y deja la decisión de fusión donde corresponde.
Preguntas frecuentes
¿Puede Sharkly impedir que un agente fusione por su cuenta? Sí. Fusionar un pull request no cambia el estado de una Tarea en Sharkly, así que una ejecución termina en «esperando revisión humana» en lugar de integrar un cambio. Combínalo con la protección de ramas de GitHub para exigir revisiones obligatorias a nivel de repositorio.
¿Cuál es la diferencia entre el estado de la tarea y el estado del agente? El estado de la tarea es la categoría del ciclo de vida (Backlog, Started, Completed, etc.). El estado del agente es lo que está haciendo la ejecución en ese momento: trabajar, esperar una respuesta humana, esperar revisión o error. Una Tarea puede quedarse en In Progress mientras el Agente te espera.
¿Necesito una Crew para cada tarea revisada? No. Para trabajos pequeños y bien acotados, asigna la Tarea a un solo Agente y usa la puerta de revisión antes de fusionar. Reserva una Crew para un objetivo que necesite un Agente líder que coordine a varios miembros.
