Na primeira vez em que você roda três agentes de programação ao mesmo tempo, a execução deixa de ser a parte lenta. Você entrega um bug ao Claude Code, um refactor ao Codex e uma lacuna de cobertura de testes a um terceiro Runtime, e quarenta minutos depois três branches estão prontas. Aí começa a espera de verdade, porque as três agora estão esperando por você. Você lê o primeiro diff, aprova, e os outros dois ficam parados. Você tem execução paralela e revisão serial, então o paralelismo quase não rende nada.
Essa é a armadilha que pega toda equipe que fica boa em rodar agentes em paralelo. O gargalo não desaparece; ele se desloca, de “com que rapidez um agente escreve o código” para “com que rapidez uma pessoa lê, julga e aceita o resultado”. Adicionar um quarto agente só piora: uma fila maior de trabalho concluído, com o mesmo único revisor.
A solução não é revisar mais rápido nem confiar mais. É projetar a revisão como parte explícita do fluxo de trabalho, em vez de um pensamento tardio que existe só na sua cabeça. É esse fluxo de trabalho que este artigo percorre, e é em torno desse problema que o Sharkly foi construído: manter o objetivo, o diff, as evidências e a revisão de cada execução de agente em uma única Task, para que a fila de revisão se torne algo que você consegue ver e gerenciar, em vez de uma pilha de abas abertas no navegador.
Por que agentes em paralelo deslocam o gargalo para a revisão
A revisão é uma fila. Execuções concluídas de agentes chegam a um certo ritmo, uma pessoa as libera a um certo ritmo, e se as chegadas superam as liberações a fila cresce sem limite. É basicamente isso, e é por isso que a vazão bruta de agentes é a métrica errada a otimizar. Se dez agentes terminam em uma hora e você consegue aceitar com cuidado três mudanças por hora, você construiu uma fábrica cuja doca de carga é uma pessoa com uma prancheta.
A maioria das ferramentas esconde isso. Uma pilha de pull requests mostra o trabalho, mas não mostra quais itens estão de fato esperando uma decisão, quais ainda estão rodando e quais já foram integrados. A fila é real, mas está espalhada entre abas, notificações e memória. O primeiro objetivo de design é torná-la visível, porque não dá para gerenciar um gargalo que você não vê. Um artigo complementar sobre matemática da capacidade de revisão detalha o que acontece conforme a concorrência aumenta.
O modelo operacional: quem atribui, quem executa, quem revisa, quem aceita
Antes de mexer nos status, nomeie as quatro funções. São funções diferentes, e confundi-las é o que faz a revisão parecer caótica.
Alguém atribui o trabalho: transforma uma intenção em uma Task com escopo definido e critérios de aceite. Algo o executa: um Agent, em um Computer, rodando em um Runtime, produzindo uma mudança e um registro do que fez. Alguém revisa o resultado: lê o diff e as evidências e decide se ele atende aos critérios. Alguém o aceita: toma a decisão de integrar e liberar, que é uma decisão diferente de “o código parece bom”.
O Sharkly resume o contrato em uma frase que vale a pena colar num post-it: agentes pesquisam, executam, testam e reportam; pessoas definem a direção, concedem autoridade e aceitam o resultado. A automação para onde o julgamento da equipe é necessário. Atribuir e aceitar são humanos por design. Executar é do Agent. Revisar é a função que precisa ser projetada, porque é ali que a fila se forma.
Uma distinção útil: um PR integrado não é a mesma coisa que um resultado aceito. Fazer o merge é uma operação do git. Aceitar é uma pessoa decidindo que a mudança faz o que a Task pedia. Quando os dois se resumem a um clique, a qualidade da revisão cai para o que o revisor tinha de energia naquele minuto.
Papéis, status e portões de revisão
Dê forma à fila atribuindo às Tasks um pequeno conjunto de status pelos quais agentes e humanos transitam. Uma Task é a principal unidade de trabalho: ela guarda o objetivo, a conversa e a execução. A ideia dos status é que os agentes podem levar uma Task até o portão de revisão, e só uma pessoa pode fazê-la passar dele.
| Status | Quem move para cá | Significado |
|---|---|---|
| Backlog | Pessoa | Com escopo definido, ainda não iniciada. Nenhuma execução acontece aqui. |
| Ready | Pessoa | Liberada para execução; um Agent pode assumi-la. |
| In progress | Agent | Uma execução está rodando em um worktree isolado. |
| Ready for review | Agent | Execução concluída, mudança e evidências anexadas, aguardando uma pessoa. |
| Changes requested | Pessoa | Devolvida com um comentário; uma execução de acompanhamento continua na mesma Task. |
| Done | Pessoa | Aceita, integrada, liberada. |
O portão é a transição para Ready for review e a saída para Done. Os agentes conseguem chegar ao portão sozinhos; não conseguem passá-lo. Essa única regra é o que permite rodar dez agentes com segurança: eles preenchem a coluna Ready for review em paralelo, e você a esvazia no ritmo que mantiver a qualidade honesta. O comprimento da coluna é o seu gargalo, tornado visível.
Aqui está o par de decisões honesto. Coloque um portão em toda mudança que chega aos usuários ou toca dinheiro, autenticação, migrações de dados ou APIs públicas. Não coloque portão em spikes descartáveis, boilerplate gerado que você vai regenerar de qualquer forma, ou trabalho atrás de uma flag que ninguém consegue alcançar ainda. Um portão em tudo só devolve o gargalo para o revisor em mudanças que nunca precisaram de um humano. Portões de aprovação aborda onde colocar a parada para trabalhos de maior risco.
Projete a revisão para que ela escale
Revisar a saída de agentes em paralelo não é o mesmo que revisar o PR de um colega de equipe. Você tem mais volume, ele chega em rajadas e muitas vezes você sabe menos sobre como foi produzido. Três medidas mantêm baixo o custo por item para o revisor.
Anexe as evidências à Task, não à sua memória. Uma execução deve retornar o resumo da mudança, a saída do typecheck e dos testes, o resultado do build e os limites conhecidos, tudo registrado. Quando você abre um item em Ready for review, está lendo um dossiê, não reconstruindo o que aconteceu. É a diferença entre revisar com evidências no nível da Task e rodar tudo de novo você mesmo para recuperar a confiança.
Revise a decisão, não as teclas digitadas. Propriedades verificáveis por máquina — formatação, segurança de tipos, se os testes passam — devem ser validadas por máquinas antes que a Task chegue até você. O guia de revisão de código do Google faz a mesma divisão: automatize o que uma ferramenta consegue verificar, para que a pessoa gaste atenção em design e adequação. Seu julgamento escasso vai para “essa é a mudança certa”, não para “isso compilou?”.
Limite o trabalho em andamento. Um limite rígido de quantas Tasks ficam em In progress ao mesmo tempo impede que a coluna Ready for review se torne um muro que você nunca vai escalar. É a ideia do limite de WIP do kanban aplicada a agentes: iniciar uma sexta execução quando cinco já esperam por você não aumenta a vazão, apenas esconde a fila. Também ajuda monitorar os agentes em execução para distinguir uma execução travada de uma lenta antes que ela chegue ao portão.
Um exemplo prático, do ticket ao PR integrado
Pegue uma Task realista, SH-312: “Aplique rate limit no endpoint público de busca”. Uma pessoa a molda no Backlog com critérios de aceite (429 após N requisições por minuto por chave, header documentado, um teste) e a move para Ready.
Três Agents estão trabalhando no Space em paralelo. Um deles assume a SH-312, clona o repositório configurado em um Computer e roda em um worktree isolado, para que sua branch nunca colida com as outras duas execuções em andamento. Ele escreve o limitador, adiciona um teste, roda o typecheck e a suíte, abre um PR cujo título carrega o ID da Task e move a SH-312 para Ready for review com o resumo da mudança, a saída dos testes passando e um limite conhecido registrado: o contador é em processo, não compartilhado entre instâncias.
Você abre a Task, e não quinze abas. As evidências estão ali mesmo, e a nota sobre o limite conhecido é a parte útil: os testes passam, mas o estado compartilhado entre instâncias é uma decisão de design que você precisa tomar. Você deixa um comentário e a move para Changes requested. Esse comentário inicia uma execução de acompanhamento na mesma Task; o Agent troca o contador por um armazenamento compartilhado e retorna evidências atualizadas. Desta vez, você aceita. Mover a SH-312 para Done é sua decisão, registrada como uma mudança de status com o seu nome, e não um efeito colateral silencioso de um merge no git.
Enquanto isso, os outros dois Agents estão parados em Ready for review. Como a fila é uma coluna e não a sua caixa de entrada, você os libera em seguida, na ordem, sem perder o fio da meada.
A fronteira que você reserva para as pessoas
Agentes em paralelo são uma história de vazão até o momento em que a revisão se torna a restrição; a partir daí, são uma história de filas. As equipes que extraem valor de muitos agentes tratam a revisão como infraestrutura projetada: status explícitos, um portão que os agentes alcançam mas não cruzam, evidências na Task, verificações automáticas antes das humanas e um limite de quanto trabalho pode estar em voo.
Você pode construir isso à mão com worktrees, uma convenção de nomes de branch e disciplina. Ou pode deixar o Sharkly gerenciar o fluxo: Agents atribuíveis, Tasks que carregam a execução e suas evidências, e um quadro em que Ready for review é uma coluna que você esvazia — assim os agentes pesquisam, executam, testam e reportam, enquanto as pessoas ficam com a última decisão. Se você já roda vários agentes, esse é um lugar para gerenciar as tarefas e os resultados deles, em vez de contar com a memória.
FAQ
Rodar agentes em paralelo economiza tempo se a revisão é serial? Só até o ponto em que execuções concluídas chegam mais rápido do que você consegue aceitá-las. Depois disso, agentes extras aumentam a fila de revisão sem entregar nada mais cedo. O ganho vem de tornar a revisão visível e de colocar portões apenas no que precisa de um humano.
Toda mudança de agente deve passar por revisão humana? Não. Coloque portões em mudanças que chegam aos usuários ou tocam autenticação, dados, dinheiro ou APIs públicas. Deixe passar trabalho de baixo risco ou regenerável apenas com verificações automáticas. Colocar portão em tudo devolve o gargalo para o revisor em mudanças que nunca precisaram disso.
Fazer o merge do PR não é o mesmo que aceitar o trabalho? Não. O merge é uma operação do git; aceitar é uma pessoa decidindo que a mudança atende aos critérios da Task. Manter os dois separados preserva a qualidade da revisão quando o volume é alto. Veja agentes de programação com human-in-the-loop para saber onde manter a decisão humana.
