Seu backlog costumava ser uma lista da qual você e alguns colegas puxavam tarefas. Você lia o item do topo, entendia o que ele pedia e fazia. A triagem era rápida porque a única pergunta era “quem tem tempo?”. Agora, alguns desses itens podem ser assumidos por um agente de código em vez de uma pessoa, e a fila tranquila se transforma em fonte de erros pequenos e caros: um agente começa uma tarefa que ninguém terminou de escrever, dois agentes pegam trabalhos sobrepostos e uma coluna “concluído” se enche de resultados que ninguém pediu.
O problema não são os agentes. É que um backlog criado para humanos mudou de função sem avisar. Deixou de ser uma lista de tarefas e virou uma fila de despacho capaz de disparar execução. Quando um item da lista pode acionar trabalho real, o momento em que você move uma tarefa e o momento em que você decide quem é o responsável passam a ter consequências que antes não existiam.
É nessa camada que o Sharkly atua. Você já tem agentes de código; o Sharkly os transforma em um time ao dar ao backlog um significado compartilhado. Task é a unidade principal de trabalho, Backlog é onde o trabalho não comprometido aguarda, e Triage é uma fila de entrada dedicada onde os itens que chegam ficam até que alguém decida. Este artigo mostra como triar um backlog misto de humanos e agentes sem que essas filas virem caos, e termina com uma checklist que você pode aplicar hoje mesmo.
O que backlog e triagem significam quando os agentes podem fazer o trabalho
Duas definições fazem quase todo o trabalho aqui, então vale deixá-las precisas.
Um backlog é o conjunto do trabalho não comprometido: tarefas que existem, mas que ninguém decidiu começar ainda. A triagem é a decisão de entrada tomada sobre itens novos ou pouco claros: aceitar, recusar, marcar como duplicado ou adiar para depois. Humanos sempre fizeram as duas coisas de forma informal. A mudança é que, em um time de humanos e agentes, o resultado da triagem agora inclui “qual agente executa isto”, e o ato de comprometer uma tarefa pode iniciar uma execução.
Eis a fronteira que confunde as pessoas logo de cara: atribuir um Agent a uma tarefa no Backlog não a inicia. O Backlog é uma área de estacionamento onde o trabalho é preparado antes da execução. A execução só começa quando a tarefa sai do Backlog para um status pronto para trabalho, e quando há um Computer e um Runtime disponíveis. Ou seja, “atribuir o agente” e “iniciar o agente” são dois eventos separados, com o status do backlog entre eles funcionando como um portão.
Mais uma fronteira que vale deixar clara: agentes não mantêm um backlog particular. Não existe uma fila oculta que um Agent percorre sozinho. Todo item que um Agent vai tocar fica no quadro compartilhado, e é isso que torna a triagem possível em vez de puro palpite.
Onde uma configuração faça você mesmo deixa de escalar
Uma planilha, um quadro Kanban e alguns terminais funcionam bem para uma pessoa e dois agentes. Isso deixa de escalar em pontos previsíveis, e cada um deles aparece como uma falha específica.
A coluna de status não significa nada para os agentes. Em um quadro manual, mover um cartão para “Em andamento” é um recado para seus colegas; nada é executado. Assim, o quadro e o trabalho real se distanciam: um cartão diz “Em andamento” enquanto o agente terminou há uma hora, ou diz “A fazer” enquanto o agente já está três commits adiante porque alguém o iniciou em um terminal. Ninguém confia no quadro, então ninguém o usa.
As decisões de triagem ficam na cabeça de uma pessoa. Quem atende as solicitações que chegam lembra que um bug já foi reportado, que uma funcionalidade foi recusada no trimestre passado, que uma tarefa precisa primeiro da contribuição do design. Quando essa pessoa não está, surgem duplicatas e os agentes começam trabalhos que deveriam ter sido recusados logo na entrada. A fila não tem memória.
Atribuição e escopo acabam decididos no mesmo momento apressado. Um escopo vago é sobrevivível quando uma pessoa pega a tarefa e faz uma pergunta. Um agente não para para perguntar; ele executa com o que você deu e devolve um resultado confiante e errado. O custo de uma triagem superficial passou de “um colega fica confuso por um instante” para “um agente queimou uma execução e um ciclo de revisão na coisa errada”.
Como triar um backlog misto, passo a passo
Esta é a sequência que mantém um backlog de humanos e agentes íntegro. Cada passo indica a falha que ele evita.
1. Esvazie a fila de entrada antes de mexer no backlog. Novas solicitações chegam ao Triage, não direto ao backlog. Trate cada item com uma de quatro decisões: aceitar, recusar, marcar como duplicado ou adiar. O Triage é uma fila de entrada, não um filtro salvo nem um construtor de formulários, então a decisão é explícita e registrada. Falha que evita: trabalho recusado ou duplicado se transformando silenciosamente em tarefas reais que um agente depois assume.
2. Dê forma à tarefa antes que ela fique elegível para um agente. Um item aceito se torna uma Task, mas permanece no Backlog enquanto você escreve os critérios de aceite, anexa o repositório e anota as restrições. É esse o passo que as pessoas pulam sob pressão de tempo. Falha que evita: um agente executando a partir de um título de uma linha e devolvendo algo que bate tecnicamente com as palavras, mas erra a intenção.
3. Defina o responsável e trate “qual agente” como uma escolha de verdade. Algumas tarefas pedem uma pessoa. Outras pedem um agente, e entre os agentes o certo depende da tarefa: um refactor, uma rodada de escrita de testes e uma atualização de documentação não são o mesmo trabalho. Faça o roteamento de forma deliberada, em vez de mandar para o agente que estiver ocioso. Nosso guia de roteamento para agentes de código mostra como tomar essa decisão. Falha que evita: o runtime errado consumindo uma tarefa para a qual não é adequado.
4. Mantenha no Backlog até que esteja realmente pronto. Esse é o portão. Uma tarefa pode estar totalmente atribuída e ainda assim ficar no Backlog sem que nenhuma execução comece. Aproveite isso. Não a mova até que o escopo esteja definido e você realmente queira que o trabalho comece. Falha que evita: uma tarefa pela metade disparar uma execução porque alguém a arrastou para a coluna errada.
5. Comprometa a tarefa e deixe a execução começar. Mova a tarefa para um status pronto, ou puxe-a para um Sprint. Quando uma tarefa com um Agent pronto sai do Backlog e há um Computer e um Runtime disponíveis, a execução começa. Agora a mudança de status e o trabalho são o mesmo evento, que é exatamente o ponto.
Para times que trabalham em ciclos, o artigo Planejamento de Sprint para times de humanos e agentes mostra como o mesmo passo de comprometimento define o escopo de um período de tempo em vez de uma única tarefa.
O status do backlog se torna um portão de execução
A mudança mental é esta: em um quadro só de humanos, o status é um rótulo que descreve a realidade. Em um quadro de humanos e agentes, o status é uma alavanca que muda a realidade. Tirar uma tarefa do Backlog é a ação que inicia o agente, então sua disciplina de triagem passa a ser seu mecanismo de segurança.
Esse portão também é onde o contrato entre humanos e agentes deve ficar. Agentes pesquisam, executam, testam e reportam. As pessoas decidem o que entra no backlog, o que é comprometido e o que é entregue. A automação para onde o julgamento do time é necessário. A visão Plan mantém Backlog, Sprints e Projects em um só lugar, para que a decisão de comprometimento fique visível em vez de enterrada em um terminal, e para que execução, bloqueios, resultados e revisão voltem todos para a Task em vez de se espalharem por sessões privadas.
É por isso que a higiene do backlog importa mais com agentes, e não menos. Um backlog humano bagunçado é só desordem. Um backlog de agentes bagunçado é desordem que de vez em quando se executa sozinha. O quadro mantém contexto, responsabilidade, progresso, resultados e revisão humana visíveis da entrada até o lançamento, e é essa a diferença entre uma fila que você gerencia e uma fila que gerencia você. Quando o que se acumula é a revisão, e não a entrada, o gargalo é outro, e isso está em por que a revisão humana é a verdadeira restrição.
Você pode fazer isso com uma planilha e disciplina manual se o volume for baixo. Se você já recebe um fluxo constante de solicitações e roda vários agentes, o Sharkly oferece a fila de Triage, o portão do Backlog e um único quadro compartilhado, para que essas decisões parem de viver na sua cabeça. Para uma visão mais ampla do mesmo fluxo de trabalho, veja nosso guia de gerenciamento de tarefas com agentes de IA e a diferença entre Triage e sua Inbox pessoal.
Uma checklist de triagem para aplicar hoje mesmo
Aplique isto no seu quadro atual. Cada “não” é um ponto onde os agentes vão te surpreender.
- As novas solicitações chegam a algum lugar antes do backlog? Se a entrada vai direto para “A fazer”, você não tem uma etapa de aceitar/recusar/duplicar e as duplicatas são inevitáveis.
- O escopo de cada tarefa do backlog é bom o bastante para entregar a um desconhecido? Se não é bom o bastante para uma pessoa recém-contratada, não é bom o bastante para um agente.
- Mover uma tarefa realmente inicia alguma coisa? Se suas mudanças de status são apenas rótulos, o quadro e o trabalho vão se distanciar.
- A atribuição é uma decisão de verdade, incluindo qual agente? Mandar para o agente ocioso por padrão não é roteamento.
- Você consegue dizer, agora mesmo, no que cada agente está trabalhando e o que está aguardando revisão? Se essa resposta está na memória de alguém ou no histórico de um terminal, a triagem não tem uma fonte única de verdade.
- O trabalho concluído volta para a task, e não para uma sessão privada? Resultados, bloqueios e diffs pertencem ao registro compartilhado, para que a revisão tenha algo sobre o que agir.
Resolva os dois primeiros antes de aumentar o número de agentes. Uma etapa de entrada limpa e um escopo de tarefa honesto evitam a maior parte das falhas caras; todo o resto é refinamento em cima de um backlog que já significa alguma coisa.
