Adotando o modelo de fábrica de software: rastejar, caminhar, correr

A abordagem de fábrica de software (um loop agêntico fechado que roda na nuvem) está ganhando popularidade, mas sua adoção pode ser intimidadora. Neste post, vou percorrer os passos "engatinhar, andar, correr" para fazer a transição de agentes locais e interativos para o desenvolvimento automatizado na nuvem.

Engatinhar

Muitos líderes de engenharia e engenheiros de plataforma com quem converso já começaram na parte do "engatinhar" da construção de uma fábrica de software, criando automações simples usando agentes em nuvem.

Pense nessas automações como Gatilho → Atividade do Agente.

Por exemplo:

• Reprodução e triagem de issues: ter um agente que analisa todas as novas issues abertas, reproduz os problemas e aplica rótulos.
• Revisão de código: Revisar PRs automaticamente assim que são abertos e deixar comentários.
• Monitoramento: ter um agente que responde a alertas do Sentry, depura e corrige problemas.
• Auto-cura de CI: corrigir CI quebrado identificando PRs para rollback ou conflitos de merge para resolver.
• Atualização automática de docs: atualizar documentação voltada ao usuário e gerar changelogs.
• Verificação: agentes de browser-use e computer-use realizam QA visual e verificam mudanças.
• Correções simples de bugs: agentes identificam e corrigem problemas simples reportados por usuários.

O ponto em comum entre todas essas abordagens é que elas automatizam partes discretas do ciclo de vida do software. Começar com automações simples é uma abordagem de baixo risco e baixo custo, ajudando a construir intuição sobre como usar agentes eficazmente em tarefas mais complexas e multiestágio.

Exemplo de automação para monitoramento de alertas

Essas automações podem ser construídas usando infraestrutura própria (por exemplo, colocando o SDK do Claude Code em um container Docker e configurando um servidor para acioná-lo), ou podem usar uma plataforma genérica de automação de agentes em nuvem projetada para executar agentes baseados em gatilhos. Também podem usar uma plataforma dedicada a apenas uma etapa do ciclo (por exemplo, um revisor de código agêntico dedicado ou um SRE de IA).

Começar com um mosaico de automações pontuais é aceitável, mas a maioria das equipes eventualmente atinge limites com essa abordagem.

Especificamente:

• Dependendo de como as coisas estão configuradas, essas automações podem não compartilhar contexto. Isso significa que, ao fazer melhorias em um aspecto (digamos, revisão de código), elas não se transferem para outras etapas, como triagem e QA.
• Não há uma visão global de se todas essas automações avulsas realmente melhoram a produtividade geral, nem uma maneira sistemática de testar e melhorar as métricas de alto nível que você valoriza, como custo-por-PR, tempo de ciclo, porcentagem de automação, etc. Para rastrear isso, você precisa de um sistema que funcione através de todas as etapas do desenvolvimento.
• As soluções pontuais criam suas próprias cargas de configuração e manutenção. Elas aumentam a superfície de segurança a ser gerenciada. Não possuem uma interface unificada para observabilidade. As equipes eventualmente desejam configuração centralizada, auditoria e governança.

Andar

Todos esses problemas apontam para a necessidade de uma abordagem mais holística. Organizações que já "engatinharam" perguntam-se: "qual é o sistema que queremos para escalar verdadeiramente o desenvolvimento agêntico?"

Mais especificamente, elas questionam:

• Onde o desenvolvimento deve acontecer? Localmente ou na nuvem? Através de quais interfaces?
• Como parece um processo de desenvolvimento automatizado bem-sucedido? Quais são as métricas-chave?
• Qual é a nossa postura de soberania de IA? Quão importante é possuir nossos dados de agentes de codificação? Quão dependentes devemos ser dos provedores de modelos?
• Como planejamos melhorar nosso processo de desenvolvimento ao longo do tempo? Como controlamos custos enquanto aceleramos a velocidade de entrega? Como sabemos que estamos melhorando?
• Como nos preparamos para o futuro à medida que modelos e agentes evoluem? Estamos considerando riscos regulatórios que possam impactar o acesso aos modelos?
• Como exatamente os engenheiros devem participar do processo de desenvolvimento? E designers, PMs e outros construtores?
• Como estamos garantindo a segurança do desenvolvimento? Qual é o plano se nosso processo de produção de software for comprometido?

