Estás ejecutando múltiples agentes de IA de programación en el mismo repositorio. Quizás tres, quizás trece. Necesitan gestionar su propio trabajo: crear issues, actualizar estados, verificar dependencias, reportar progreso. Decenas de escrituras por minuto en toda la flota.
Esto es ingeniería agéntica: humanos coordinando flotas de agentes de IA para entregar 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 tu equipo use para gestión de proyectos.
No funciona. Y la incompatibilidad no es superficial. Es arquitectural.
La latencia mata el throughput
Una llamada a la API de Jira toma de 200 a 800ms. Una llamada a la API de Linear es más rápida pero aún queda entre 100 y 300ms. Crear un solo issue, leer sus dependencias, actualizar su estado: son tres roundtrips a través de HTTPS, resolución DNS, handshake TLS y serialización JSON. Digamos 500ms en un buen día.
Una escritura local vía CLI a una base de datos SQLite toma menos de 50ms. Frecuentemente menos de 10ms.
Parece un error de redondeo hasta que lo multiplicas por el número de operaciones. Un agente trabajando en una tarea puede 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 podría completar un ciclo de tarea en 30 segundos ahora gasta el 10% de su tiempo esperando HTTP en lugar de escribir código.
Escala eso a 13 agentes y el overhead se mide en minutos por hora.
La infraestructura de autenticación es pegamento frágil
Cada agente necesita un token de API. Los tokens expiran. Los límites de tasa existen. Un agente dispara 20 actualizaciones rápidas y recibe un 429 Too Many Requests. Ahora está atrapado en un loop de reintentos con backoff exponencial en lugar de hacer su trabajo.
Acabas de agregar un modo de falla entero que no tiene nada que ver con el trabajo en sí. Rotación de tokens, gestión de secretos, distribución de límites de tasa entre agentes. Eso es overhead operacional para una capacidad que debería ser trivial: escribir un registro en una base de datos local.
Cuando el issue tracker es un archivo en disco, no hay nada que autenticar. Si el agente puede leer el sistema de archivos, puede leer y escribir issues. Una cosa menos para romper.
El modelo de datos asume humanos
Abre Jira. Ves sprints. Story points. Asignados con fotos de perfil y direcciones de email. Flujos de trabajo con estados como "En Revisión" y "Listo para Refinamiento". El modelo de datos entero fue diseñado para un equipo de humanos haciendo standups, planificación 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 aprobación.
Lo que los agentes necesitan es un grafo de dependencias. Esta tarea está bloqueada por aquella. Este épico tiene 12 hijos y 7 están completos. Este agente reclamó este issue hace 45 segundos y no ha reportado. La estructura de datos fundamental es un árbol de tareas con relaciones de bloqueo, no un tablero de tarjetas moviéndose entre columnas.
Las herramientas SaaS agregan funciones de "automatización", 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 único de falla
Tus agentes corren localmente. Leen archivos locales, escriben código local y hacen commit en repos git locales. Pueden trabajar offline, en un avión o en una red con 2000ms de latencia. No les importa.
Pero si tu issue tracker es un producto SaaS, cada operación del agente requiere acceso a internet. Linear se cae por 10 minutos? Toda tu flota se detiene. Tu internet doméstico falla por 30 segundos? Cada agente entra en un loop de reintentos. El issue tracker, aquello que debería coordinar el trabajo, se convierte en el punto único de falla de todo el sistema.
Local-first significa que el issue tracker es tan confiable como el sistema de archivos. Siempre disponible, siempre rápido, siempre bajo tu control.
El volumen de escrituras está órdenes de magnitud mal
Las herramientas SaaS de gestión de proyectos están diseñadas para un equipo de 5 a 10 humanos haciendo unas cuantas actualizaciones por día. Quizás 50 a 100 escrituras en todo el equipo.
13 agentes actualizando issues cada pocos minutos producen cientos de llamadas de API por hora desde un solo proyecto. Esto no es un aumento marginal en el uso. Es un patrón de uso completamente diferente. Los límites de tasa que parecen generosos para equipos humanos se convierten en paredes sólidas para flotas de agentes.
Y no es solo volumen. Es concurrencia. Tres agentes actualizando los hijos del mismo épico simultáneamente. Condiciones de carrera en campos de estado. Fallos de locking optimista en hilos de comentarios. Son problemas que las herramientas SaaS nunca tuvieron que resolver porque los humanos no actualizan el mismo issue desde tres terminales en el mismo instante.
Colaborar significa entregar tus datos
Para compartir un proyecto en Jira con un colega, ambos necesitan cuentas en Jira. Los datos viven en los servidores de Atlassian. Estás pagando por asiento, por mes, por el privilegio de acceder a tus propios datos de proyecto a través de su API.
Quieres migrar a otra herramienta? Exporta lo que puedas como CSV y abandona el resto. Comentarios, adjuntos, campos personalizados, historial de auditoría: buena suerte sacando todo eso en un formato utilizable. El modelo SaaS intercambia propiedad de los datos por conveniencia.
Pero la colaboración no requiere un intermediario. Si tu base de datos de issues está respaldada por algo como Dolt (Git para bases de datos), haces push a un remoto y tu colega hace pull. Crea branches en tu base de datos de issues de la misma forma que creas branches en código. Haz merge de la misma forma. Resuelve conflictos con las mismas herramientas y el mismo modelo mental. Tus datos siguen siendo tuyos. La colaboración funciona como git, no como una suscripción.
Lo que realmente funciona
Olvida 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 también debería.
- Basado en Git. Versionado, fusionable, auditable. Sin lock-in de proveedor.
- Sin overhead de autenticación. Si el agente puede leer el sistema de archivos, puede gestionar issues.
- Baja latencia. Menos de 50ms por operación, no 500ms.
- Sincronizable sin intermediarios. Push y pull como un repo git, no por 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 sincronización. 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 construí encima. Observa la base de datos local en busca de cambios y renderiza árboles de dependencias, progreso de épicas 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 través de flujos de trabajo estructurados. Linear es hermoso para equipos pequeños que quieren velocidad y pulido. GitHub Issues es perfecto para colaboración en código abierto.
Ninguna de ellas es mala. Están resolviendo un problema diferente. Si tu flujo de trabajo es un equipo de cinco humanos haciendo sprints de dos semanas, sigue usándolas.
Pero si estás ejecutando 5, 10 o 13 agentes de IA coordinándose en tiempo real en el mismo repositorio, has superado el modelo SaaS. La ingeniería agéntica necesita herramientas construidas para ingeniería agéntica, no flujos de trabajo humanos con una API agregada encima.