Voce esta rodando varios agentes de IA programando no mesmo repositorio. Talvez tres, talvez treze. Eles precisam gerenciar seu proprio trabalho: criar issues, atualizar status, verificar dependencias, reportar progresso. Dezenas de escritas por minuto em toda a frota.
Isso e agentic engineering: humanos coordenando frotas de agentes de IA para entregar software. O fluxo de trabalho e novo, mas a primeira coisa que todo mundo faz e recorrer a ferramenta que ja conhece. Jira. Linear. GitHub Issues. Notion. Qualquer coisa que seu time use para gestao de projetos.
Nao funciona. E a incompatibilidade nao e superficial. E arquitetural.
Latencia mata throughput
Uma chamada a API do Jira leva de 200 a 800ms. Uma chamada a API do Linear e mais rapida, mas ainda fica entre 100 e 300ms. Criar um unico issue, ler suas dependencias, atualizar seu status: sao tres roundtrips passando por HTTPS, resolucao DNS, handshake TLS e serializacao 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 ate voce multiplicar pelo numero de operacoes. 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 operacoes. A 500ms cada, sao 3 segundos de pura espera. A 10ms cada, sao 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 codigo.
Escale isso para 13 agentes e o overhead e medido em minutos por hora.
Infraestrutura de autenticacao e cola fragil
Cada agente precisa de um token de API. Tokens expiram. Limites de taxa existem. Um agente dispara 20 atualizacoes rapidas e recebe um 429 Too Many Requests. Agora esta preso em um loop de retentativa com backoff exponencial em vez de fazer seu trabalho.
Voce acabou de adicionar um modo de falha inteiro que nao tem nada a ver com o trabalho em si. Rotacao de tokens, gestao de segredos, distribuicao de limites de taxa entre agentes. Isso e overhead operacional para uma capacidade que deveria ser trivial: escrever um registro em um banco de dados local.
Quando o issue tracker e um arquivo em disco, nao ha 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. Voce ve sprints. Story points. Responsaveis com fotos de perfil e enderecos de email. Fluxos de trabalho com estados como "Em Revisao" e "Pronto para Refinamento". O modelo de dados inteiro foi projetado para um time de humanos fazendo standups, planejamento de sprints e retrospectivas.
Agentes nao fazem standups. Nao estimam em story points. Nao precisam de um fluxo de trabalho com sete estados e quatro portoes de aprovacao.
O que agentes precisam e de um grafo de dependencias. Esta tarefa esta bloqueada por aquela. Este epic tem 12 filhos e 7 estao completos. Este agente reivindicou este issue ha 45 segundos e nao reportou. A estrutura de dados fundamental e uma arvore de tarefas com relacoes de bloqueio, nao um quadro de cartoes se movendo por colunas.
Ferramentas SaaS adicionam recursos de "automacao", mas o modelo central por baixo ainda e um quadro Kanban para humanos. Voce pode escrever um plugin de Jira que permita agentes criarem issues. Nao pode mudar o fato de que o Jira acha que seu agente e uma pessoa em um time de sprint.
Dependencia da nuvem e um ponto unico de falha
Seus agentes rodam localmente. Leem arquivos locais, escrevem codigo local e fazem commit em repos git locais. Podem trabalhar offline, num aviao ou numa rede com 2000ms de latencia. Nao faz diferenca.
Mas se seu issue tracker e um produto SaaS, cada operacao do agente exige acesso a internet. Linear fica fora do ar por 10 minutos? Toda a sua frota para. Sua internet domestica oscila por 30 segundos? Cada agente fica em loop de retentativa. O issue tracker, aquilo que deveria coordenar o trabalho, se torna o ponto unico de falha de todo o sistema.
Local-first significa que o issue tracker e tao confiavel quanto o sistema de arquivos. Sempre disponivel, sempre rapido, sempre sob seu controle.
O volume de escritas esta ordens de magnitude errado
Ferramentas SaaS de gestao de projetos sao projetadas para um time de 5 a 10 humanos fazendo algumas atualizacoes 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 unico projeto. Isso nao e um aumento marginal no uso. E um padrao de uso completamente diferente. Limites de taxa que parecem generosos para times humanos se tornam paredes solidas para frotas de agentes.
E nao e so volume. E concorrencia. Tres agentes atualizando os filhos do mesmo epic simultaneamente. Condicoes de corrida em campos de status. Falhas de locking otimista em threads de comentarios. Sao problemas que ferramentas SaaS nunca precisaram resolver porque humanos nao atualizam o mesmo issue de tres 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. Voce esta pagando por assento, por mes, pelo privilegio de acessar seus proprios dados de projeto pela API deles.
Quer migrar para outra ferramenta? Exporte o que puder como CSV e abandone o resto. Comentarios, anexos, campos customizados, historico de auditoria: boa sorte tirando tudo isso em um formato utilizavel. O modelo SaaS troca propriedade dos dados por conveniencia.
Mas colaboracao nao exige um intermediario. Se seu banco de dados de issues e respaldado por algo como Dolt (Git para bancos de dados), voce 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 codigo. Faca merge da mesma forma. Resolva conflitos com as mesmas ferramentas e o mesmo modelo mental. Seus dados continuam sendo seus. Colaboracao funciona como git, nao como uma assinatura.
O que realmente funciona
Esqueca os nomes de marca e pense no que agentes realmente precisam de um issue tracker:
- Local-first. Sem dependencia de rede. O banco de dados e um arquivo em disco.
- Nativo de CLI. Agentes vivem no terminal. A interface tambem deveria.
- Baseado em Git. Versionado, mesclavel, auditavel. Sem lock-in de fornecedor.
- Sem overhead de autenticacao. Se o agente consegue ler o sistema de arquivos, consegue gerenciar issues.
- Baixa latencia. Menos de 50ms por operacao, nao 500ms.
- Sincronizavel sem intermediarios. Push e pull como um repo git, nao por webhooks de API.
Isso e o que eu uso diariamente. beads e um issue tracker nativo de Git construido exatamente para esse fluxo de trabalho. Armazena tudo em um banco de dados local SQLite respaldado por Dolt para versionamento e sincronizacao. O CLI e a interface principal. Agentes criam, atualizam e consultam issues da mesma forma que executam qualquer outro comando.
Beadbox e a camada visual que construi por cima. Observa o banco de dados local em busca de mudancas e renderiza arvores de dependencias, progresso de epics 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 nao sao o problema
Jira e excelente no que faz: coordenar times humanos por meio de fluxos de trabalho estruturados. Linear e lindo para times pequenos que querem velocidade e refinamento. GitHub Issues e perfeito para colaboracao em codigo aberto.
Nenhuma delas e ruim. Estao resolvendo um problema diferente. Se seu fluxo de trabalho e um time de cinco humanos fazendo sprints de duas semanas, continue usando.
Mas se voce esta rodando 5, 10 ou 13 agentes de IA se coordenando em tempo real no mesmo repositorio, voce superou o modelo SaaS. Agentic engineering precisa de ferramentas construidas para agentic engineering, nao fluxos de trabalho humanos com uma API adicionada por cima.