Dejamos Jira: agentes de IA y un tasks.md que se rellena solo

El último ticket que abrimos en nuestro Jira para un proyecto propio es de febrero. Nadie decidió en una reunión dejar de usarlo. Pasó solo: cada vez que alguien escribía un ticket, acababa escribiendo lo mismo en el prompt del agente, y el ticket no lo volvía a leer nadie. Al cabo de unas semanas la gente dejó de escribir la primera versión.

Hoy el trabajo de cada proyecto se lleva en un fichero de texto, tasks.md, que vive dentro del propio proyecto y que los agentes van rellenando mientras trabajan. Nos funciona mejor que Jira en casi todo. En una cosa funciona peor, y es la que más nos duele: saber qué está haciendo cada uno.

Este texto tiene opinión. Creo que Jira, y casi cualquier tracker de tickets, está pensado para repartir horas de programador, que durante veinte años fueron lo más caro de un proyecto. Con agentes, escribir el código cuesta minutos u horas. Lo caro ahora es saber qué quieres y comprobar que lo que ha vuelto está bien, y un tablero de tickets no ayuda con ninguna de las dos cosas.

También es un texto a medias. Llevamos ocho meses con este sistema, lo hemos cambiado cuatro veces y lo vamos a cambiar más. Cuento lo que nos ha salido bien, lo que nos ha salido mal y lo que todavía no sabemos resolver.

Una advertencia antes de empezar: somos una agencia, y una parte de lo que vendemos son horas de desarrollo. Si estimar en horas deja de tener sentido, nos afecta a nosotros antes que a nadie.

Para qué servía Jira

Quítale las integraciones, los colores y los campos personalizados, y a Jira le quedan cuatro funciones:

1. Una cola: qué hay que hacer y en qué orden.
2. Un reparto: quién hace cada cosa.
3. Una estimación: cuánto va a costar, en horas o en puntos, para saber qué cabe en un sprint.
4. Un estado: en qué punto está cada cosa, para que quien no está programando lo sepa sin preguntar.

Las cuatro giran alrededor de un mismo recurso escaso: el tiempo de una persona que sabe programar. El sprint existe porque ese tiempo se acaba cada dos semanas. Los puntos existen porque hay que repartirlo antes de gastarlo. Las columnas “En curso” y “En revisión” existen porque una tarea podía pasar días en cada una.

Durante años trabajamos así, y funcionaba. Teníamos refinamientos los lunes, planning cada dos semanas, una retro que a veces se saltaba y un tablero por proyecto. El tablero era la forma de que el cliente, el jefe de proyecto y el equipo vieran lo mismo.

Qué cambió con los agentes

Lo primero que notamos fue que las estimaciones dejaron de cuadrar, y no porque fuesen malas. Una tarea de tres puntos, que antes era un día y medio de trabajo, se hacía en una tarde. Una de cinco, en un día. Las de ocho seguían costando lo mismo o más, porque ahí lo difícil nunca fue teclear: era entender qué había que hacer.

Durante un par de meses intentamos recalibrar los puntos. No funcionó. Lo que tardaba una tarea ya no dependía de su tamaño, dependía de lo bien que estuviera explicada. Una tarea grande pero clara salía en una mañana. Una pequeña pero ambigua podía comerse dos días de ida y vuelta, porque el agente hacía con mucha seguridad algo que no era lo que queríamos, había que explicarlo otra vez, y volvía a hacer otra cosa.

Ahí entendimos que habíamos movido el cuello de botella. Antes el trabajo se atascaba en “quién tiene tiempo para hacer esto”. Ahora se atasca en dos sitios:

• Antes de empezar: escribir bien qué quieres. No en un ticket de dos líneas, sino con el contexto, las restricciones, lo que no hay que tocar y cómo vas a saber que está bien.
• Al terminar: revisar lo que ha hecho el agente. Leer el cambio, probarlo, entender si ha roto algo que no se ve.

Jira no tiene una columna para ninguna de las dos. Tiene “Por hacer”, “En curso” y “Hecho”, y la mayor parte del esfuerzo ya no está en “En curso”.

La otra cosa que cambió fue el tiempo que pasaba una tarea en cada estado. Si una tarea está “En curso” durante cuarenta minutos, moverla en el tablero cuesta casi lo mismo que hacerla. La gente dejó de moverla. El tablero empezó a mentir. Y un tablero que miente es peor que no tener tablero, porque alguien lo mira y se lo cree.

El tasks.md

La alternativa salió de un proyecto pequeño, casi por accidente. Un desarrollador del equipo empezó a dejarle al agente una lista de pendientes en un fichero de texto en la raíz del proyecto, para no tener que explicarle el contexto cada mañana. Al cabo de una semana el agente ya actualizaba esa lista él solo: marcaba lo que terminaba, añadía lo que se encontraba por el camino y anotaba por qué dejaba algo a medias.

