Você iniciou quatro agentes esta manhã. Um refatorou o módulo de autenticação, um escreveu testes, um correu atrás de um job de CI instável, e um ainda está pensando. À tarde, você tem uma vaga sensação de que coisas aconteceram, uma pilha de abas de terminal, três worktrees que você mal lembra de ter criado e dois pull requests que você não leu. O trabalho foi feito. Mas você não consegue ver o que ele foi.
Rastrear o trabalho concluído por agentes de codificação com IA é o problema de transformar essa dispersão em um registro: o que cada agente alterou, se aquilo se sustenta e onde terminou. É um problema real porque os agentes terminam mais rápido do que você consegue inspecioná-los, e as evidências do que fizeram ficam em lugares projetados para uma pessoa trabalhando sozinha. Este guia percorre primeiro a configuração manual, aponta onde ela quebra e, depois, mostra o fluxo de trabalho que a Sharkly usa para manter cada resultado vinculado à tarefa que o solicitou.
A versão curta: você consegue acompanhar alguns agentes na mão, com git e o terminal. Além disso, você precisa de um lugar compartilhado onde os resultados retornem por conta própria, porque o gargalo deixa de ser a codificação e passa a ser sua capacidade de revisá-la.
TL;DR
Rastrear o trabalho concluído dos agentes significa responder a três perguntas em cada execução: o que mudou, se está correto e onde foi parar. O histórico do git e os pull requests respondem à primeira para um ou dois agentes. Quando vários agentes trabalham em paralelo, o registro se fragmenta entre worktrees, terminais e filas de PR, e você perde o vínculo entre a tarefa e o resultado dela. Um quadro de tarefas resolve isso ao fazer com que a execução, os bloqueios, os resultados e a revisão humana retornem a uma única tarefa, de modo que o trabalho concluído seja inspecionável em vez de reconstruído.
O que significa rastrear o trabalho concluído
Rastrear não é um registro de atividade. É a capacidade de responder a três perguntas sobre uma execução finalizada sem precisar fazer engenharia reversa dela.
- O que mudou. O diff, os arquivos tocados, o motivo de cada um.
- Se está correto. O typecheck, os testes, o build e um resumo do que o agente verificou.
- Onde foi parar. A branch, o PR, a tarefa à qual pertence e quem o aceita.
Um agente que termina em silêncio, tecnicamente, concluiu o trabalho, mas você não consegue agir sobre ele. O estado concluído que importa é aquele que uma pessoa consegue inspecionar e aceitar. É por isso que “os testes passaram” não é a mesma coisa que “o trabalho está rastreado”.
O modelo human-in-the-loop para agentes de codificação traça a linha divisória: os agentes pesquisam, executam, testam e relatam; as pessoas definem a direção e aceitam o resultado. O rastreamento é a engrenagem que permite que a segunda metade aconteça.
A configuração faça-você-mesmo, passo a passo, e onde cada passo quebra
Para um agente em uma branch, as ferramentas nativas bastam. Aqui está a versão honesta, com o modo de falha nomeado em cada passo.
Passo 1: Veja o que mudou. Depois de uma execução, você lê o diff.
git log --oneline -10
git diff main...HEAD --stat
Falha quando: dois agentes compartilham uma branch, ou um agente não faz commit de nada e deixa alterações na árvore de trabalho de um worktree que você esqueceu que existia. O diff que você lê não é o diff que foi entregue.
Passo 2: Isole o trabalho de cada agente. Você dá a cada agente seu próprio git worktree para que não colidam.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
Falha quando: a lista cresce além do que você consegue manter na cabeça. git worktree list mostra os caminhos, não qual agente está em cada um, qual tarefa ele atende ou se já terminou. Consulte a documentação oficial do git-worktree para entender a mecânica; ela para na escrituração.
Passo 3: Verifique se os resultados chegaram a um PR. Você se apoia no GitHub.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
Falha quando: o PR existe, mas ninguém escreveu o porquê, ou as verificações estão verdes embora a alteração esteja errada, ou o PR não tem vínculo de volta com a solicitação que o originou. A referência do gh pr list mostra os PRs abertos, não a intenção.
Passo 4: Lembre o que você pediu. Esse passo não tem comando. O requisito original vive em uma mensagem do Slack, em uma nota ou na sua memória. Quando você revisa o PR três dias depois, está adivinhando os critérios de aceitação.
Cada passo funciona. O problema são as costuras entre eles. O diff, o isolamento, o PR e a intenção vivem em quatro sistemas que não se conhecem, e você é a única coisa que os conecta.
Onde a configuração manual para de escalar
A quebra não é um momento. É uma ladeira, e você consegue nomear onde está nela.
| Agentes em paralelo | O custo de rastrear | O que quebra primeiro |
|---|---|---|
| 1 | Ler um diff, um PR | Nada |
| 2 a 3 | Alternar o contexto entre worktrees | Você perde qual agente fez o quê |
| 4 a 6 | Reconstruir a intenção a cada PR | Os resultados ultrapassam sua capacidade de revisão |
| 7+ | Coordenação em tempo integral | O trabalho concluído fica dias sem revisão |
O custo real é medido em capacidade de revisão, não em velocidade dos agentes. Os agentes produzem trabalho concluído mais rápido do que uma pessoa consegue inspecioná-lo, então, passado um punhado de execuções, sua vazão é limitada pela velocidade com que você responde às três perguntas, e não pela velocidade com que os agentes codificam. Adicionar mais agentes piora o problema de rastreamento, não melhora o problema de entrega.
O que um quadro de tarefas acrescenta
A solução é parar de tratar uma execução concluída como um diff e começar a tratá-la como algo que retorna a uma tarefa.
Na Sharkly, a tarefa é o registro compartilhado. Você atribui uma tarefa a um agente ou a um Crew, e a execução acontece em um worktree isolado, de modo que agentes em paralelo nunca tocam os mesmos arquivos. Quando ela termina, a execução, os bloqueios, os resultados e os desdobramentos retornam para a linha do tempo da tarefa. O resumo das alterações, os resultados da verificação e os limites conhecidos ficam anexados à própria tarefa, e não a um terminal que você precisa manter aberto.
Essa é a diferença entre um log e um registro. Um log diz que algo aconteceu. Um registro diz o que mudou, se está correto e onde foi parar, tudo em um só lugar, vinculado à solicitação que o originou. Você revisa o trabalho concluído a partir da tarefa, aceita ou devolve, e a decisão leva o seu nome.
É aqui que as costuras do faça-você-mesmo se fecham. A intenção, o diff, as verificações e a aceitação vivem em um único objeto. Você mantém as ferramentas que seus agentes já usam; Claude Code e Codex continuam fazendo a execução, e a Sharkly acrescenta a camada de tarefa, contexto e revisão ao redor delas. Atribuir trabalho a um agente de IA passa a ser como atribuir a um colega de equipe, e o resultado volta para onde você consegue encontrá-lo.
Você pode baixar a Sharkly e conectar um Computer para testar isso em uma única tarefa real antes de escalar.
Quando você não precisa de nada disso
Seja honesto quanto ao limiar. Se você usa um único agente de codificação, em um único repositório, e lê cada diff antes de ele ser mesclado, o git e o seu terminal já rastreiam o trabalho concluído. Um quadro de tarefas só acrescentaria cerimônia desnecessária. A visão de projeto nativa do Claude Code cobre uma quantidade surpreendente para um fluxo de trabalho com um único agente.
A equação muda quando três coisas se acumulam: mais de dois agentes ao mesmo tempo, trabalho que você não consegue revisar no mesmo dia em que termina, e resultados que precisam chegar a alguém além de você. É aí que um registro compartilhado de tarefas deixa de ser sobrecarga e passa a ser a única forma de o trabalho concluído ficar visível, da solicitação até a entrega.
Uma checklist que você pode aplicar hoje
Antes de adicionar mais um agente, confirme que você consegue responder “sim” a cada um destes itens para os que já estão rodando:
- [ ] Para qualquer execução finalizada, você consegue encontrar o diff em menos de um minuto sem abrir um terminal?
- [ ] Cada execução concluída traz um resumo do que o agente verificou, e não apenas verificações verdes?
- [ ] Você consegue rastrear um PR de volta ao requisito que o originou?
- [ ] Existe um único lugar que mostra qual agente está em qual tarefa, o que terminou e o que precisa de revisão?
- [ ] Aceitar trabalho concluído tem o nome de uma pessoa vinculado a isso?
- [ ] Quando um agente termina, o resultado chega até você, ou você precisa ir buscá-lo?
Qualquer “não” é uma costura que vai se alargar conforme você adiciona agentes. Corrigi-la cedo sai mais barato do que reconstruir depois uma semana de execuções não rastreadas.
FAQ
Como faço para rastrear o que um agente de codificação com IA alterou? Leia o diff, não o resumo que o agente faz dele. Para um agente, o git diff e o PR bastam. Para vários, mantenha cada execução em seu próprio worktree e encaminhe o diff mais um resumo de verificação de volta a uma tarefa compartilhada, para não precisar reconstruí-lo a partir do histórico do terminal.
Posso rastrear o trabalho de agentes de IA apenas com o GitHub? Para um ou dois agentes, sim. O GitHub mostra os PRs abertos e o status das verificações. Ele não diz qual agente produziu um PR, qual tarefa ele atende ou se a alteração corresponde à intenção original, então ele perde força rápido quando vários agentes rodam em paralelo.
Quantos agentes posso rodar antes de precisar de um quadro de tarefas? A maioria das pessoas sente as costuras em torno de três a quatro agentes em paralelo, quando reconstruir a intenção a cada PR começa a consumir mais tempo do que a própria revisão. O gatilho é a capacidade de revisão, não um número fixo. Veja nossa observação sobre gerenciar agentes de codificação em paralelo.
Um quadro de tarefas deixa os agentes mais lentos? Não. Os agentes continuam executando em worktrees isolados a plena velocidade. O quadro acrescenta um caminho de retorno para que o trabalho concluído deles chegue a algum lugar onde você possa revisá-lo, o que elimina a etapa de reconstrução manual em vez de adicionar uma.
