Tienes varios agentes de IA programando sobre el mismo repositorio. Tal vez tres, tal vez trece. Necesitan gestionar su propio trabajo: crear issues, actualizar estados, verificar dependencias, reportar avances. Decenas de escrituras por minuto en toda la flota.
Esto es agentic engineering: humanos coordinando flotas de agentes de IA para producir software. El flujo de trabajo es nuevo, pero lo primero que todos hacen es recurrir a la herramienta que ya conocen. Jira. Linear. GitHub Issues. Notion. Lo que sea que tu equipo use para gestionar proyectos.
No funciona. Y la incompatibilidad no es superficial. Es arquitectonica.
La latencia mata el rendimiento
Una llamada a la API de Jira tarda entre 200 y 800ms. Una llamada a la API de Linear es mas rapida, pero sigue siendo de 100 a 300ms. Crear un solo issue, leer sus dependencias, actualizar su estado: son tres viajes de ida y vuelta a traves de HTTPS, resolucion DNS, handshake TLS y serializacion JSON. Digamos 500ms en un buen dia.
Una escritura local por CLI a una base de datos SQLite tarda menos de 50ms. Muchas veces menos de 10ms.
Parece un error de redondeo hasta que lo multiplicas por el numero de operaciones. Un agente trabajando en una tarea podria crear 2 o 3 sub-issues, actualizar el estado del padre, verificar bloqueos y comentar su progreso. Seis operaciones. A 500ms cada una, son 3 segundos de pura espera. A 10ms cada una, son 60 milisegundos. El agente que podria completar un ciclo de tarea en 30 segundos ahora dedica el 10% de su tiempo esperando respuestas HTTP en lugar de escribir codigo.
Escala eso a 13 agentes y la sobrecarga se mide en minutos por hora.
La infraestructura de autenticacion es pegamento fragil
Cada agente necesita un token de API. Los tokens expiran. Los limites de tasa existen. Un agente lanza una rafaga de 20 actualizaciones rapidas y recibe un 429 Too Many Requests. Ahora esta atrapado en un bucle de reintentos con backoff exponencial en lugar de hacer su trabajo.
Acabas de agregar un modo de fallo completo que no tiene nada que ver con el trabajo en si. Rotacion de tokens, gestion de secretos, distribucion de limites de tasa entre agentes. Eso es sobrecarga operativa para una capacidad que deberia ser trivial: escribir un registro en una base de datos local.
Cuando el issue tracker es un archivo en disco, no hay nada contra lo que autenticarse. Si el agente puede leer el sistema de archivos, puede leer y escribir issues. Una cosa menos que pueda fallar.
El modelo de datos asume humanos
Abre Jira. Ves sprints. Story points. Personas asignadas con fotos de perfil y direcciones de correo. Flujos de trabajo con estados como "En revision" y "Listo para refinamiento". Todo el modelo de datos fue disenado para un equipo de humanos haciendo standups, planificacion de sprints y retrospectivas.
Los agentes no hacen standups. No estiman en story points. No necesitan un flujo de trabajo con siete estados y cuatro puertas de aprobacion.
Lo que los agentes necesitan es un grafo de dependencias. Esta tarea esta bloqueada por aquella otra. Este epic tiene 12 hijos y 7 estan completados. Este agente reclamo este issue hace 45 segundos y no ha reportado. La estructura de datos fundamental es un arbol de tareas con relaciones de bloqueo, no un tablero de tarjetas moviendose por columnas.
Las herramientas SaaS agregan funciones de "automatizacion", pero el modelo central sigue siendo un tablero Kanban para humanos. Puedes escribir un plugin de Jira que permita a los agentes crear issues. No puedes cambiar el hecho de que Jira piensa que tu agente es una persona en un equipo de sprint.
La dependencia de la nube es un punto unico de fallo
Tus agentes se ejecutan localmente. Leen archivos locales, escriben codigo local y hacen commit a repos git locales. Pueden trabajar sin conexion, en un avion o en una red con 2000ms de latencia. Les da igual.
Pero si tu issue tracker es un producto SaaS, cada operacion del agente requiere acceso a internet. Linear se cae durante 10 minutos? Toda tu flota se detiene. Tu internet domestico falla por 30 segundos? Cada agente reintenta en bucle. El issue tracker, la cosa que se supone que coordina el trabajo, se convierte en el punto unico de fallo de todo el sistema.
Local-first significa que el issue tracker es tan confiable como el sistema de archivos. Siempre disponible, siempre rapido, siempre bajo tu control.
El volumen de escrituras esta ordenes de magnitud equivocado
Las herramientas SaaS de gestion de proyectos estan disenadas para un equipo de 5 a 10 humanos haciendo un punado de actualizaciones al dia. Quiza 50 a 100 escrituras en todo el equipo.
13 agentes actualizando issues cada pocos minutos producen cientos de llamadas a la API por hora desde un solo proyecto. Eso no es un aumento marginal en el uso. Es un patron de uso completamente diferente. Los limites de tasa que parecen generosos para equipos humanos se convierten en muros infranqueables para flotas de agentes.
Y no es solo volumen. Es concurrencia. Tres agentes actualizando los hijos del mismo epic simultaneamente. Condiciones de carrera en campos de estado. Fallos de bloqueo optimista en hilos de comentarios. Estos son problemas que las herramientas SaaS nunca tuvieron que resolver porque los humanos no actualizan el mismo issue desde tres terminales al mismo instante.
Colaborar significa entregar tus datos
Para compartir un proyecto de Jira con un companero, ambos necesitan cuentas de Jira. Los datos viven en los servidores de Atlassian. Estas pagando por puesto, por mes, por el privilegio de acceder a tus propios datos de proyecto a traves de su API.
Quieres migrar a otra herramienta? Exporta lo que puedas como CSV y abandona el resto. Comentarios, adjuntos, campos personalizados, historial de auditoria: buena suerte sacando todo eso en un formato utilizable. El modelo SaaS intercambia la propiedad de los datos por conveniencia.
Pero la colaboracion no requiere un intermediario. Si tu base de datos de issues esta respaldada por algo como Dolt (Git para bases de datos), la empujas a un remoto y tu companero la descarga. Crea ramas en tu base de datos de issues de la misma forma que creas ramas en codigo. Haz merge de la misma forma. Resuelve conflictos con las mismas herramientas y el mismo modelo mental. Tus datos siguen siendo tuyos. La colaboracion funciona como git, no como una suscripcion.
Lo que realmente funciona
Deja de lado los nombres de marca y piensa en lo que los agentes realmente necesitan de un issue tracker:
- Local-first. Sin dependencia de red. La base de datos es un archivo en disco.
- Nativo de CLI. Los agentes viven en la terminal. La interfaz tambien deberia.
- Respaldado por Git. Versionado, fusionable, auditable. Sin dependencia de proveedor.
- Sin sobrecarga de autenticacion. Si el agente puede leer el sistema de archivos, puede gestionar issues.
- Baja latencia. Menos de 50ms por operacion, no 500ms.
- Sincronizable sin intermediarios. Push y pull como un repo git, no a traves de webhooks de API.
Esto es lo que uso a diario. beads es un issue tracker nativo de Git construido exactamente para este flujo de trabajo. Almacena todo en una base de datos local SQLite respaldada por Dolt para versionado y sincronizacion. El CLI es la interfaz principal. Los agentes crean, actualizan y consultan issues de la misma forma que ejecutan cualquier otro comando.
Beadbox es la capa visual que construi encima. Observa la base de datos local en busca de cambios y renderiza arboles de dependencias, progreso de epics y actividad de agentes en tiempo real. Los agentes usan el CLI. Yo uso el dashboard. Ambos leen de la misma base de datos local.
Las herramientas antiguas no son el problema
Jira es excelente en lo que hace: coordinar equipos humanos a traves de flujos de trabajo estructurados. Linear es hermoso para equipos pequenos que quieren velocidad y pulido. GitHub Issues es perfecto para la colaboracion en codigo abierto.
Ninguna de ellas es mala. Estan resolviendo un problema diferente. Si tu flujo de trabajo es un equipo de cinco humanos haciendo sprints de dos semanas, sigue usandolas.
Pero si estas ejecutando 5, 10 o 13 agentes de IA coordinandose en tiempo real sobre el mismo repositorio, has superado el modelo SaaS. Agentic engineering necesita herramientas construidas para agentic engineering, no flujos de trabajo humanos con una API anadida.