O caminho de bugs que começa e termina num e-mail

Um relato de bug cai no nosso endereço de suporte. O this+that lê, reconhece que é um bug e não uma dúvida de cobrança ou um pedido de recurso, e transforma numa tarefa no DoBox. Então atribui a tarefa com base no que o Brain, a nossa camada de conhecimento operacional, sabe sobre as capacidades de cada pessoa de engenharia e sobre qual área do produto ela é dona. O bug vai para quem conhece o código, e não para uma fila rotativa.

Dali, essa pessoa entrega a correção a um agente. O nosso aplicativo de mesa liga a tarefa ao Claude Code ou ao Codex rodando na máquina dela. O agente ganha um worktree próprio a partir do checkout local, então escreve a correção sem atrapalhar o ramo em que essa pessoa está trabalhando, e abre um pull request em rascunho. O pedido de revisão vai para quem é dono da tarefa, e a tarefa no DoBox se atualiza a cada passo, então quem acompanha a fila vê onde a correção está sem precisar perguntar.

Quando a revisão é aprovada, outro fluxo fecha o ciclo: ele responde a quem relatou o bug. Está corrigido, sai em breve, acompanhe as novidades. Do lado de quem relatou, parece o que parecia antes da IA: alguém corrigiu o bug. Essa pessoa provavelmente não faz ideia de quão pouco trabalho quem desenvolve teve.

O que é embutido, e o que você monta

Essa história é um fluxo, e nós o montamos. Vale separar as duas metades, porque são coisas de tipos diferentes.

A delegação é a metade embutida. Abra qualquer tarefa no DoBox, escolha um agente, envie. Isso funciona uma tarefa por vez, à mão, sem automação na frente e sem nada configurado antes. É também onde a maioria começa e onde muita gente fica, porque olhar uma tarefa e decidir que um agente deve tentar é um jeito perfeitamente bom de usar isto.

O caminho completo é a metade que você monta. Qual endereço conta como relato de bug e não dúvida de cobrança, quem é dono de qual área do produto, onde uma pessoa precisa aprovar: são decisões que deliberadamente não tomamos por você, porque a resposta certa muda em cada time. Leia o nosso caminho de bugs como um exemplo do que as peças fazem juntas, e não como um modelo que você liga.

Nenhuma das metades é só para código. Uma tarefa que guarda um relatório, uma análise ou uma pesquisa pode ser delegada exatamente do mesmo jeito, e a maioria delas não precisa de repositório nenhum.

Atribuir trabalho a um agente agora é normal

O meio dessa história virou comum, e é justo dar o crédito. O agente de código do GitHub Copilot pega uma issue e abre um pull request em rascunho. O Linear deixa você atribuir uma issue ao Devin, ao Codex ou ao Copilot do jeito que atribuiria a um colega. O Rovo Dev da Atlassian faz o mesmo para o Jira. São produtos úteis, e todos convergiram para o mesmo ciclo: descreva o trabalho, entregue a um agente, revise o que voltar. Quando GitHub, Linear e Atlassian chegam ao mesmo ciclo, o padrão ganhou. Fizemos a mesma aposta cedo, então ficamos felizes de vê-la validada.

Nós diferimos desses três em dois pontos: onde o agente roda, e onde o ciclo começa.

O agente pode rodar na sua máquina

Esses agentes rodam em ambientes isolados na nuvem. Quem fornece sobe um ambiente, clona o seu repositório nele, e o agente trabalha ali. É um desenho razoável, torna a configuração fácil, e você também pode delegar do this+that a agentes na nuvem.

O que acrescentamos é a opção de manter o trabalho em casa. Delegue uma tarefa de código e o agente roda na máquina de quem recebeu, pelo Claude Code ou pelo Codex, num worktree a partir do checkout local, no hardware dessa pessoa, sob a assinatura que ela já paga. Nada é clonado para a computação de outra pessoa, nenhuma cópia do seu repositório existe fora da sua máquina, e não há uma conta medida à parte por minutos de agente.

Claude Code e Codex rodam localmente mas ainda chamam a Anthropic ou a OpenAI, do mesmo jeito que quando você os roda num terminal. Se isso é um problema para o seu código, aponte a delegação para um modelo Qwen servido pelo Ollama na mesma máquina. Aí não há chamada de API nenhuma: o repositório, o modelo e o trabalho ficam todos no laptop. Essa opção está no ar agora, e ambientes na nuvem não conseguem oferecer.

O ciclo começa num e-mail

A segunda diferença é o formato do ciclo. O ciclo do Copilot começa numa issue e termina num pull request. O do Linear começa num ticket e termina num ticket. Isso funciona quando o trabalho nasce dentro da engenharia.

Mas a maior parte do trabalho não chega como um ticket bem formado. Chega como mensagem. Um cliente escreve ao suporte. Um colega aponta algo estranho no Slack. Alguém responde numa corrente com “mais alguém está vendo isto?”. Antes de qualquer agente pegar o trabalho, uma pessoa precisa notar a mensagem, traduzir em ticket, e registrar no lugar certo, e esse passo de tradução é onde as coisas escapam.

