Você está rodando vários agentes de IA programando no mesmo repositório. Talvez três, talvez treze. Eles precisam gerenciar seu próprio trabalho: criar issues, atualizar status, verificar dependências, reportar progresso. Dezenas de escritas por minuto em toda a frota.
Isso é engenharia agêntica: humanos coordenando frotas de agentes de IA para entregar software. O fluxo de trabalho é novo, mas a primeira coisa que todo mundo faz é recorrer à ferramenta que já conhece. Jira. Linear. GitHub Issues. Notion. Qualquer coisa que seu time use para gestão de projetos.
Não funciona. E a incompatibilidade não é superficial. É arquitetural.
Latência mata throughput
Uma chamada à API do Jira leva de 200 a 800ms. Uma chamada à API do Linear é mais rápida, mas ainda fica entre 100 e 300ms. Criar um único issue, ler suas dependências, atualizar seu status: são três roundtrips passando por HTTPS, resolução DNS, handshake TLS e serialização JSON. Digamos 500ms num dia bom.
Uma escrita local via CLI em um banco de dados SQLite leva menos de 50ms. Frequentemente menos de 10ms.
Parece um erro de arredondamento até você multiplicar pelo número de operações. Um agente trabalhando em uma tarefa pode criar 2 ou 3 sub-issues, atualizar o status do pai, verificar bloqueios e comentar seu progresso. Seis operações. A 500ms cada, são 3 segundos de pura espera. A 10ms cada, são 60 milissegundos. O agente que poderia completar um ciclo de tarefa em 30 segundos agora gasta 10% do seu tempo esperando HTTP em vez de escrever código.
Escale isso para 13 agentes e o overhead é medido em minutos por hora.
Infraestrutura de autenticação é cola frágil
Cada agente precisa de um token de API. Tokens expiram. Limites de taxa existem. Um agente dispara 20 atualizações rápidas e recebe um 429 Too Many Requests. Agora está preso em um loop de retentativa com backoff exponencial em vez de fazer seu trabalho.
Você acabou de adicionar um modo de falha inteiro que não tem nada a ver com o trabalho em si. Rotação de tokens, gestão de segredos, distribuição de limites de taxa entre agentes. Isso é overhead operacional para uma capacidade que deveria ser trivial: escrever um registro em um banco de dados local.
Quando o issue tracker é um arquivo em disco, não há nada para autenticar. Se o agente consegue ler o sistema de arquivos, consegue ler e escrever issues. Uma coisa a menos para quebrar.
O modelo de dados assume humanos
Abra o Jira. Você vê sprints. Story points. Responsáveis com fotos de perfil e endereços de email. Fluxos de trabalho com estados como "Em Revisão" e "Pronto para Refinamento". O modelo de dados inteiro foi projetado para um time de humanos fazendo standups, planejamento de sprints e retrospectivas.
Agentes não fazem standups. Não estimam em story points. Não precisam de um fluxo de trabalho com sete estados e quatro portões de aprovação.
O que agentes precisam é de um grafo de dependências. Esta tarefa está bloqueada por aquela. Este épico tem 12 filhos e 7 estão completos. Este agente reivindicou este issue há 45 segundos e não reportou. A estrutura de dados fundamental é uma árvore de tarefas com relações de bloqueio, não um quadro de cartões se movendo por colunas.
Ferramentas SaaS adicionam recursos de "automação", mas o modelo central por baixo ainda é um quadro Kanban para humanos. Você pode escrever um plugin de Jira que permita agentes criarem issues. Não pode mudar o fato de que o Jira acha que seu agente é uma pessoa em um time de sprint.
Dependência da nuvem é um ponto único de falha
Seus agentes rodam localmente. Leem arquivos locais, escrevem código local e fazem commit em repos git locais. Podem trabalhar offline, num avião ou numa rede com 2000ms de latência. Não faz diferença.
Mas se seu issue tracker é um produto SaaS, cada operação do agente exige acesso à internet. Linear fica fora do ar por 10 minutos? Toda a sua frota para. Sua internet doméstica oscila por 30 segundos? Cada agente fica em loop de retentativa. O issue tracker, aquilo que deveria coordenar o trabalho, se torna o ponto único de falha de todo o sistema.
Local-first significa que o issue tracker é tão confiável quanto o sistema de arquivos. Sempre disponível, sempre rápido, sempre sob seu controle.
O volume de escritas está ordens de magnitude errado
Ferramentas SaaS de gestão de projetos são projetadas para um time de 5 a 10 humanos fazendo algumas atualizações por dia. Talvez 50 a 100 escritas em todo o time.
13 agentes atualizando issues a cada poucos minutos produzem centenas de chamadas de API por hora de um único projeto. Isso não é um aumento marginal no uso. É um padrão de uso completamente diferente. Limites de taxa que parecem generosos para times humanos se tornam paredes sólidas para frotas de agentes.
E não é só volume. É concorrência. Três agentes atualizando os filhos do mesmo épico simultaneamente. Condições de corrida em campos de status. Falhas de locking otimista em threads de comentários. São problemas que ferramentas SaaS nunca precisaram resolver porque humanos não atualizam o mesmo issue de três terminais no mesmo instante.
Colaborar significa entregar seus dados
Para compartilhar um projeto no Jira com um colega, ambos precisam de contas no Jira. Os dados ficam nos servidores da Atlassian. Você está pagando por assento, por mês, pelo privilégio de acessar seus próprios dados de projeto pela API deles.
Quer migrar para outra ferramenta? Exporte o que puder como CSV e abandone o resto. Comentários, anexos, campos customizados, histórico de auditoria: boa sorte tirando tudo isso em um formato utilizável. O modelo SaaS troca propriedade dos dados por conveniência.
Mas colaboração não exige um intermediário. Se seu banco de dados de issues é respaldado por algo como Dolt (Git para bancos de dados), você faz push para um remoto e seu colega faz pull. Crie branches no seu banco de dados de issues da mesma forma que cria branches em código. Faça merge da mesma forma. Resolva conflitos com as mesmas ferramentas e o mesmo modelo mental. Seus dados continuam sendo seus. Colaboração funciona como git, não como uma assinatura.
O que realmente funciona
Esqueça os nomes de marca e pense no que agentes realmente precisam de um issue tracker:
- Local-first. Sem dependência de rede. O banco de dados é um arquivo em disco.
- Nativo de CLI. Agentes vivem no terminal. A interface também deveria.
- Baseado em Git. Versionado, mesclável, auditável. Sem lock-in de fornecedor.
- Sem overhead de autenticação. Se o agente consegue ler o sistema de arquivos, consegue gerenciar issues.
- Baixa latência. Menos de 50ms por operação, não 500ms.
- Sincronizável sem intermediários. Push e pull como um repo git, não por webhooks de API.
Isso é o que eu uso diariamente. beads é um issue tracker nativo de Git construído exatamente para esse fluxo de trabalho. Armazena tudo em um banco de dados local SQLite respaldado por Dolt para versionamento e sincronização. O CLI é a interface principal. Agentes criam, atualizam e consultam issues da mesma forma que executam qualquer outro comando.
Beadbox é a camada visual que construí por cima. Observa o banco de dados local em busca de mudanças e renderiza árvores de dependências, progresso de épicos e atividade de agentes em tempo real. Os agentes usam o CLI. Eu uso o dashboard. Ambos leem do mesmo banco de dados local.
As ferramentas antigas não são o problema
Jira é excelente no que faz: coordenar times humanos por meio de fluxos de trabalho estruturados. Linear é lindo para times pequenos que querem velocidade e refinamento. GitHub Issues é perfeito para colaboração em código aberto.
Nenhuma delas é ruim. Estão resolvendo um problema diferente. Se seu fluxo de trabalho é um time de cinco humanos fazendo sprints de duas semanas, continue usando.
Mas se você está rodando 5, 10 ou 13 agentes de IA se coordenando em tempo real no mesmo repositório, você superou o modelo SaaS. Engenharia agêntica precisa de ferramentas construídas para engenharia agêntica, não fluxos de trabalho humanos com uma API adicionada por cima.