Lo copiamos en el resto de proyectos. Hoy todos tienen uno, y se parece a esto:

# Tareas

## En curso
- [ ] Exportación de pedidos a CSV con filtro por tienda (Laura, desde 14-oct)
  - Falta: probar con más de 10.000 filas
- [ ] Cambio de pasarela de pago a la nueva API (Dani, desde 15-oct)

## Pendiente
- [ ] El buscador ignora tildes ("gestion" no encuentra "gestión")
- [ ] Revisar textos legales de la página de checkout (espera respuesta del cliente)

## Hecho
- [x] Login con enlace mágico por email (Laura, 13-oct)
  - Se quitó el login con contraseña en móvil a petición del cliente
- [x] Corregido el cálculo del IVA en devoluciones parciales (Dani, 11-oct)

Las reglas son pocas:

• El agente lo lee al empezar cualquier sesión. Así sabe qué hay abierto, quién lo lleva y qué se decidió antes, sin que nadie se lo cuente.
• El agente lo actualiza al terminar. Mueve lo que ha hecho a “Hecho”, con una línea de qué ha cambiado y, si hace falta, por qué. Si ha encontrado algo roto que no le tocaba arreglar, lo añade a “Pendiente”.
• Las personas lo leen y lo corrigen. Si una prioridad cambia, se mueve la línea a mano. Nadie tiene que “mover tarjetas” para que el estado esté al día, porque el estado lo escribe quien hace el trabajo.
• Todo lo que no cabe en una línea va en otro sitio. Las decisiones de diseño y las reglas del proyecto viven en un fichero aparte que el agente también lee. El tasks.md es solo la lista.

Comparado con Jira, gana en tres cosas. Vive con el código, así que se guarda, se versiona y se recupera junto a él. Lo lee el agente sin integraciones, sin permisos y sin conectores, porque es texto. Y una persona lo lee entero en treinta segundos, que es más de lo que se puede decir de un tablero con ciento veinte tarjetas.

Pierde en otras, y las cuento más abajo.

Lo que ha salido bien

El cambio que salió de la reunión

En primavera teníamos una reunión de seguimiento con un cliente del sector de la distribución. A mitad de reunión, el director de operaciones dijo que el informe de pedidos que les habíamos entregado servía, pero que lo que necesitaban de verdad era verlo por tienda y poder descargarlo para pasárselo a cada encargado.

Con nuestro proceso anterior, eso habría sido un ticket, un refinamiento el lunes siguiente, una estimación y, con suerte, entrar en el sprint de la semana después. Dos semanas, siendo optimistas.

La desarrolladora que estaba en la reunión lo apuntó en el tasks.md mientras hablaban, con las palabras del cliente. Al salir abrió una sesión con el agente. A las cinco de la tarde le mandamos un enlace al entorno de pruebas con el filtro por tienda y la descarga. La respuesta del director fue un audio de WhatsApp que todavía nos ponemos de vez en cuando.

El agente hizo su parte, pero lo que ahorró las dos semanas fue que entre la petición y el código no había nada más: ni ticket, ni cola, ni planning. Lo único que hacía falta era entender bien qué pedía el cliente, y eso ya lo teníamos porque estábamos en la reunión.

El MVP que salió antes de tiempo

Para una startup habíamos planificado un primer producto en seis semanas: alta de usuarios, un panel con tres vistas, pagos y notificaciones. Salió en dos y media.

Lo que más pesó fue que, al no tener sprints, el cliente veía avances cada día y corregía cada día. Cuando en la segunda semana se dio cuenta de que una de las tres vistas del panel no la iba a usar nadie, la quitamos esa misma tarde. En un sprint de dos semanas ese cambio habría llegado tarde, con la vista ya construida y probada.

La fundadora nos dijo después que era el primer proveedor con el que no sentía que estaba esperando.

El cliente que dejó de pedir el informe semanal

A varios clientes les mandábamos un informe semanal de estado. Lo escribía el jefe de proyecto los viernes, a partir del tablero de Jira, y costaba una hora larga.

Un cliente nos preguntó si podía ver directamente “esa lista que usáis”. Le dimos acceso de lectura al tasks.md. Dos semanas después nos pidió que dejásemos de mandarle el informe: prefería mirar la lista cuando le apetecía, y ahí estaba todo lo que necesitaba saber. Dicho por él, se enteraba mejor en el fichero que en el informe, porque cada línea la había escrito quien había hecho el trabajo.

No todos los clientes lo quieren así, y está bien. Pero ninguno nos ha pedido volver al tablero.

La incorporación de un día

Cuando alguien se incorpora a un proyecto a mitad de camino, lo normal es que pase dos o tres días leyendo tickets, preguntando y entendiendo qué está a medias. Este verano entró un desarrollador nuevo a un proyecto que llevaba cuatro meses en marcha. Le pidió al agente que leyese el tasks.md y el fichero de reglas y le explicase el estado del proyecto. Esa misma mañana cerró su primera tarea.

