Un agente de programación puede convertir un ticket en un pull request mientras te tomas un café. Esa velocidad plantea una pregunta más silenciosa que las herramientas nunca responden por ti: una vez que el diff existe, ¿de quién es la responsabilidad? No de quién lo escribió, eso ya lo hizo el agente. Sino quién responde por si se publica, por si era el cambio correcto y por lo que ocurre cuando falla a las 2 de la mañana. La ejecución pasó al agente. La responsabilidad no, y no puede hacerlo.
La confusión se agrava en cuanto ejecutas más de un agente. Asigna un bug a Claude Code y otro a Codex, y ahora tienes dos ramas, dos resúmenes y ninguna respuesta compartida a una pregunta sencilla: ¿qué nombre figura en cada uno de ellos cuando se integran? La responsabilidad que vive en el historial de una terminal no es responsabilidad. Es una suposición que sobrevive hasta el siguiente git log.
Ese es el problema en torno al que se ha construido Sharkly. Sharkly se sitúa por encima de tus agentes de programación como la capa que registra quién asignó el trabajo, qué agente lo ejecutó, quién revisa el resultado y quién lo acepta. Este artículo presenta ese modelo operativo como cuatro roles y un conjunto de estados, y después recorre un ticket desde la asignación hasta un PR fusionado. Para conocer la mecánica de revisión que hay debajo, nuestra guía sobre agentes de programación con human-in-the-loop cubre las cinco puertas que hacen cumplir estas decisiones.
TL;DR
Que el trabajo de los agentes tenga un responsable humano significa que la responsabilidad sobre un cambio nunca se transfiere al agente, aunque la ejecución sí lo haga. El modelo operativo tiene cuatro roles: una persona asigna, un Agente ejecuta, una persona designada revisa y esa misma persona acepta. Los agentes pueden llevar una Tarea hasta Lista para revisión; solo una persona la mueve a Hecha. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan el rumbo, conceden la autoridad y aceptan el resultado.
Quién es el responsable del trabajo que produce un agente
La responsabilidad y la ejecución son dos trabajos distintos, y confundirlos es el error de raíz. La ejecución consiste en producir el cambio: leer el código base, editar archivos, ejecutar pruebas y abrir un PR. Un agente lo hace bien y rápido. La responsabilidad consiste en responder por el resultado: que el cambio mereciera la pena, que cumpla los criterios de aceptación y que dentro de tres meses haya alguien a quien preguntar por él. Esa capacidad de responder sigue recayendo en una persona, porque a un agente no se le puede pedir que justifique una decisión de compromiso a posteriori ni que cargue con las consecuencias.
La forma más clara de expresar esta división es el contrato humano-agente: los agentes investigan, ejecutan, prueban e informan; las personas marcan el rumbo, conceden la autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo. Todo lo que hay hasta «aceptar el resultado» se puede delegar en un agente. La aceptación en sí no, y la decisión de publicar tampoco. Nuestro artículo sobre asistentes de IA frente a compañeros de equipo de IA traza la misma línea desde la dirección opuesta.
El modelo operativo: asignar, ejecutar, revisar, aceptar
Cuando separas la responsabilidad de la ejecución, el flujo de trabajo se divide en cuatro roles, cada uno con una única función. Ponerles nombre es lo que evita que cinco agentes en paralelo se conviertan en cinco ramas huérfanas.
| Paso | Quién actúa | De qué responde |
|---|---|---|
| Asignar | Una persona | Decidir que el trabajo merece la pena, escribir los criterios de aceptación y designar quién responde |
| Ejecutar | Un Agente, a través de un Runtime en un Equipo | Producir el cambio, ejecutar las pruebas e informar de lo que hizo y de lo que es incierto |
| Revisar | El Asignado humano | Evaluar el resultado frente a los criterios de aceptación y las evidencias |
| Aceptar | El mismo Asignado humano | La decisión de fusionar y publicar |
El detalle importante está en la primera y la última fila: la misma persona es responsable de la asignación y de la aceptación. Así es como se cierra el ciclo. Quien decidió que el trabajo merecía la pena es quien confirma que se hizo. Sharkly lo respalda manteniendo dos casillas de asignación a la vez en una Tarea, un Asignado humano y un asignado Agente, de modo que la responsabilidad y la ejecución quedan registradas como hechos separados en lugar de como un ambiguo «asignado a». Para saber cómo llega el trabajo al agente, consulta nuestra guía sobre asignar, hacer seguimiento y revisar el trabajo de los agentes en un solo lugar.
Estados y puertas: los agentes llegan a Lista para revisión, las personas mueven el trabajo a Hecha
El modelo operativo se vuelve real cuando se plasma en los estados de las Tareas, porque un cambio de estado es una decisión que puedes señalar más adelante. Aquí la regla es estricta y merece decirse sin rodeos: los agentes pueden hacer avanzar el trabajo hasta Lista para revisión; solo una persona mueve una Tarea a Hecha.
| Categoría de estado | Quién lo mueve | Significado |
|---|---|---|
| Backlog | Persona | Sin empezar. Asignar un Agente aquí no ejecuta nada |
| Lista para trabajar | Persona | Mover una Tarea a esta categoría es lo que inicia la ejecución del Agente |
| En curso | Agente | La ejecución se está llevando a cabo en un worktree aislado |
| Lista para revisión | Agente | La ejecución ha terminado y espera a la persona designada |
| Hecha / Aceptada | Persona | Una persona leyó las evidencias y aceptó el resultado |
Dos límites protegen esto. En primer lugar, un Agente no puede seleccionar un estado que su Flujo de trabajo de Tareas no le conceda, así que no puede marcar su propio trabajo como aceptado. Deja la Tarea esperando revisión humana, y esa señal llega a la Bandeja de entrada de la persona responsable en lugar de a un canal que nadie lee. En segundo lugar, fusionar un pull request vinculado no cambia el estado de la Tarea. Una fusión es un evento de Git, no una decisión de aceptación, y Sharkly los mantiene separados para que «se fusionó el PR» nunca se confunda con «una persona consideró que esto era correcto». Si te preocupa la capacidad de revisión, nuestro análisis sobre por qué la revisión humana es el verdadero cuello de botella explica cómo diseñar para ello.
De ticket a PR fusionado: un ejemplo práctico
Veamos el modelo funcionando de principio a fin en una sola Tarea, SH-312, «Añadir rate limiting al endpoint público de búsqueda».
- Asignar. Una ingeniera redacta la Tarea: el endpoint, el límite objetivo y los criterios de aceptación (429 al superar el límite, que las pruebas existentes sigan pasando y una prueba nueva para el límite). Se establece a sí misma como Asignada humana y elige el asignado Agente. La Tarea se queda en Backlog. Todavía no se ejecuta nada.
- Ejecutar. Mueve
SH-312a un estado Lista para trabajar. Ese cambio de estado inicia la ejecución. El Agente reclama la Tarea, prepara un worktree nuevo para que este trabajo no choque con nada más, lee la descripción y los comentarios recientes, edita el endpoint, añade la prueba y ejecuta la batería de pruebas. - Informar. El Agente abre un pull request y publica un comentario en la Tarea: el resumen del cambio, las pruebas que ejecutó y sus resultados, y una nota honesta de que no hizo pruebas de carga del límite con tráfico real. Mueve
SH-312a Lista para revisión. Ahí se detiene. No puede ir más allá. - Revisar. La señal de espera de revisión llega a la Bandeja de entrada de la ingeniera. Lee en orden: los criterios de aceptación, el comentario del Agente, el registro de ejecución y, por último, el diff. El registro muestra por qué se puso en cola la ejecución y qué llamadas a herramientas hizo, así que está revisando el cambio y no un relato sobre él. La carencia de pruebas de carga es real, así que comenta pidiendo una prueba en el techo documentado. Ese comentario pone en cola una ejecución de seguimiento para el mismo Agente; no abre una segunda Tarea.
- Aceptar. El Agente añade la prueba, informa de nuevo y devuelve la Tarea a Lista para revisión. Esta vez las evidencias coinciden con los criterios. Fusiona el PR y mueve
SH-312a Hecha: dos actos deliberados de la persona que fue responsable del trabajo desde el principio.
Cada paso vuelve a la Tarea: la ejecución, el enlace al PR, los comentarios de revisión, la aceptación. Nada vive únicamente en una terminal. Nuestra guía sobre revisar código generado por IA con evidencias a nivel de tarea profundiza en qué leer antes de aceptar.
Dónde se rompe la responsabilidad sin que nos demos cuenta
No necesitas todo este ceremonial en cada Tarea, y fingir lo contrario convierte la revisión en teatro. Usa la versión ligera cuando el trabajo sea de solo lectura o trivialmente reversible: una auditoría de repositorio o una actualización de dependencias con las pruebas en verde pueden pasar directamente de la ejecución a una aceptación rápida. Usa el ciclo completo de cuatro roles, con una persona designada en ambos extremos, siempre que un cambio toque datos, altere una interfaz pública o no se pueda deshacer con un solo comando.
El modo de fallo al que hay que estar atento no es que los agentes hagan demasiado. Es que la responsabilidad quede sin asignar. Una Tarea con un asignado Agente y ningún Asignado humano tiene ejecución sin responsabilidad: el problema de la rama huérfana disfrazado de progreso. La solución es una única regla en todas partes: toda Tarea de Agente nombra a una persona responsable de ella. Cuando coordinas traspasos entre varios agentes, nuestra guía sobre patrones de traspaso de agente a agente y de agente a persona muestra dónde se sitúa el responsable humano en la cadena.
Conclusión
Que el trabajo de los agentes tenga un responsable humano no es un freno a la automatización. Es lo que hace que la automatización se pueda escalar con seguridad. Deja que los agentes hagan la ejecución, toda ella, a la velocidad que puedan. Mantén cuatro decisiones en manos de las personas: qué asignar, si conceder la autoridad para ejecutar, si el resultado cumple el listón y si publicarlo. Deja constancia de esas decisiones como cambios de estado en una Tarea compartida, para que la responsabilidad sea un hecho que cualquiera pueda leer y no una suposición en el historial de alguien.
Si ya ejecutas varios agentes de programación, Sharkly te ofrece un único lugar donde asignar su trabajo, verlo ejecutarse y registrar quién revisó y aceptó cada resultado. Puedes montar este modelo a mano con worktrees y una hoja de cálculo, o descargar Sharkly y dejar que la Tarea lo sostenga. Para conocer la forma completa de esta capa, empieza por la gestión de agentes de programación por encima de Claude Code y Codex.
Preguntas frecuentes
¿Que haya un responsable humano significa que una persona observa cada ejecución de un agente? No. La responsabilidad es rendir cuentas, no supervisar. Una persona asigna el trabajo y acepta el resultado; el agente se ejecuta sin supervisión en el intervalo. De todos modos, mirar una terminal no escala más allá de un agente.
¿Puede un agente marcar su propio trabajo como hecho? No. Un Agente puede hacer avanzar una Tarea hasta Lista para revisión, pero su Flujo de trabajo de Tareas no le concede el estado de aceptada. Una persona lee las evidencias y mueve la Tarea a Hecha.
¿Fusionar el pull request equivale a aceptar la tarea? No. Fusionar un PR vinculado es un evento de Git y no cambia el estado de la Tarea en Sharkly. La aceptación es un cambio de estado independiente que realiza el responsable humano tras la revisión.
¿Quién debería ser el responsable de la tarea de un agente? La persona que decidió que el trabajo merecía la pena. Sharkly mantiene una casilla de Asignado humano junto a la de asignado Agente, de modo que la señal de revisión se dirige a esa persona y es ella quien acepta.
¿Qué pasa si no se asigna a ninguna persona? Obtienes ejecución sin responsabilidad. La regla segura es que toda Tarea de Agente nombre a un responsable humano, de modo que una ejecución terminada siempre tenga a alguien que responda por ella.