Então o nosso ciclo começa onde o trabalho começa, na mensagem, e termina onde deveria terminar, com uma resposta a quem pediu. O rastreador está no meio do ciclo, e não na porta de entrada. O cliente nunca abre um chamado, cria uma conta ou acompanha uma página de status. E-mail entra, e-mail sai.

Um segundo exemplo, sem código nenhum

Um cliente pede um resumo dos números do trimestre passado. A tarefa é encaminhada a quem você definiu como dono daquela conta, e o agente escreve a análise na pasta de trabalho dessa pessoa para revisão. O mesmo vale para o relatório que um parceiro espera, ou o documento de acompanhamento prometido numa call. O agente escreve, uma pessoa revisa, e um fluxo envia a resposta. Tarefas assim não precisam de repositório, e o resultado chega anexado à própria tarefa.

Delegar uma dessas à mão são os mesmos três cliques de delegar um bug: abra a tarefa, escolha um agente, envie. Ligar isso a um fluxo é o mesmo trabalho de ligar o caminho de bugs, e as decisões são suas do mesmo jeito. O que conta como pedido que merece um rascunho, de quem é cada conta, quem assina antes de qualquer coisa chegar ao cliente.

Programação foi onde a delegação amadureceu primeiro porque o resultado é fácil de conferir. Um pull request tem um diff e um conjunto de testes. O ciclo em si, mensagem para tarefa para agente local para resultado revisado para resposta, funciona igual seja qual for a entrega.

Rodamos os nossos próprios bugs por ele

Isto não é uma demonstração montada para um vídeo de lançamento. É como corrigimos o nosso próprio produto. Relatos de bug viram tarefas, acrescentamos soluções propostas às tarefas no DoBox, e as delegamos a um agente de código nas nossas máquinas. Os PRs em rascunho voltam, revisamos, e as correções sobem.

Uma coisa mantemos constante: toda correção delegada chega como pull request em rascunho, e uma pessoa revisa e mescla. Nada técnico obriga isso. O ciclo inteiro poderia rodar sem mãos: e-mail para tarefa para correção delegada, um segundo agente fazendo a revisão de código, uma mesclagem automática, um deploy por CI/CD, e a resposta a quem relatou, com um modelo decidindo de antemão quais bugs são simples o bastante para confiar a ele. Os modelos conseguem tomar essa decisão hoje. Mantemos uma pessoa no ciclo de revisão mesmo assim, porque lemos diffs suficientes dos nossos próprios agentes para saber que a revisão é onde os erros são pegos, e porque ler esses diffs é como o time se mantém em dia com um código que não escreve mais linha a linha.

Decidir qual trabalho entregar em primeiro lugar é uma questão à parte, e vale responder antes de ligar qualquer coisa. A quebra tarefa a tarefa da automação de programação da Arsum percorre a lista de tarefas do O*NET para a profissão e pontua cada uma, incluindo aquelas em que a resposta honesta é deixar como está.

Para onde isto vai

Hoje, a delegação roda pelo nosso aplicativo de mesa no macOS (Apple Silicon), e mira Claude Code, Codex ou um modelo Qwen local pelo Ollama. Windows e Linux vêm a seguir.

Principais conclusões

• Delegação é a parte embutida e é manual por padrão: abra qualquer tarefa no DoBox, escolha um agente, envie. Nada precisa ser automatizado antes.
• O caminho de bugs descrito acima é um fluxo que montamos para nós, e não um recurso que você liga. O que conta como relato de bug, quem é dono de qual área do produto, e onde uma pessoa aprova são decisões que deixamos com você, porque as respostas certas mudam em cada time. Monte a versão que combina com o seu.
• Nada disso é específico de código. Uma tarefa que guarda um relatório, uma análise ou uma pesquisa pode ser delegada do mesmo jeito e não precisa de repositório nenhum.
• Atribuir trabalho a um agente de código já é padrão de setor: GitHub Copilot, Linear e o Rovo Dev da Atlassian suportam isso, e merecem crédito por tornar a delegação normal.
• Esses agentes trabalham em ambientes isolados na nuvem, e o this+that também delega a agentes na nuvem. O que acrescentamos é a opção local: o agente roda na máquina de quem recebeu (macOS hoje) pelo Claude Code ou pelo Codex, num worktree a partir do checkout dessa pessoa, na assinatura que ela já paga, e nenhuma cópia do seu repositório é feita em outro lugar.
• Claude Code e Codex ainda chamam a API de quem os fornece a partir daquela máquina. Aponte a delegação para um modelo Qwen sob o Ollama e nada sai do laptop, que é a configuração para código que não pode ir a terceiros.
• O ciclo deles vai de ticket a ticket. O nosso vai de e-mail a e-mail: a mensagem de um cliente vira tarefa, a correção volta como PR em rascunho para revisão humana, e um fluxo responde a quem relatou. O rastreador fica no meio, e não na porta de entrada.
• Rodamos o nosso próprio caminho de bugs assim, e toda correção delegada é revisada e mesclada por uma pessoa. O ciclo poderia rodar totalmente sem mãos, revisão de código por agente e deploy por CI/CD incluídos; manter uma pessoa no ciclo é uma escolha, e não uma limitação.

Comece delegando uma tarefa à mão, e monte o fluxo em volta dela quando souber o que quer que ele faça. Comece com o this+that e conecte a caixa onde o trabalho já cai. Grátis durante o beta.