Menos reuniones

Dejamos de hacer planning y refinamiento. Seguimos hablando, pero de otra forma: diez minutos por la mañana para decir qué va a tocar cada uno, y conversaciones cortas cuando hace falta decidir algo. Al cabo de un mes, la gente del equipo contaba que tenía las tardes enteras para trabajar sin interrupciones, y eso se notaba en lo que salía.

Lo que ha salido mal

Dos personas, la misma tarea

Un martes, dos desarrolladores arreglaron el mismo error a la vez. El cliente lo había reportado por dos canales distintos, uno lo vio en el correo y otro en el chat del proyecto, y cada uno se lo pasó a su agente. Ninguno de los dos miró el tasks.md antes de empezar, y los agentes tampoco, porque la tarea no estaba apuntada todavía. Nos dimos cuenta al revisar: dos arreglos distintos para lo mismo, los dos razonables y los dos incompatibles entre sí.

Perdimos una tarde. No es mucho, pero es exactamente el tipo de cosa que un tablero con responsable asignado evita, y nosotros lo habíamos quitado.

”En curso” durante nueve días

En otro proyecto, una tarea estuvo marcada como “En curso” durante nueve días. La persona que la llevaba había pasado a otro proyecto urgente y no la movió. Los agentes, cada vez que leían el fichero, asumían que alguien estaba con ella y no la tocaban. Lo descubrimos cuando el cliente preguntó por esa funcionalidad.

Un fichero que se rellena solo se rellena con lo que el agente sabe. Lo que pasa fuera de la sesión (alguien cambia de proyecto, un cliente cambia de idea por teléfono) no llega al fichero si una persona no lo escribe.

El agente que dio por terminado algo a medias

El tasks.md lo actualiza el agente, y el agente a veces es optimista. Hemos tenido tareas marcadas como hechas que lo estaban a medias: la exportación funcionaba, pero no con los datos reales del cliente; el formulario se enviaba, pero el correo de confirmación no salía. El fichero decía “Hecho” con la misma seguridad en los dos casos.

Desde entonces, una tarea no está hecha porque el agente lo diga. Está hecha cuando una persona la ha revisado, y el agente no puede marcar esa casilla.

”¿Qué estáis haciendo ahora?”

Esta es la que más nos ha costado. Un cliente llamó un jueves y preguntó, con toda la razón, en qué estábamos trabajando esa semana. El jefe de proyecto no lo sabía con certeza. Había dos personas en el proyecto, cada una con dos o tres sesiones de agente abiertas, y el tasks.md reflejaba lo que se había terminado, pero no lo que estaba pasando en ese momento. Tuvo que preguntar por el chat del equipo y llamar al cliente veinte minutos después.

Con Jira esa pregunta se contestaba mirando una columna. Esa columna mentía a menudo, pero se contestaba.

La trampa de la velocidad

El cliente del cambio en la reunión se acostumbró a que las cosas llegasen el mismo día. Tres meses después pidió una integración con su sistema de facturación, que dependía de un proveedor externo y de permisos que tardaron una semana en llegar. Para él, una semana era lentísimo. Antes, la misma integración habría sido un sprint entero y le habría parecido normal.

Ir rápido cambia lo que el cliente espera, y cuando algo no puede ir rápido, hay que explicarlo antes de que pregunte. Lo hemos aprendido tarde.

El problema que no hemos resuelto: trabajar en paralelo

Si hay una cosa que Jira hacía bien y nosotros todavía no, es coordinar a varias personas trabajando a la vez en el mismo proyecto.

Con agentes, cada desarrollador puede tener varias tareas avanzando al mismo tiempo. Eso multiplica lo que sale, pero también multiplica las posibilidades de que dos tareas pisen el mismo trozo de código, o de que dos personas resuelvan el mismo problema por separado. Y el tasks.md se queda corto, porque refleja lo que se ha decidido o terminado, no lo que se está haciendo ahora mismo.

Lo que hacemos hoy es poco sofisticado: los desarrolladores hablan entre ellos. Antes de empezar algo que toca una parte sensible del proyecto, se avisa en el chat del equipo con un “voy a tocar los pagos esta mañana”. La reunión de diez minutos de cada mañana sirve sobre todo para eso. Y la regla es que una tarea se apunta en el fichero, con nombre, antes de dársela a un agente, no después.

Funciona porque somos pocos por proyecto y nos conocemos. No sé si funcionaría con quince personas.

Hemos probado otras cosas que no han funcionado:

