software-factories

Software Factories — como agentes de IA entregam código start to finish

Definition

Uma software factory é um sistema que coordena agentes de IA para escrever, testar, revisar e fazer deploy de código num fluxo repetível de ponta a ponta — do ticket à produção. A fonte (Codingscape, out/2026) organiza o campo em três camadas (Addy Osmani): o loop (agente reunindo contexto, agindo e checando resultados), o harness (ambiente, ferramentas, permissões e condições de parada do agente) e a factory (coordenação de vários loops sobre uma fila de trabalho). A decisão de design que importa não é o rótulo, é onde o humano senta na linha.

A taxonomia: light, dark, twilight

• Light factory — agentes escrevem a maior parte do código e um humano lê antes de shippar. É onde praticamente toda empresa em produção está hoje.
• Dark factory — definição de Osmani: “código shippa que nenhum humano leu, verificado apenas por outras máquinas.” O exemplo público é a StrongDM: 3 engenheiros, código que não pode ser escrito nem revisado por humanos, piso de $1.000/dia em tokens por engenheiro.
• Twilight factory — termo novo de Ethan Mollick (ago/2026): “agentes fazem a maior parte do trabalho, mas se comunicam proativamente com humanos de formas que melhoram os dois lados.”

Ramp, Cursor e Uber rodam agentes autônomos em produção sem chamar de factory — o rótulo importa menos que a decisão de onde o humano entra.

Quem está rodando em produção (números da fonte)

Empresa	Como funciona	Resultado
Stripe	”Minions” escrevem end-to-end a partir de tag no Slack; humano revisa; máx. 2 rodadas de CI antes de voltar para pessoa	1.000+ PRs mergedados por semana
Anthropic	Claude escreve, engenheiros revisam, revisão automatizada por cima	~80% do código mergedado; engenheiro típico mergeda 8x mais código/dia que em 2024
Cloudflare	Até 7 agentes de revisão por merge request (qualidade, segurança, performance, docs, padrões internos, compliance de AGENTS.md)	131.246 revisões em 48.095 MRs (30 dias); $1,19 por revisão; 3m39s mediana; 0,6% de override
Ramp	”Inspect”, agente de background disparado por Slack/automações; 200+ agentes internos construídos por time de 5,5 pessoas	75% dos PRs; 1M+ sessões até jul/2026
Cursor	Cloud agents trabalham por horas e devolvem logs, vídeo e previews em vez de diffs	35% dos PRs; uso de agentes 15x ano a ano
Uber	uReview com 3 assistentes (padrão, boas práticas, AppSec), confidence scoring e dedupe	90%+ de ~65.000 diffs/semana; 75% dos comentários úteis; ~1.500 horas/dev economizadas por semana
PostHog	Agentes escrevem PRs, humanos passam o olho	~70% dos PRs escritos por agentes; humanos skimam pelo menos 80%

OpenAI descreveu (Pragmatic Engineer, 15/09) pipeline com aprovação automática opt-in para PRs de baixo risco. A categoria já tem vendor financiado: Factory levantou $200Ma$5B de valuation em setembro. Michael Truell (Cursor): “o Cursor deixou de ser sobre escrever código; é sobre ajudar devs a construir a factory que cria o software deles.”

Os 6 componentes de toda factory que funciona

• Automações — trabalho recorrente agendado (triagem de issues, resumo de CI, atribuição de revisores). Sentry atribui revisores a cada 4 horas.
• Worktrees — isolamento de agentes paralelos. Estudo com 33.596 PRs de agentes (arXiv 2607.04697): conflito em 19,8% dos pares do mesmo agente e 41,7% dos pares de agentes diferentes.
• Skills — convenções, passos de build e contexto organizacional em arquivos SKILL.md. Uber roda 3.600+ skills de agente com 30.000 execuções/dia.
• Conectores e MCP — abrir PRs, linkar tickets, disparar notificações. O Toolshed do Stripe expõe ~500 ferramentas internas via MCP.
• Sub-agentes — separar quem faz de quem confere. A Cloudflare roda um coordenador que despacha revisores especialistas.
• Memória — rastrear trabalho completo e próximos passos entre execuções.

Por que as factories falham

• HumanLayer (o caso canônico) — rodou uma factory lights-off desde jul/2025: agentes escreviam, revisavam e deployavam sem humano ler o código. Durou alguns meses até uma outage virar semanas de arqueologia em código que ninguém tinha lido. O post-mortem de Dex Horthy (“Why Software Factories Fail”, github.com/humanlayer/advanced-context-engineering-for-coding-agents) viralizou em jul/2026. O argumento: teste passando dá feedback imediato, mas o custo de arquitetura ruim emerge em meses — o agente completa cada ticket e ainda assim deixa o sistema mais difícil de manter.
• Faros (2026, telemetria de 22.000 devs) — a razão incidentes/PR subiu 242,7% entre os períodos de menor e maior adoção de IA na organização, e bugs por dev subiram 54%. Observacional, não prova de causa.
• Comprehension debt (Osmani) — em estudo da Anthropic com 52 engenheiros (arXiv 2601.20245), o grupo usando IA pontuou 17 pontos abaixo em quiz sobre código que tinha acabado de escrever, com a maior queda em debugging.
• Custo — sistemas multi-agente gastam ~15x os tokens de um chat único. A reação de Simon Willison aos $20.000/mês por engenheiro da StrongDM: “bem menos interessante para mim.”