A maioria dos líderes de engenharia e equipes de plataforma que pensam profundamente sobre essas questões chega a algo semelhante a uma abordagem de fábrica de software na nuvem. Eles querem:

• Desenvolvimento na nuvem por padrão, porque é mais seguro dar sandboxes aos agentes do que deixá-los soltos localmente.
• Governança centralizada de agentes de codificação e das ferramentas e sistemas aos quais eles acessam.
• Rastros completos do que os agentes fizeram, para auditoria e compreensão da produtividade.
• Opções flexíveis em torno de modelos e harnesses, para minimizar riscos e otimizar desempenho.
• Integração do desenvolvimento em todas as ferramentas que sua equipe já usa (ex.: Slack/Teams, Jira, Github, etc.).
• Saídas de emergência para humanos assumirem o controle, seja dirigindo agentes ao vivo ou trazendo trabalho para o loop interno de desenvolvimento.
• Uma camada de contexto compartilhado que funciona através de todos os agentes em todas as fases do desenvolvimento.
• Uma abordagem que permita testes, avaliações e benchmarks para que sua equipe tenha confiança de que o sistema está melhorando com o tempo.

Uma vez que uma empresa decide pela abordagem de fábrica, a questão torna-se: como chegar lá a partir das suas automações pontuais existentes? Isso geralmente se resume a decidir se (1) você constrói mais infraestrutura em torno dessas automações ou (2) você faz a transição para uma plataforma como o Warp Factories, que fornece a infraestrutura de fábrica.

Note que eu não enquadraria isso como uma decisão tradicional de "construir vs. comprar". Independentemente do caminho escolhido, espere que sua equipe interna faça alguma construção, pois para fazer a abordagem de fábrica funcionar, ela precisa estar profundamente integrada ao contexto e aos fluxos de trabalho da sua equipe. É mais uma questão de saber se você constrói sua infraestrutura de automação totalmente do zero ou se faz parceria com pessoas que fornecem um ponto de partida.

Por exemplo, independentemente do caminho, espere construir habilidades específicas da organização e ajustá-las para seu codebase. Espere expor e configurar MCPs específicos da organização e fontes de contexto internas. Mas talvez você não queira construir infraestrutura em nuvem para executar e gerenciar agentes, dirigi-los, passar adiante seu trabalho, medir sua eficácia, realizar uso de computador, etc. A regra prática é focar em construir as peças específicas da sua organização, não aquelas necessárias por qualquer organização.

Qualquer que seja a abordagem escolhida, sugiro que o maior marco na fase de andar seja implantar uma primeira fábrica de ponta a ponta em uma superfície de produto simples. Pode ser seu site de marketing ou um aplicativo interno.

Começar com um projeto simples tem a vantagem de iniciar todo o loop com baixo risco e complexidade mínima. Adicionar mais repositórios, linhas de código, dependências de serviço, stakeholders humanos, etc., aumenta a complexidade e pode levar à sensação de que você não está pronto para a automação. É melhor ajustar primeiro um loop simples.

O objetivo é um sistema multiagente que vai de triagem → spec → implementação → revisão → verificação → monitoramento. Em mais detalhes:

1. Nova issue entra no sistema, seja via humano ou agente de monitoramento.
2. O agente de triagem executa e tenta entender e reproduzir a issue. Se determinar que a tarefa é automatizável → passa para o agente de Implementação. Se precisar de specs devido ao escopo → faz o agente de specs iterar com um humano para criar uma spec. Se for ambígua → obtém input humano e re-executa, ou simplesmente decide estacionar a issue por enquanto.
3. [Se necessário] O agente de Specs executa, o humano revisa as specs e então passa para o agente de implementação.
4. O agente de Implementação escreve o código.
5. O agente de Revisão de Código revisa o código.
6. O agente de Verificação realiza uso de computador ou outra verificação.
7. O humano revisa o código e a saída da verificação. Se necessário, volta para o passo 2, 3, 4 ou 5.
8. CI / CD.
9. Entregar (Ship it).
10. O agente de Monitoramento executa e cria issues se necessário, completando o loop.

