Fábricas de software têm sido o centro das atenções nas últimas semanas. Então, construí uma.
Aqui está o que aprendi, como funciona e como você pode construir uma em uma tarde.
Meus Objetivos
Precisava ser algo realmente simples, que funcionasse sem exigir uma supervisão constante. Idealmente, rodaria inteiramente na minha assinatura atual do Claude.
Parece ingênuo, mas basicamente, se não se integrar facilmente ao meu fluxo de trabalho atual, não vai ser algo que eu continue usando. Não quero construir isso e ter que mudar todos os meus hábitos existentes só para usar esse novo sistema. Sei por experiência que, se isso acontecer, não funcionará para mim a longo prazo e vai acabar sendo abandonado.
Então, em vez de atacar isso como um grande esforço único, dividi em duas fases distintas:
- Pré-triagem - descobrir o que "precisa ser feito"
- Implementação - realmente "fazer" as coisas
No centro está o Linear, a fonte da verdade sobre o trabalho que precisa ser feito.
Toda fábrica de software precisa ter esse repositório centralizado de trabalho a ser feito, seja com issues do GitHub, Linear ou outra ferramenta. Deve ser algo que você já usa, para que seja facilmente extensível por qualquer sistema e possa adicionar tarefas para agentes ou humanos pegarem e concluírem depois.
Linear com uma issue gerada automaticamente pelo loop de Verificação de Saúde do Sistema
O pipeline tem limites intencionalmente definidos que tornam o processo de construção de uma fábrica de software algo gerenciável:
- Criar trabalho (loops com MCPs)
- Armazenar trabalho (Linear)
- Concluir trabalho (agente SDLC)
Ao dividir, você não precisa construir os lados de pré-triagem e implementação ao mesmo tempo (e eu realmente recomendo evitar isso para não superengenhar). O Linear torna a interface entre o que "deve ser feito" e o que estamos "fazendo" bem definida e fácil de estender.
Etapa de Pré-triagem
No diagrama acima, o trabalho progride da esquerda para a direita. O lado esquerdo é onde o trabalho é criado e contém qualquer número de sistemas (sejam humanos, agentes ou APIs) que adicionam tarefas ao que precisa ser feito. Todas as saídas criadas nesta etapa de pré-triagem são colocadas no nosso Linear.
Alguns loops rodando em um ambiente cloud do Claude
Nesta etapa, temos três loops principais:
- Loop de Verificação de Saúde do Sistema (ou seja, um caçador de bugs) - este loop roda diariamente às 5h e está conectado a alguns servidores MCP: Posthog para rastreamento de erros; Vercel para diagnósticos do sistema; e Linear para criar issues.
- Loop de Melhorias de UX e Feedback de Clientes - este loop roda semanalmente às segundas-feiras às 9h e examina cada novo feedback, cada chat de suporte ao cliente do Intercom/Fin e todas as reproduções de sessão do Posthog. As reproduções de sessão são uma mina de ouro. Você pode ver onde ocorrem cliques de raiva ou onde os usuários estão com dificuldades e confusos.
- Loop de Análise de Churn - este loop roda diariamente às 6h e investiga cada cliente que clicou em "cancelar" nas últimas 24 horas. Ele puxa dados de pagamento e usuário do Stripe (incluindo e-mail/localização) e depois analisa a reprodução da sessão desse cliente no Posthog para ver o que ele estava fazendo antes de cancelar. Puxamos o uso do Supabase para ver se era um ICP errado, se o cliente nunca teve aquele momento "uau" ou se encontrou bugs. O relatório é enviado para o Slack e o agente cria (ou comenta) issues se elas estiverem relacionadas ao churn de clientes para aumentar a prioridade.
Para realmente executar esses agentes de forma consistente, mantive a simplicidade e usei o Claude Code Cloud Routines.
Nada de superengenharia com um VPS da Hetzner, um Mac mini com cafeína, etc. É de longe a maneira mais fácil que encontrei de aproveitar sua assinatura existente do Claude Code e criar agentes sempre ativos que podem ser acionados por agendamento ou por evento de webhook. E para todos que dizem "mas e o vendor lock-in?!" - é literalmente só texto. Sinta-se à vontade para copiar o prompt para onde quiser, eu só queria a maneira mais fácil e barata de configurar algo que funcione de forma confiável.
E outra razão para usar o Claude Code Cloud Routines é que os ambientes cloud da Anthropic têm uma paridade próxima com o Claude rodando localmente.
Cloud Claude Routines
Obviamente, eles não têm suas variáveis de ambiente (que podem ser adicionadas à configuração do ambiente cloud, se necessário), mas se você configurar uma conexão MCP através dos conectores do Aplicativo Desktop, tanto o Claude CLI local quanto o Claude remoto podem usá-las, ao contrário do Codex. Esse foi o recurso matador para mim e é o que faz esses loops de agentes de pré-triagem funcionarem tão bem. Também facilita executar várias sessões em paralelo sem se preocupar com a memória do seu notebook.
Se você implementar apenas esta etapa de pré-triagem, ainda terá muito ganho, mesmo que não construa a próxima etapa onde o trabalho é concluído.
Comece pequeno com um único loop, teste, refine e depois adicione mais. Descubra quais rotinas você pode criar hoje que coloquem trabalho novo e de alta qualidade no seu rastreador de issues existente e depois faça o que você já faz hoje para implementação.
Etapa de Implementação
A versão mais básica da etapa dois é dar ao seu agente um ID de issue e dizer para ele concluí-la. Isso é o que a maioria das pessoas já faz hoje ao trabalhar com agentes, no entanto, provavelmente não é o que você quer se está lendo isso, porque você agora se torna o gargalo no loop, iniciando um agente diretamente em uma sessão.
Em vez disso, o que fiz foi construir uma maneira de acionar sessões remotas do Claude Code diretamente do Linear.
Da issue do Linear para o Claude
Funciona assim:
- Primeiro, identifique como você quer acionar uma nova sessão do Claude. Para nós, adicionamos um rótulo 'auto' a uma issue do Linear que inicia essa nova tarefa.
- Em seguida, o Linear envia um evento de webhook para nosso serviço de API de webhook interno (um novo aplicativo Hono interno) que analisa o evento e depois encaminha as informações corretas para a Claude Routine.
- Por fim, este serviço de API leve faz uma requisição POST para a Anthropic que aciona a Claude Routine com um prompt inicial.
Usar um rótulo 'auto' como gatilho nos permite controlar a execução automática de novas sessões do Claude.
Por padrão, as etapas de pré-triagem não incluem esses rótulos 'auto' e exigem que um humano adicione o rótulo que aciona o agente para iniciar o trabalho (mantendo o humano no loop). É por isso que chamamos a etapa 1 de etapa de pré-triagem, porque algo ainda está descobrindo o que realmente trabalhar, seja por envolvimento humano ou por algum agente em loop observando novas issues sendo adicionadas e iniciando novas sessões de implementação.
No entanto, como adicionar um rótulo também é facilmente feito por um agente, poderíamos fazer com que loops de pré-triagem criem novas issues com o rótulo 'auto' por padrão, o que inicia uma nova sessão do Claude. Usar um rótulo se torna uma maneira muito flexível de iniciar novos trabalhos de implementação, seja automaticamente por um agente ou por nós, humanos.
Um serviço de roteamento leve para iniciar sessões do Claude
Como o Linear suporta webhooks, todo o "envio quando um rótulo é adicionado" funciona. A única desvantagem é que precisamos ter uma API pública que aceite esses webhooks e formate os eventos e dados do payload para acionar o Claude Code. Este novo serviço também adiciona os cabeçalhos de autenticação corretos, e é por isso que você não pode fazer o Linear acionar a rotina diretamente.
Alternativamente, você poderia ter uma rotina agendada que inicia de tempos em tempos e tenta implementar quaisquer novas issues que não estejam em andamento com o rótulo 'auto'.
Para o prompt real da rotina, recomendo construir uma habilidade reutilizável que percorra todo o SDLC, com um nome como /implement ou /do, que facilite apenas dizer "/do ISSUE-NNN", documentando como passar corretamente pelas etapas de buscar o contexto da issue, implementar o trabalho, verificar no navegador, criar o PR e monitorar os comentários.
Então o prompt da Claude Routine, acionado pelo evento do Linear, pode ter apenas um prompt muito simples. Aqui está o meu:
Recupere a issue fornecida e use a habilidade /do para implementar a mudança solicitada e criar um pull request. Busque apenas a issue exata fornecida. Se ela já estiver completa ou em andamento, pare.
A referência da issue não aparece nesta mensagem — ela chega como uma mensagem de acompanhamento separada, encapsulada em uma tag
<routine-fire-payload>, enviada imediatamente após esta, na mesma sessão. Aguarde essa mensagem antes de decidir se uma issue foi fornecida. Só conclua que a issue não existe, ou que nenhuma foi fornecida, após verificar na mensagem<routine-fire-payload>e confirmar que a issue referenciada realmente não existe.Ao começar o trabalho, comente na issue, defina-a como "Em Andamento" e atualize a issue com qualquer informação relevante conforme você progride. Sempre prefixe os comentários da issue do Linear com [Claude].
Então, neste ponto, você tem sessões paralelas do Claude Remotion acionadas via API, implementando issues, abrindo PRs (e, esperançosamente, verificando seu trabalho via Playwright ou Agent Browser).
É essencialmente uma fábrica de software completa, totalmente observável, que funciona enquanto você dorme e opera inteiramente na sua assinatura do Claude Code.
