Você inicia um agente de código em uma tarefa real, fecha o notebook e vai almoçar. Essa parte é fácil. A parte difícil é o que você encontra quando volta: um terminal cujo conteúdo já rolou para fora da tela, um diff que você não viu ser escrito e nenhuma resposta clara para a única pergunta que importa: se o trabalho está bom o suficiente para ser mantido.
Executar um agente sem supervisão tem duas metades, e a maioria das configurações resolve apenas a primeira. A primeira metade é manter o processo vivo e produtivo enquanto ninguém está olhando. A segunda metade é a fila de revisão: a pilha de execuções concluídas, semiconcluídas e falhas esperando uma decisão humana quando você volta. Se você ignorar a segunda metade, os agentes sem supervisão apenas deslocam o gargalo de escrever código para reconstruir o que aconteceu.
Este artigo aborda as duas metades: como montar você mesmo uma execução sem supervisão, o modo de falha em cada etapa e onde essa configuração faça-você-mesmo deixa de escalar. Quando um terminal se torna cinco, um quadro de tarefas como o Sharkly fica acima dos seus agentes de código. Você mantém o Claude Code, o Codex ou o Gemini CLI fazendo o trabalho, e o Sharkly concentra a tarefa, a execução e a revisão em um único lugar, em vez de espalhá-las por terminais que você já fechou.
O que realmente envolve executar um agente sem supervisão
Uma execução sem supervisão é um agente de código executando uma tarefa em um host que você não está acompanhando ativamente, com sua saída capturada para revisão posterior. Essa definição tem três partes essenciais: uma tarefa que o agente consegue concluir sem você, um host que continua rodando quando você se desconecta e um registro que você pode ler depois.
O registro é a parte que as pessoas subestimam. Quando você acompanha um agente ao vivo, você é o log: você vê quando ele escolhe o arquivo errado, interrompe, corrige o rumo. Sem supervisão, nada disso acontece. Tudo o que o agente fez precisa sobreviver de uma forma que você possa inspecionar a frio, horas depois, sem lembrar do que pediu. Agentes pesquisam, executam, testam e relatam. Pessoas definem a direção, concedem autoridade e aceitam o resultado. Esse contrato só se sustenta se o relatório for real e completo quando você voltar a ele.
Portanto, o objetivo não é “fazer o agente rodar sem mim”. É “fazer o agente rodar sem mim e devolver algo que eu possa revisar”. São problemas diferentes, e é no segundo que os fluxos de trabalho sem supervisão costumam quebrar.
Montando você mesmo uma execução sem supervisão
Aqui está a versão manual mínima, com o modo de falha que ataca em cada etapa.
Etapa 1: isole o trabalho. Dê à execução seu próprio checkout para que ela não colida com o seu editor ou com outro agente.
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
Modo de falha: se você pular esta etapa e houver duas execuções no mesmo diretório, elas sobrescrevem as alterações não commitadas uma da outra. Veja um checkout por tarefa para entender por que os worktrees, e não apenas as branches, são a fronteira de isolamento.
Etapa 2: desacople o processo. Sua sessão SSH ou terminal vai fechar, e um processo em primeiro plano morre junto (SIGHUP). Mantenha-o vivo com nohup ou uma sessão tmux:
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
Modo de falha: se você o executar em um shell comum em primeiro plano, fechar a tampa mata o agente no meio de uma edição de vários arquivos e deixa a árvore quebrada. O nohup resolve o tempo de vida, mas não oferece como voltar; o tmux permite reconectar e ver o que está acontecendo.
Etapa 3: capture tudo. O > run.log 2>&1 acima não é opcional. É a fila de revisão em sua forma mais crua.
Modo de falha: sem um log capturado, você não consegue responder “por que ele parou?”. A parada silenciosa mais comum é um agente esperando para sempre por um prompt interativo que ninguém vai responder, porque sem supervisão significa que não há ninguém ali para digitar “sim”. Execute em modo não interativo e pré-aprove o conjunto restrito de ações de que a tarefa precisa.
Etapa 4: limite o raio de impacto. Decida, antes de sair, o que o agente pode fazer sozinho e o que precisa de você. Restrinja o escopo de arquivos, proíba o force-push e nunca deixe uma execução sem supervisão fazer merge em uma branch protegida.
Modo de falha: uma execução com permissões excessivas que faz push direto para a main não é um ganho de produtividade, é um incidente. Os portões de aprovação existem para que o agente pare no último ponto seguro e espere.
Etapa 5: saiba quando terminou e como. Verifique o código de saída e envie um aviso para você mesmo, para não ficar consultando um log manualmente:
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
Modo de falha: sem um sinal de conclusão, “sem supervisão” vira “eu verifico o terminal a cada vinte minutos”, o que é apenas uma execução supervisionada com latência extra.
Onde a configuração faça-você-mesmo deixa de escalar
Um agente, um worktree, um arquivo de log: isso funciona, e para uma única execução você não precisa de nada mais pesado. A configuração quebra no momento em que há mais de uma.
Execute três agentes em três tarefas e agora você tem três worktrees, três arquivos de log, três códigos de saída e três e-mails de conclusão que você vai interpretar errado de relance. O isolamento continua funcionando. O que desmorona é a fila de revisão. Nada diz qual execução terminou limpa, qual falhou nos testes e qual está esperando silenciosamente por um prompt. Você reconstrói isso manualmente, lendo os logs um de cada vez, que é exatamente o trabalho que você estava tentando delegar.
Esse é o custo real, e é fácil de passar despercebido porque cada peça parece boa isoladamente. Monitorar várias execuções paralelas se torna um problema de verdade quando a quantidade ultrapassa o que uma tela mostra. Um arquivo de log responde “o que esta execução imprimiu”, não “das minhas seis execuções, quais três precisam de mim agora”. Os sinais de status e de falha que vale a pena capturar não se organizam sozinhos em uma fila. E a fila é o ponto central de trabalhar enquanto você está fora: você quer uma lista classificada de decisões, não um diretório de saída bruta.
O que um quadro de tarefas muda
É em um quadro de tarefas que a segunda metade do problema é resolvida. A execução sem supervisão continua acontecendo em um Computer que você conecta, com o seu Runtime atual fazendo a codificação. O que muda é onde o resultado chega.
No Sharkly, o trabalho, a execução e a revisão ficam em uma única Task. Você atribui a Task a um Agent, uma configuração salva de instruções, Runtime e repositórios, e não um prompt avulso que você digita de novo. O Agent assume a Task, executa em um worktree isolado, e sua execução, seus bloqueios e seus resultados retornam para a linha do tempo da Task. Quando você volta, não precisa fazer grep em seis arquivos de log. Você abre o quadro e lê a fila: o que terminou, o que falhou, o que está esperando por você.
Vale deixar essa fronteira clara. O Sharkly não substitui o Claude Code, o Codex ou outras ferramentas de execução. Ele adiciona a camada compartilhada de tarefa, Computer, contexto e revisão em torno das ferramentas que sua equipe já usa. O agente continua escrevendo o código. O Sharkly garante que, enquanto você estava fora, o código voltou para algum lugar onde você pode vê-lo, com o resumo de alterações e os resultados dos testes anexados, e que a aceitação final continua sendo uma decisão humana. A automação para onde o julgamento é necessário.
Você pode construir tudo isso manualmente com worktrees, nohup e um comando de e-mail. A regra de decisão honesta: se você executa um agente ocasionalmente, a configuração manual dá conta e o Sharkly é uma sobrecarga de que você não precisa. A equação muda quando vários agentes rodam em diferentes tarefas e repositórios e a fila de revisão se torna aquilo em que você gasta a manhã. Se você quer continuar usando vários agentes de código em vez de se comprometer com um único ecossistema, essa fila é o problema em torno do qual o Sharkly foi projetado.
A fila de revisão é o gargalo de verdade
Aqui está a premissa que vale a pena contestar: as pessoas otimizam a execução sem supervisão e tratam a revisão como algo secundário. É o contrário. Rodar agentes em paralelo enquanto você dorme só é vantagem se revisar a saída deles na manhã seguinte for mais rápido do que teria sido fazer o trabalho você mesmo. Quando cinco agentes terminam durante a noite e revisar todos os cinco diffs leva mais tempo do que escrever dois deles, o paralelismo não produziu nada.
Portanto, projete a fila de revisão primeiro. Defina o que “concluído” precisa incluir antes que uma execução chegue até você: testes passando, uma verificação de tipos, um resumo das alterações e uma nota sobre limites conhecidos. Ordene a fila por risco, não por horário de término, para que a execução que mexeu na autenticação chame sua atenção antes daquela que corrigiu um erro de digitação. Faça com que “solicitar alterações” seja tão barato quanto “aprovar”, porque metade das execuções sem supervisão estará quase certa, mas não totalmente. A revisão é o gargalo em qualquer fluxo de trabalho com agentes paralelos, e onde os agentes rodam fisicamente, seu servidor, seu notebook ou ambos, importa muito menos do que se a saída deles chega como uma fila que você consegue esvaziar.
Uma checklist para usar hoje mesmo
Antes de se afastar de um agente, confirme:
- Isolamento: a execução tem seu próprio worktree, não o seu checkout de trabalho.
- Tempo de vida: o processo sobrevive a uma desconexão (
nohup,tmuxou um Computer gerenciado), então fechar a tampa não o mata no meio da edição. - Captura: stdout e stderr vão para um log durável ou uma linha do tempo de Task que você consegue ler a frio.
- Não interativo: o agente não vai travar em um prompt que ninguém está ali para responder.
- Raio de impacto: o escopo de arquivos é limitado, o force-push está desativado e nenhuma execução sem supervisão faz merge em uma branch protegida.
- Sinal de conclusão: você é avisado quando ela termina e se passou, sem precisar ficar consultando.
- Contrato de revisão: toda execução concluída chega com testes, um resumo das alterações e limites conhecidos, e a aceitação continua sendo sua.
Os primeiros seis itens tornam a execução sem supervisão. O último a torna digna de ser feita. Se você já roda vários agentes e é na revisão da manhã que seu tempo vai embora, execute seus agentes de código atuais pelo Sharkly para que a fila chegue até você organizada, em vez de espalhada.
