El ticket ya está escrito. Tiene título, descripción, criterios de aceptación y un hueco en el sprint. Lo único que se interpone entre él y un diff es una persona que abre una terminal, pega el ticket en un agente de programación, observa la ejecución y después copia el resultado a mano en Jira. El trabajo y el registro del trabajo viven en dos ventanas distintas, y mantenerlas sincronizadas se lleva la tarde de alguien.
Asignar un ticket de Jira a un agente de IA consiste en cerrar esa brecha: la incidencia se convierte en una unidad de trabajo que un agente puede tomar, ejecutar contra tu repositorio y devolver como un cambio revisable, sin salir del gestor que tu equipo ya utiliza. No sacas al equipo de Jira. Añades una capa donde el ticket realmente se puede trabajar.
Esa capa es Sharkly, una plataforma todo en uno para comandar y gestionar agentes. Se conecta a Jira, convierte las incidencias en Tareas asignables, las enruta a tus agentes de programación (Claude Code, Codex, Gemini y otras herramientas de línea de comandos), ejecuta cada una de forma aislada y devuelve el resultado a la Tarea. Esta guía recorre todo el ciclo: entra el ticket, se asigna el agente, el trabajo se hace en un worktree aislado y el pull request con su discusión vuelven al registro.
Todo el ciclo en una frase
Una Tarea de Sharkly es el registro compartido de una unidad de trabajo y, al conectar Jira, cada incidencia de Jira se convierte en una de esas Tareas. A partir de ahí el contrato es sencillo: los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, conceden autoridad y aceptan el resultado. El resto de este artículo no es más que la mecánica de esa frase.
Conserva Jira y añade la capa de ejecución
Sharkly no sustituye a Jira. Añade la Tarea compartida y la capa de Computer conectado, ejecución y revisión alrededor del gestor que tu equipo ya usa. Nadie tiene que aprenderse un tablero nuevo ni migrar un backlog para empezar.
Conectas ambos mediante un enlace de sincronización. Abre la integración de Jira, conecta la cuenta (Jira Cloud usa tu host *.atlassian.net, el correo de la cuenta y un token de API de Atlassian; Server y Data Center usan la URL base, el nombre de usuario y un token de acceso personal) y luego empareja un proyecto de Jira con un Espacio de Sharkly. Las correspondencias básicas son las que cabría esperar:
- Una incidencia de Jira se convierte en una Tarea de Sharkly
- Una épica de Jira se convierte en un Proyecto de Sharkly
- El responsable, el estado, los comentarios y los archivos adjuntos se trasladan
Aquí está la decisión honesta. Usa sync cuando quieras que un proyecto activo permanezca conectado, de modo que los cambios fluyan entre Jira y Sharkly a partir de ahora. Usa import cuando quieras copiar incidencias históricas para una migración controlada; la sincronización por sí sola no rellena el pasado de un proyecto. La mayoría de los equipos que empiezan quieren un enlace de sincronización bidireccional sobre un proyecto activo y nada más. La configuración completa, incluido el paso del webhook que un administrador de Jira realiza una sola vez, está en la documentación de Sharkly.
Asigna el ticket a un agente
Una vez vinculado el proyecto, la incidencia aparece como una Tarea en el Espacio. Asignársela a un agente funciona igual que asignársela a un compañero: eliges al agente en lugar de a una persona.
Un agente es mucho más que elegir un modelo. Sus instrucciones, su Runtime, sus repositorios y su configuración de ejecución definen cómo maneja el trabajo, igual que la descripción de un puesto moldea lo que hace una persona recién incorporada. El Runtime es el motor que hay debajo: Claude Code, Codex o el agente de CLI que tu equipo ya use. El uso del modelo sigue canalizándose a través de las suscripciones o claves de API configuradas en esas herramientas, así que tu acceso a los agentes y tu código permanecen en tu propio hardware. Sharkly coordina la asignación; no se hace cargo de tus credenciales.
Si es tu primera ejecución, mantén el alcance reducido y los límites explícitos. Escribir una tarea que un agente pueda ejecutar de verdad es una habilidad en sí misma, y merece la pena dominarla antes de apuntar un agente a algo crítico. Un ticket bien acotado con una definición de terminado clara produce un diff bien acotado; uno vago produce un diff vago.
Ejecución en un worktree aislado
Cuando el agente arranca, la ejecución tiene lugar en un Computer conectado, dentro de su propio worktree aislado. Ese aislamiento es lo que hace que repetir esto sea seguro. Cada ejecución obtiene un directorio de trabajo nuevo, de modo que dos agentes trabajando en dos tickets sobre el mismo repositorio nunca se sobrescriben los archivos ni se pelean por una rama. Es la misma disciplina que aplicarías a mano con git worktrees para agentes de programación con IA, pero resuelta por ti y repetible en todas las Tareas.
Esto es también lo que permite que el flujo de trabajo escale más allá de un solo ticket. En el momento en que el aislamiento es automático, ejecutar varios agentes en paralelo deja de ser un malabarismo, porque lo que suele romperse (el estado compartido en disco) se elimina por diseño. Si eres nuevo en todo este modelo, asignar tu primera tarea a un agente de IA es la vía de entrada más suave antes de conectar Jira.
Devuelve el PR al registro
El trabajo del agente vuelve a la Tarea: la conversación, los registros de ejecución, los bloqueos y el cambio resultante aterrizan todos en un mismo sitio en lugar de dispersarse entre una terminal y un hilo de chat. Cuando el agente abre un pull request, lo conectas a la Tarea escribiendo el ID de la Tarea en el nombre de la rama, en el título del PR o en el cuerpo del PR. La integración de GitHub de Sharkly detecta el ID, vincula el pull request a la Tarea y puede dejar un comentario de enlace de vuelta para que cualquiera que siga el ticket salte directamente al código.
Como el enlace de sincronización con Jira es bidireccional, esa actividad también sigue fluyendo hacia la incidencia original. Quien creó el ticket ve avanzar el trabajo sin abrir ni una sola terminal. Esta es la recompensa de canalizar el trabajo a través de una Tarea compartida en lugar de un prompt privado: el contexto, el progreso, los bloqueos, los resultados y la revisión permanecen visibles desde la petición hasta la entrega.
El límite honesto: una persona acepta
Nada se fusiona por sí solo. Es deliberado y conviene decirlo con claridad, porque quien lea esto podría suponer lo contrario: fusionar un pull request no cambia el estado de la Tarea y nunca ocurre de forma automática. La automatización se detiene allí donde se requiere el criterio del equipo.
El reparto de tareas se mantiene hasta el final. El agente ejecuta el trabajo, abre el PR e informa de lo que hizo, de lo que verificó y de dónde no está seguro. Una persona lee el diff comparándolo con los criterios de aceptación originales, solicita cambios o acepta, y toma la decisión sobre la fusión y la entrega. Un agente llenará encantado el silencio con iniciativa propia, así que el paso de revisión no es una ceremonia: es el control que hace que valga la pena confiar en la parte automática. Las decisiones finales de aceptación y entrega siguen siendo de las personas.
Ese es el ciclo completo. Entra un ticket de Jira, un agente lo toma, el trabajo se ejecuta de forma aislada y vuelve al registro como un pull request que puedes leer, y tú decides si se publica. Para una visión más amplia de cómo encaja esto en un equipo de agentes y no en una sola ejecución, consulta qué significa la orquestación de agentes de IA para los equipos de desarrollo, o el resumen de Sharkly para ver toda la plataforma.
Para probarlo con un ticket real: descarga Sharkly, inicia sesión en app.sharkly.ai, conecta un Computer y vincula un proyecto de Jira de bajo riesgo.
Preguntas frecuentes
¿Sharkly sustituye a Jira? No. Sharkly añade la capa de ejecución y revisión alrededor de Jira. Tus incidencias, épicas, estados y flujos de trabajo se quedan donde están; el enlace de sincronización los mantiene conectados mientras los agentes hacen avanzar el trabajo.
¿Qué versiones de Jira funcionan? Ambas. Jira Cloud se conecta con tu host, el correo de la cuenta y un token de API de Atlassian. Jira Server y Data Center se conectan con la URL base, el nombre de usuario y un token de acceso personal.
¿Tengo que migrar mi backlog primero? No. Un enlace de sincronización conecta un proyecto activo y mantiene fluyendo los cambios futuros sin importar el historial. Realiza una importación aparte solo cuando quieras copiar específicamente incidencias pasadas.
¿Fusionar el pull request cerrará el ticket? No. Fusionar un PR no cambia el estado de la Tarea, por diseño. Una persona acepta el resultado y decide el paso de fusión y entrega. Consulta asignar tu primera tarea a un agente de IA para ver cómo funciona el ciclo de revisión.
¿Dónde viven mi código y mi acceso a los modelos? En tu propio hardware. Los agentes se ejecutan en un Computer que tú conectas, usando las suscripciones o claves de API que ya tengas configuradas en tus herramientas de programación. Sharkly coordina la asignación, el contexto y la revisión; no aloja tu repositorio ni tu cuota de modelos.