O consenso emergente: humanos na frente, agentes no meio

• Horthy (HumanLayer) — devolve julgamento humano a 4 pontos: product review, arquitetura de sistema, design de programa e vertical slices revisados ao aterrissar. “30 minutos de planejamento salvam horas de review.” Claim: 2–3x de throughput nesse arranjo, contra a promessa dark de 10–100x que colapsa sob carga de produção.
• Mollick (twilight) — um agente facilitador puxa humanos em 4 gatilhos: aprovação (gastar dinheiro, contatar externos, tocar dados sensíveis), expertise que o modelo não tem, variância (quando agentes convergem para a mesma ideia) e interesse. “Se os agentes tomarem toda decisão interessante e deixarem para as pessoas as aprovações, as exceções e as falhas, teremos automatizado a metade errada do job.”
• PostHog (contra-argumento) — a peça que falta é contexto. Agente decide melhor quando vê o que o engenheiro de produto vê: dados de uso, reclamações, incidentes. Lá, 63% das linhas alteradas caem em arquivos já existentes e “fix” é o maior tipo de commit (40%). Dê sinais de produção aos agentes e “apagar as luzes pode não ser tão louco assim.”

O Cloudflare com 0,6% de override é o quadro quando funciona: 7 agentes revisam tudo; humanos só os overrulharam 288 vezes em 48.000 merges.

Por onde começar (4 pré-requisitos antes de aumentar volume)

1. Baseline — tempo de merge, esforço de review, retrabalho e falhas em produção, para saber se o fluxo melhorou a entrega.
2. Release gate — quais checks devem passar, quais mudanças exigem aprovação humana, o que acontece quando o agente não termina.
3. Limites operacionais — permissões de ferramentas, limites de retry e gasto, e um caminho para parar o agente ou reverter suas mudanças.
4. Custo por outcome útil — incluir runs falhos, revisões e correções; rastrear quanto custa aterrissar uma mudança aceita e se a qualidade se mantém.

O modelo operacional da Uber pareia custo por PR/revisão/alerta resolvido com qualidade (revert rate) — base mais útil para expansão que consumo de tokens ou volume de código gerado.

Implications

Para o founder/PM não-técnico, a consecuencia prática é dupla. Primeiro, a decisão de factory é uma decisão de produto, não só de engenharia: qual workflow tem critério de aceitação claro e custo de falha administrável (assistência de review, migração delimitada, classe conhecida de bugs) define onde começar — e um engenheiro nomeado responde pelo resultado. Segundo, o gargalo mudou de lado: agents escrevem mais rápido que review, CI, deploy e manutenção absorvem, então o julgamento humano de maior valor migrou para os 4 pontos do Horthy (produto, arquitetura, design de programa, slices) e para os 4 pré-requisitos de medição — quem não tem baseline, gate, limites e custo por outcome está escalando volume sem saber se a entrega melhorou. A conversa “quanto de IA escreve meu código” é a pergunta errada; a certa é “onde meu humano senta na linha e o que eu meço”.

Open Questions

• Números são majoritariamente single-source (posts das próprias empresas + agregação do blog):Cloudflare $1,19/revisão e 0,6% de override, Anthropic 80%, Ramp 75% — sem métrica independente pública. Tratar como auto-reportado.
• Os claims de Falha (Faros +242,7%) são observacionais; o próprio texto diz que não provam causa.
• Tensão não resolvida com o otimismo do padrão loop autônomo deste vault (ralph-loop em main, autoresearch): a evidência de falha lights-off é de agentes entregando em produção sem humanos na linha, não do padrão de loop em si — hipótese a registrar, não conclusão.
• Nenhuma página deste vault ainda cobre custo por outcome útil como prática de métrica — candidato a página própria se mais evidência surgir.

Related

• humanlayer — o post-mortem canônico de falha de factory e os 4 pontos de retorno do julgamento humano
• context-engineering — o contra-argumento PostHog: contexto (sinais de produção) como a peça que falta
• agent-loop — a camada loop/harness que a factory coordena
• ciclo-issue-branch-pr-merge — o loop mínimo de qualidade que a factory automatiza e reconcilia
• ai-native-sdlc-playbook — o SDLC nativo-IA onde a factory se encaixa como estágio de entrega
• especificacao-de-issues-para-agentes — “30 minutos de planejamento salvam horas de review” é a especificação como ponto de retorno humano

Sources

• raw/articles/software-factories-how-ai-agents-ship-code-start-to-finish.md