Internamente na Warp, nossa fábrica de fase andar automatiza cerca de 75% das mudanças no warp.dev, nosso site de marketing. Diferente do Warp Terminal (65k estrelas no GitHub, quase um milhão de devs ativos, 1M de linhas de Rust nativo), nosso site de marketing é um app bastante simples. Note que por "automatizar" quero dizer ir do input humano até a funcionalidade entregue inteiramente através da fábrica, com pontos de contato humanos mínimos além de descrever a mudança desejada, seja no Slack ou no nosso rastreador de tarefas.

Correr

Somente quando você tiver o loop básico estabelecido em um projeto simples deve escalar para projetos mais complexos. Escalar fábricas requer infraestrutura mais robusta.

Especificamente, ao escalar, certos gargalos surgem:

• Fazer ambientes de desenvolvimento remoto funcionarem em grandes projetos é difícil. Mais repositórios, linhas de código e dependências de serviço tornam a automação mais difícil.
• À medida que você tem mais habilidades e código, etc., fica mais difícil saber se as mudanças feitas nas suas fábricas estão tendo um impacto positivo no desenvolvimento ou apenas causando churn.
• Você naturalmente corre maiores riscos de custo à medida que os agentes trabalham em codebases mais complexos, pois precisa de modelos mais poderosos e os agentes precisam rodar por mais tempo. O roteamento de modelos e a escolha de harness tornam-se mais importantes.
• Segurança e auditoria tornam-se mais críticas quanto mais você traz a abordagem de fábrica para apps mission-critical voltados ao usuário.
• Mais stakeholders de app significam mais coordenação humana e aprovações. Você vai querer uma solução de fábrica que permita inputs multiplayer e trilhas de auditoria.
• Inevitavelmente, os PRs começarão a se acumular, então você precisará de uma estratégia definida para o que é revisado, como usar verificação e QA agênticos.
• Você vai querer ferramentas mais robustas para fechar o loop, garantindo que as mudanças entregues em produção sejam de alta qualidade, não travem, etc.

Fazer fábricas escaláveis funcionarem será, na minha opinião, um dos desafios de engenharia de software mais interessantes nos próximos anos; a engenharia de software está se tornando engenharia de fábrica. Organizações que conseguirem tornar suas fábricas robustas, confiáveis e auto-aprimoráveis poderão entregar mais a um melhor custo e terão vantagem competitiva.

Para fazer as fábricas realmente funcionarem perfeitamente exige investimento significativo. Na Warp, pensamos nisso como construir completamente sua stack de fábrica:

Cubro cada uma dessas camadas em detalhe neste post:

https://x.com/zachlloydtweets/status/2097739116720910619

Alguns pontos-chave a destacar que podem não ser óbvios:

• Fábricas-como-código: uma das principais escolhas que você pode fazer é definir suas fábricas como código. Isso permite testar diferentes configurações de fábrica para ver quais são mais eficientes, de maior qualidade, etc.
• Multi-modelo & multi-harness: você deve garantir que suas fábricas sejam capazes de usar os modelos mais recentes, tanto frontier quanto open-weight, e usar diferentes harnesses de agentes de codificação como Claude Code e Codex.
• Propriedade de dados: você deve garantir que armazene e possua todos os dados provenientes da sua fábrica - esta é a matéria-prima para melhorar suas operações.

Em uma fábrica funcionando plenamente, a característica chave é que é um sistema de loop fechado, mensurável e aprimorável. Este deve ser o objetivo. Em tal sistema, todos trabalham a partir do mesmo contexto, publicamente, de forma totalmente auditada e observada. Os próprios agentes observam as habilidades e configurações que impulsionam o sistema e sugerem melhorias. Engenheiros de plataforma conseguem estender o sistema para integrá-lo a todos os sistemas internos. Líderes de engenharia podem ver métricas de produtividade e entender quais mudanças estão sendo feitas para melhorá-las. Tudo funciona empiricamente, não baseado em "vibes".

Na Warp, estamos chegando mais perto dessa visão. Todos os dias, todos nós trabalhamos publicamente, ajustando nossa fábrica, reduzindo custos e melhorando throughput e qualidade.

Nossa missão é fornecer às melhores equipes de engenharia do mundo as ferramentas para construir, medir e otimizar seus próprios fluxos de trabalho usando qualquer modelo subjacente e harness em infraestrutura aberta. Essas capacidades ajudarão as equipes a entregar software melhor, mais rápido e com mais eficiência.

O Warp Factories está atualmente em acesso antecipado. Empresas qualificadas recebem $10k de uso da fábrica.