Software factories têm sido a sensação das últimas semanas. Então eu construí uma.
Aqui está o que aprendi, como funciona e como você pode construir uma em uma tarde.
Meus Objetivos
Precisava ser realmente simples, algo que funcionasse e não exigisse muita supervisão. Idealmente, funcionaria inteiramente na minha assinatura atual do Claude.
Parece ingênuo, mas essencialmente, a menos que se integre facilmente ao meu fluxo de trabalho existente, não será algo que permanecerá. Não quero construir isso e ter que mudar todos os meus hábitos existentes apenas para usar este novo sistema. Sei por experiência que, se isso acontecer, não funcionará para mim a longo prazo e acabará caindo no esquecimento.
Então, em vez de atacar isso como um grande esforço, dividi em duas fases distintas:
- Pré-triagem - descobrir o que "fazer"
- Implementação - realmente "fazer" as coisas
No centro está o Linear, a fonte da verdade sobre qual trabalho precisa ser feito.
Toda fábrica de software precisa ter esse repositório centralizado de trabalho a ser feito, seja GitHub Issues, Linear ou outra ferramenta. Deve ser o que você já usa para que seja facilmente extensível por qualquer sistema para adicionar trabalho que agentes ou humanos possam pegar e concluir depois.
Linear com um issue gerado automaticamente pelo loop de Verificação de Saúde do Sistema
O pipeline tem costuras definidas intencionalmente que tornam o processo de construção de uma fábrica de software realmente gerenciável:
- Criar trabalho (loops com MCPs)
- Armazenar trabalho (Linear)
- Completar trabalho (agente SDLC)
Ao dividir, você não precisa construir os lados de pré-triagem e implementação ao mesmo tempo (e na verdade recomendo evitar isso para não complicar demais). O Linear torna a interface entre o que "fazer" 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 (humanos, agentes ou APIs) que adicionam ao que precisa ser feito. Todas as saídas criadas nesta etapa de pré-triagem são colocadas no nosso Linear.
Alguns loops que rodam 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 da manhã 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 escaneia cada novo feedback, cada chat de suporte ao cliente do Intercom/Fin, e todas as replays de sessão do Posthog. As replays 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 do usuário do Stripe (incluindo e-mail/localização), e então analisa a replay de sessão deste cliente no Posthog para ver o que estavam fazendo antes de cancelar. Puxamos o uso deles do Supabase para ver se era um ICP errado, nunca experimentaram aquele momento "uau" ou encontraram bugs. O relatório é enviado para o Slack e o agente cria (ou comenta) issues se estiverem relacionadas a clientes cancelando para aumentar a prioridade.
Para realmente rodar esses agentes de forma consistente, mantive simples e usei o Claude Code Cloud Routines.
Nada de engenharia excessiva com um VPS da Hetzner, um Mac Mini com cafeína, etc. É de longe a maneira mais fácil que encontrei para aproveitar sua assinatura existente do Claude Code e criar agentes sempre ativos que podem ser acionados por agendamento ou por um evento de webhook. E para todos que dizem "mas e o vendor lock-in!!" - é literalmente apenas um texto. Sinta-se à vontade para copiar o prompt para onde quiser, eu só queria a coisa mais fácil e barata de configurar que funcionasse de forma confiável.
E outra razão para usar o Claude Code Cloud Routines é que os ambientes cloud da Anthropic têm 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 Desktop App, tanto o seu Claude CLI local quanto o Claude remoto podem usá-los, ao contrário do Codex. Esse foi o recurso matador para mim e é o que faz esses loops de agente 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 laptop.
Se você apenas implementar esta etapa de pré-triagem, ainda terá muita vantagem, mesmo que não construa a próxima etapa onde o trabalho é concluído.
Comece pequeno com um único loop, experimente, refine e depois adicione mais. Descubra quais rotinas você pode criar hoje que colocam 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 ir completá-lo. 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 agora você é 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.
Indo de um 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 um issue do Linear que inicia essa nova tarefa.
- Em seguida, o Linear envia um evento de webhook para nosso serviço interno de API de webhook (um aplicativo Hono interno recém-criado) que analisa o evento e encaminha as informações corretas para a Claude Routine.
- Finalmente, 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, não incluímos esses rótulos 'auto' nas etapas de pré-triagem e exigimos 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 pré-triagem, porque algo ainda está descobrindo o que realmente trabalhar, seja por envolvimento humano ou algum agente que fica em loop e observa novos issues sendo adicionados e inicia 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 novos 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 novo trabalho 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 "push quando um rótulo é adicionado" funciona. A única desvantagem é que precisamos ter uma API pública que roteia aceita esses webhooks e formata os eventos e dados de 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 novos 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 percorre todo o SDLC, com nome algo como /implement ou /do, que torna fácil apenas dizer '/do ISSUE-NNN', que documenta como passar corretamente pelas etapas de buscar o contexto do issue, implementar o trabalho, verificar no navegador, criar o PR e monitorar 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 o issue fornecido e use a habilidade /do para implementar a mudança solicitada e criar um pull request. Busque apenas o issue exato fornecido. Se já estiver completo ou em andamento, pare.
A referência do 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 um issue foi fornecido. Só conclua que o issue não existe, ou que nenhum foi dado, depois de verificar na mensagem \<routine-fire-payload>\e confirmar que o issue referenciado realmente não existe.Quando você começar o trabalho, comente no issue, defina-o como "Em Andamento" e atualize o issue com qualquer coisa significativa à medida que progredir. Sempre prefixe os comentários do issue Linear com [Claude].
Então neste momento você tem sessões paralelas do Claude Remotion acionadas via API, implementando issues, abrindo PRs (e com sorte verificando seu trabalho via Playwright ou Agent Browser).
É essencialmente uma fábrica de software completa que é totalmente observável, funciona enquanto você dorme e opera inteiramente na sua assinatura do Claude Code.
