Você começou rodando dois agentes de código ao mesmo tempo porque um só era lento demais. Agora você roda cinco, e a parte difícil não é iniciá-los. É lembrar qual terminal tem qual agente, o que cada um mudou, qual branch é seguro fazer merge, e se aquele que ficou quieto há quarenta minutos terminou ou travou. O paralelismo foi a vitória fácil. Acompanhar tudo isso é o imposto que você paga todo dia depois.
Esse imposto é o que as ferramentas faça-você-mesmo para agentes paralelos tentam reduzir. Conductor, Claude Squad e scripts caseiros de tmux mais git worktree resolvem todos o mesmo primeiro problema: dar a cada agente seu próprio espaço de trabalho isolado, para que várias execuções avancem ao mesmo tempo sem pisar nos arquivos umas das outras. Eles resolvem isso bem, e para um desenvolvedor solo em uma única máquina podem ser tudo o que você precisa. Este é um comparativo honesto do que cada um faz, até onde cada um vai, e a linha em que o gerenciamento de janelas silenciosamente se torna um problema de equipe.
É nessa linha que o Sharkly entra, e é esse o fluxo de trabalho que este artigo apresenta a você. O Sharkly não substitui o Claude Code, o Codex nem qualquer executor faça-você-mesmo. Ele é a camada compartilhada de Task, Computer, contexto e revisão em torno das ferramentas que você já usa, para que o trabalho dos agentes permaneça visível da solicitação à entrega, em vez de desaparecer em terminais privados. Se sua configuração ainda cabe em uma tela, mantenha. Se parou de caber semanas atrás, a segunda metade deste texto é para você.
TL;DR
Conductor, Claude Squad e tmux puro mais git worktrees são três formas de rodar vários agentes de código de IA em paralelo na sua própria máquina. O Conductor é um app gratuito para Mac, feito para execuções solo e locais. O Claude Squad é um app de terminal multiplataforma que adiciona um alternador sobre sessões tmux e git worktrees. tmux puro mais scripts de worktree dão controle total e zero abstração. Os três dominam a execução paralela. Nenhum deles foi feito para dar a uma equipe visibilidade compartilhada, revisão ou repasses, e é exatamente nesse ponto que você passa para uma camada de orquestração como o Sharkly.
O verdadeiro gargalo não é o paralelismo
Isolamento é um problema resolvido. Um git worktree permite que um único repositório faça checkout de várias branches em diretórios separados ao mesmo tempo, então cada agente edita sua própria cópia do código e faz commit na sua própria branch. Sem árvore de trabalho compartilhada, sem diffs meio aplicados colidindo. Todas as ferramentas nesta comparação se apoiam nessa mesma primitiva. Se você quer os detalhes mecânicos a fundo, nosso guia sobre git worktrees com agentes de código de IA cobre os comandos e as pegadinhas.
Então, se o isolamento é de graça, por que rodar muitos agentes ainda parece caótico? Porque o trabalho que um agente produz precisa ir para algum lugar onde um humano possa encontrá-lo, lê-lo, julgá-lo e agir sobre ele. Em uma única máquina, esse “algum lugar” é a sua própria memória de curto prazo mais um buffer de histórico de rolagem. Isso aguenta dois agentes. Desanda com cinco. Quebra no momento em que uma segunda pessoa precisa saber o que qualquer um dos seus agentes fez.
Aqui está a divisão que importa. Rodar agentes em paralelo é um problema de runtime: iniciar o processo, entregar a ele um diretório isolado, deixá-lo trabalhar. Revisar e coordenar o que eles produzem é um problema de fluxo de trabalho: onde o resultado fica, quem o aprova, o que acontece com aqueles que travam. As ferramentas faça-você-mesmo são excelentes no primeiro problema. As três seções abaixo avaliam cada uma segundo seus próprios critérios, e depois olhamos o que acontece com o segundo problema conforme sua configuração cresce.
Conductor: o app gratuito para Mac para execuções paralelas solo
O Conductor é um app nativo de desktop para Mac que roda vários agentes do Claude Code lado a lado. Você aponta para um repositório, descreve uma mudança, e ele cria cada execução em seu próprio espaço de trabalho apoiado por um git worktree. Em vez de fazer malabarismo com abas de terminal, você tem uma visão em janelas: uma coluna por agente, cada uma com sua própria conversa, diff e status. Você clica entre elas como clicaria entre conversas de chat.
O que ele faz bem é eliminar a burocracia de terminal para uma pessoa. Você não digita nada de tmux. Você não precisa lembrar qual painel é qual. O app rastreia os worktrees, mostra os diffs em um visualizador de diff de verdade e permite saltar entre agentes sem perder o lugar. Para um desenvolvedor solo em um Mac que quer rodar três ou quatro sessões do Claude Code em uma base de código e continuar são, é uma resposta limpa e de baixo atrito. O download é gratuito, e não há nada para configurar em um servidor porque não existe servidor.
As limitações são o outro lado desses pontos fortes. O Conductor é exclusivo para macOS, então um colega de equipe no Linux não pode compartilhar sua configuração. Ele é construído em torno do Claude Code como runtime, em vez de uma mistura de agentes. E é um app de desktop para um único usuário: os espaços de trabalho, os diffs e as decisões ficam no seu Mac. Outro engenheiro não pode abrir seu Conductor e ver o que seus agentes estão fazendo, e não há registro compartilhado de quem aceitou qual mudança. Isso não é uma falha. É um escopo. O Conductor é um cockpit para um piloto só.
Use o Conductor quando você for um desenvolvedor solo em um Mac rodando Claude Code e quiser o caminho mais rápido de “muitos terminais” para “uma janela tranquila”. Procure outra coisa quando uma segunda pessoa precisar ver, revisar ou assumir qualquer uma dessas execuções.
Claude Squad: tmux e worktrees com uma TUI por cima
O Claude Squad é uma aplicação de terminal de código aberto que gerencia vários agentes em espaços de trabalho isolados. Por baixo do capô, ele faz o que um engenheiro cuidadoso escreveria à mão em script: cria um git worktree por agente e roda cada agente dentro de sua própria sessão tmux, depois coloca uma interface de texto por cima para que você possa listar seus agentes, entrar em qualquer um deles e ver quais estão trabalhando, esperando ou concluídos. É multiplataforma, roda em macOS e Linux e não está preso a um único runtime. Ele pode comandar Claude Code, Codex, Aider e outros agentes de CLI, o que o torna um favorito entre desenvolvedores que misturam ferramentas. O código-fonte está no repositório do Claude Squad no GitHub.
O apelo é que ele oferece a ergonomia de uma ferramenta de verdade sem esconder as primitivas em que você confia. Você continua tendo worktrees e tmux, então nada é mágico e tudo é inspecionável, mas você para de escrever a cola à mão. Criar um novo agente é uma tecla, não um ritual de três comandos. Pausar um agente libera seus recursos e preserva sua branch. Se você já vive no terminal e quer uma frota de agentes pela qual possa alternar com Tab, o Claude Squad acerta um ponto ideal que scripts puros e apps de desktop deixam passar. Nosso passo a passo sobre como rodar vários agentes do Claude Code em paralelo mostra o mesmo padrão de tmux e worktree que ele automatiza.
Seus limites são os limites do terminal em que ele vive. O estado é local à sua máquina e ao seu shell. Quando você fecha a sessão, o panorama compartilhado fecha junto. Não há uma linha do tempo que um gestor possa abrir, não há um lugar onde um revisor que não é você possa aceitar ou rejeitar uma mudança, não há uma fila de onde um colega de equipe possa puxar a próxima tarefa. O Claude Squad é um centro de comando excelente para um único operador. Ele nunca tentou ser o sistema de registro de uma equipe, e pedir isso a ele é pedir à ferramenta errada.
Use o Claude Squad quando você for um desenvolvedor que vive no terminal, rodando uma mistura de agentes em uma máquina, e quiser um alternador rápido sem abrir mão de worktrees e tmux. Procure outra coisa quando as execuções precisarem ser atribuíveis a outras pessoas ou revisáveis por alguém que não está sentado ao seu teclado.
tmux puro mais git worktrees: os scripts que são seus
A configuração faça-você-mesmo mais honesta também é a mais antiga: alguns shell scripts que criam worktrees e abrem janelas do tmux, uma por agente. É assim que fica.
# one worktree and one branch per parallel unit of work
git worktree add ../app-auth -b feature/auth
git worktree add ../app-billing -b feature/billing
# a named tmux window per agent, launched in its worktree
tmux new-window -n auth -c ../app-auth 'claude'
tmux new-window -n billing -c ../app-billing 'claude'
Dois comandos por funcionalidade e você tem agentes isolados rodando em paralelo, cada um em sua própria branch, cada um em uma janela rotulada para a qual você pode alternar com uma tecla. Envolva isso em um loop e você pode lançar uma dúzia. Nada fica entre você e as ferramentas. Você pode ler cada linha, mudar qualquer coisa e isso não custa nada além do tempo de escrever.
Para um certo tipo de desenvolvedor, essa é a resposta certa para sempre, e vale a pena respeitá-la em vez de tentar convencer alguém do contrário. Você entende exatamente o que roda porque você escreveu. Não há fornecedor, nenhuma atualização que quebra seu fluxo, nenhuma abstração vazando na hora errada. Se suas necessidades são estáveis e pessoais, scripts que são seus vencem ferramentas que você aluga.
O custo aparece conforme sua configuração cresce, e aparece como manutenção, não como recursos. A limpeza é por sua conta: worktrees obsoletos se acumulam até que git worktree prune e uma varredura de tmux kill-session se tornem parte da sua rotina. Colisões de nomes são por sua conta. Um agente que travou deixa uma janela morta e uma branch pela metade, e perceber isso é por sua conta. E nada disso sai da sua máquina, então no momento em que um colega pergunta “o que seus agentes entregaram esta semana”, a única resposta vive no seu histórico de rolagem. Os scripts escalam sua produtividade. Eles não escalam sua capacidade de compartilhar o resultado.
Use tmux puro e scripts de worktree quando você quiser controle total, gostar de ser dono do seu ferramental e o público do trabalho for você. Procure outra coisa quando você se pegar reconstruindo rastreamento de status, limpeza e lógica de repasse que começa a parecer um produto que você não pretendia escrever.
Comparativo lado a lado: o que cada configuração faça-você-mesmo faz bem
| Conductor | Claude Squad | tmux puro + worktrees | |
|---|---|---|---|
| Interface | App nativo para Mac | Interface de terminal (TUI) | Seus próprios shell scripts |
| Plataforma | Somente macOS | macOS, Linux | Onde o tmux rodar |
| Runtimes | Foco em Claude Code | Claude Code, Codex, Aider e mais | O que você lançar |
| Isolamento | git worktree por execução | git worktree por agente | git worktree por agente |
| Custo de configuração | Instalar e abrir | Instalar um binário | Escrever e manter scripts |
| Melhor para | Desenvolvedor solo no Mac | Dev solo que vive no terminal | Dev solo maximalista de controle |
| Visão compartilhada da equipe | Não | Não | Não |
| Revisão e aprovação por outras pessoas | Não | Não | Não |
As duas últimas linhas não são uma crítica. São o padrão. Cada uma dessas ferramentas foi feita para um operador em uma máquina, e dentro desse escopo elas vão de boas a excelentes. A coluna vazia é a mesma nas três, e é a coluna que importa no dia em que o trabalho deixa de ser só seu. Para um mapa mais amplo da categoria, veja nossa visão geral de orquestração de agentes de IA.
A linha da graduação: quando gerenciar janelas deixa de ser o problema
Aí está o sinal. Você para de perguntar “como faço para rodar mais agentes ao mesmo tempo” e começa a fazer perguntas que as ferramentas faça-você-mesmo não conseguem responder:
- Quais mudanças dos meus agentes alguém revisou?
- Se eu ficar doente, um colega consegue ver o que está em andamento e assumir?
- Onde está o registro de por que aceitamos este diff e rejeitamos aquele?
- Quais execuções estão bloqueadas, por causa de quê e há quanto tempo?
Essas são perguntas de fluxo de trabalho, não de runtime. Nenhum alternador melhor ou visualizador de diff mais bonito as responde, porque a peça que falta não está na sua tela. É um lugar compartilhado onde o trabalho possa viver. Essa é a linha da graduação: o dia em que seu gargalo passa de gerenciar janelas para gerenciar visibilidade, revisão e repasses.
O Sharkly foi construído para o outro lado dessa linha. Ele mantém contexto, progresso, bloqueios, resultados e revisão humana visíveis da solicitação à entrega, em um único fluxo de trabalho compartilhado em vez de espalhados por terminais privados. A divisão do trabalho é deliberada: Claude Code, Codex e ferramentas semelhantes fazem a execução; o Sharkly gerencia a atribuição no nível da equipe, os Computers conectados, o contexto das tarefas, o progresso, os bloqueios, os resultados e a revisão humana entre essas ferramentas. Você mantém os runtimes e os worktrees em que já confia. Você adiciona a camada que permite que mais de uma pessoa veja e direcione o trabalho.
A garantia importa tanto quanto o mecanismo. Adotar o Sharkly não exige que você reconstrua seu processo nem abandone suas ferramentas. Você traz sua própria assinatura: o uso do modelo continua pelas assinaturas ou chaves de API configuradas nas ferramentas que sua equipe já usa. Você conecta um Computer, aponta o Sharkly para os mesmos repositórios e começa a encaminhar trabalho sem desmontar nada. Se você está comparando isso com um quadro local, nosso texto sobre alternativa ao Vibe Kanban cobre o mesmo caminho de manter o que você já tem.
Como o mesmo fluxo de trabalho paralelo fica no Sharkly
As ferramentas faça-você-mesmo dão a cada agente um worktree e uma janela. O Sharkly dá a cada unidade de trabalho uma Task e deixa os Agents executá-la em worktrees isolados da mesma forma, com uma diferença: o resultado volta para a Task em vez de ficar no seu histórico de rolagem.
Uma Task é a principal unidade de trabalho no Sharkly. Ela carrega o objetivo, o escopo, o diff, a discussão e a revisão em um único registro compartilhado. Quando você atribui uma Task a um Agent, o Agent a assume, trabalha em seu próprio worktree isolado, roda typecheck, testes e build, e então anexa de volta àquela Task o resumo das mudanças, os resultados da verificação e os limites conhecidos. A próxima pessoa que for olhar não precisa do seu terminal. Ela abre a Task.
A menor versão útil é deliberadamente sem graça. Conecte um Computer, crie um Agent e atribua a ele uma Task de baixo risco, da mesma forma que nosso passo a passo da primeira tarefa monta isso. A partir daí, a história paralela escala do jeito que seus scripts queriam: vários Agents assumem Tasks prontas e trabalham ao mesmo tempo, cada um isolado, enquanto frontend, backend, correção de bugs e cobertura de testes avançam em paralelo. A diferença em relação a uma parede de janelas do tmux é que toda execução é atribuível a uma pessoa, revisável por alguém que não é você e rastreável depois dos fatos.
O contrato entre humano e agente é onde a camada de revisão justifica sua existência. Os agentes pesquisam, executam, testam e relatam. As pessoas definem a direção, concedem autoridade e aprovam o resultado. A automação para onde o julgamento da equipe é necessário, e devolve uma entrega com contexto completo e evidências inspecionáveis. Uma configuração faça-você-mesmo consegue rodar os agentes. Ela não consegue sustentar esse contrato, porque não tem um lugar compartilhado para uma pessoa que não seja você aprovar ou rejeitar. Se você quer a mecânica desse portão, nossa nota sobre agentes em segundo plano do Cursor percorre um fluxo de revisão semelhante.
Exemplo prático, no formato que as equipes usam. Uma tarefa como SH-312 diz “adicione limitação de taxa à API pública”. Um Agent molda o escopo, trabalha em seu worktree, roda os testes e devolve um resumo mais o diff para a Task. Seu revisor abre SH-312, lê as evidências e aprova ou solicita mudanças. Quando você era solo, todo esse ciclo vivia na sua cabeça e em um terminal. Agora ele vive em algum lugar que a equipe consegue ver, que é o ponto principal de dar esse salto.
Quem deve ficar, quem já superou essa fase
Uma comparação que só empurra para cima não é honesta, então aqui vai a versão sem rodeios. Muita gente não deveria migrar, e as ferramentas acima são o lugar certo para elas.
- Fique no Conductor se você for um desenvolvedor solo em Mac que quer execuções paralelas do Claude Code em uma janela tranquila e ninguém mais precisa vê-las. Ele faz esse trabalho com limpeza e não exige nada de um servidor.
- Fique no Claude Squad se você vive no terminal, roda uma mistura de runtimes e quer um alternador rápido sobre worktrees e tmux para o seu próprio trabalho. É um centro de comando forte para um único operador.
- Fique no tmux puro e nos scripts de worktree se você valoriza controle total, seu fluxo de trabalho é estável e você é o único público do resultado. Ferramental próprio vence ferramental alugado quando as necessidades são pessoais.
- Migre para o Sharkly quando o trabalho deixar de ser só seu: quando um colega precisar revisar uma execução, quando alguém tiver de assumir enquanto você estiver fora, quando um gestor precisar ver o que está bloqueado, ou quando você perceber que está reconstruindo rastreamento de status e lógica de repasse à mão. Nossa visão geral de orquestração mapeia onde as camadas se encontram.
O par de decisão para toda a categoria é curto. Use uma ferramenta faça-você-mesmo quando a restrição for sua própria máquina e seu próprio tempo. Use uma camada de orquestração quando a restrição for o entendimento compartilhado da sua equipe sobre o que os agentes fizeram. A maioria dos desenvolvedores começa à esquerda e cruza a linha na semana em que o nome de uma segunda pessoa aparece no trabalho.
Cenários do mundo real
O construtor solo que fica onde está. Um desenvolvedor freelancer entrega funcionalidades para clientes com três ou quatro agentes do Claude Code em um Mac. O Conductor ou o Claude Squad é a resposta inteira, e adicionar uma camada de equipe seria peso sem retorno. Ficar é a decisão certa.
A equipe de duas pessoas que acabou de cruzar a linha. Um fundador e o primeiro engenheiro rodavam, cada um, seus próprios scripts de tmux. Nenhum conseguia revisar o trabalho dos agentes do outro sem compartilhar a tela. Mover as execuções para Tasks compartilhadas no Sharkly fez com que cada um pudesse abrir o diff do outro, aprová-lo e fazer merge, sem mudar os runtimes que ambos já usavam.
O líder padronizando um time. Um tech lead com cinco engenheiros descobriu que cada um tinha um script de worktree um pouco diferente e nenhuma revisão compartilhada. Agents compartilhados e um fluxo comum de Tasks transformaram cinco configurações privadas em um fluxo de trabalho que a equipe podia reutilizar, enquanto cada engenheiro mantinha seu próprio Computer e sua própria assinatura de modelo.
Perguntas frequentes
Qual é a diferença entre o Claude Squad e o Conductor? O Claude Squad é um app de terminal multiplataforma que gerencia agentes sobre tmux e git worktrees e suporta vários runtimes. O Conductor é um app de desktop para macOS focado em rodar o Claude Code em uma interface em janelas. Ambos isolam cada execução em seu próprio worktree; a diferença é terminal versus app nativo, e multiplataforma versus somente Mac.
Preciso do Claude Squad ou do Conductor se eu já uso git worktrees? Não necessariamente. Ambos são conveniências sobre a mesma primitiva de worktree. Se você se sente à vontade escrevendo alguns comandos de tmux e git worktree, scripts puros lhe dão o mesmo isolamento com mais controle. As ferramentas compram ergonomia e limpeza, não uma nova capacidade.
Essas ferramentas faça-você-mesmo conseguem lidar com revisão de equipe? Não, e elas não dizem que conseguem. Conductor, Claude Squad e scripts de tmux mantêm todo o estado em uma máquina para um operador. Revisão compartilhada, aprovação por outra pessoa e um registro durável de decisões são recursos de fluxo de trabalho que vivem em uma camada de orquestração, não em um executor local. Veja nosso texto sobre alternativa ao Vibe Kanban para essa distinção.
O Sharkly substitui o Claude Code ou o Claude Squad? Não. O Sharkly não substitui o Claude Code, o Codex nem outras ferramentas de execução. Ele adiciona a camada compartilhada de Task, Computer, contexto, controle e revisão em torno das ferramentas que sua equipe já usa. Você mantém seus runtimes e seus worktrees e ganha visibilidade no nível da equipe por cima.
Migrar para o Sharkly significa abrir mão dos git worktrees? Não. O Sharkly também roda Agents em worktrees isolados, então o isolamento com que você conta permanece. O que muda é para onde o resultado vai: ele volta para uma Task compartilhada em vez de um buffer de terminal privado.
Como mantenho meu uso de modelo e meus custos quando faço a migração? Você traz sua própria assinatura. O uso do modelo continua pelas assinaturas ou chaves de API configuradas nas ferramentas que sua equipe conecta, e a cota do modelo depende dessas ferramentas, planos e contas de API. O Sharkly adiciona a camada de coordenação, não uma nova relação de cobrança.
Pronto para cruzar a linha? Baixe o Sharkly, conecte um Computer e atribua um requisito real a um único Agent. Mantenha os runtimes e worktrees em que você já confia, e deixe o trabalho começar a voltar para um lugar que toda a sua equipe consegue ver. A documentação aprofunda cada conceito em docs.sharkly.ai.