• Un fichero de tareas por persona. Cada uno sabía lo suyo y nadie veía el conjunto. Duró dos semanas.
• Que el agente avise de con qué está. Le pedimos que, al empezar, escribiese en el fichero qué iba a tocar. Lo hacía, pero cuando dos sesiones empezaban casi a la vez, ninguna veía lo que había escrito la otra.
• Volver a un tablero solo para lo que está en curso. Duró menos que el fichero por persona. Nadie lo actualizaba, por lo mismo de antes.

Estamos mirando herramientas que intentan resolver justo esto. Orca, de Stably AI, es una aplicación de escritorio de código abierto que lanza varios agentes en paralelo, cada uno aislado, y te deja ver en una sola pantalla qué está haciendo cada uno y comparar los resultados. Resuelve la parte de ver qué hace cada agente de una persona. La parte de ver qué hace cada persona del equipo sigue abierta.

Qué están haciendo Atlassian y Linear

Los fabricantes de trackers han visto lo mismo y han respondido metiendo a los agentes dentro.

Atlassian abrió Agents in Jira en beta en febrero de 2026 y lo anunció como disponible para todos en mayo, en Team ‘26. Asignas un ticket a un agente desde el mismo desplegable que usas para una persona, y el agente lee el ticket y deja su progreso en él.

Linear tomó una decisión que me parece mejor: una issue solo se asigna a personas y se delega a agentes. El agente trabaja, pero el responsable sigue siendo un humano. Es una distinción pequeña en la pantalla y grande en la práctica, porque deja claro quién responde cuando el agente se equivoca, que es justo lo que nos pasó con las tareas que el agente daba por terminadas.

Las dos respuestas tienen el mismo problema de fondo: asumen que un ticket es una buena especificación para un agente, y casi ninguno lo es. “Arreglar el login en Safari” basta para una persona que sabe a quién preguntar. Un agente con ese ticket va a hacer algo, y lo va a hacer con mucha seguridad. Que asignar tickets a agentes sea cómodo hace más fácil mandar trabajo mal explicado a algo que no pregunta.

Dónde Jira sigue teniendo razón

Si has llegado hasta aquí pensando “esto os funciona porque sois pocos”, tienes parte de razón. Hay sitios donde yo no quitaría Jira:

• Varios equipos que dependen unos de otros. Un tasks.md coordina un proyecto. Cuando el equipo de pagos depende de que el de plataforma cambie algo, y cada uno trabaja en lo suyo, hace falta un sitio común donde esa dependencia se vea.
• Gente que no está en el proyecto. Dirección, soporte, ventas o compliance necesitan saber qué está pasando sin abrir un fichero dentro del código. Un tablero es una interfaz para ellos, y eso no cambia porque el código lo escriba un agente.
• Auditorías. Si te auditan ISO 27001 o SOC 2, el auditor va a querer ver que cada cambio tiene una petición, una aprobación y un responsable. Si tu proceso de control de cambios ya está montado sobre Jira, rehacerlo no compensa.
• El equipo de un cliente. Cuando nos integramos en el equipo de producto de un cliente, trabajamos con sus herramientas. Con Orquest usábamos su Jira y entrábamos en sus dailies. Ahí no hay nada que discutir: el tracker es suyo.

Lo que tienen en común es que casi todo es comunicación con personas que no están dentro del código. La parte de Jira que sigue teniendo sentido es la que habla con humanos. La que ha perdido el sentido, para nosotros, es la que planificaba el trabajo de los programadores.

Lo que haríamos si empezásemos hoy

Esto sigue cambiando, pero si un equipo nos preguntase mañana cómo empezar, le diríamos esto:

1. Deja de estimar el trabajo que hace un agente. Si el equipo sigue poniendo puntos a tareas de cuarenta minutos, está midiendo el ritual, no el trabajo.
2. Pon la lista de tareas dentro del proyecto, en un fichero que el agente lea al empezar y actualice al terminar. Es la forma más barata de que el agente tenga memoria entre sesiones.
3. Apunta la tarea antes de dársela a un agente, con nombre. Es la única regla que de verdad nos ha evitado trabajo duplicado.
4. Una tarea solo está hecha cuando la revisa una persona. El agente puede proponer que está terminada; no puede decidirlo.
5. Habla con el resto del equipo antes de tocar algo delicado. Un mensaje de una línea en el chat evita una tarde perdida. No hemos encontrado nada mejor todavía.
6. Cierra lo que lleve semanas sin moverse. Una tarea que nadie ha tocado en seis semanas es una decisión que nadie ha querido tomar. Si era importante, alguien la volverá a abrir.
7. Guarda Jira, o lo que uses, para hablar con quien no está en el código. Clientes que lo prefieran, dirección, auditoría.

Dentro de seis meses es probable que este texto se nos haya quedado viejo. Si resolvemos lo de trabajar en paralelo, lo contaremos aquí. Y si alguien ya lo ha resuelto, nos encantaría saber cómo: escríbenos a info@soamee.com.