A Fábrica de Software: Um Guia Prático para Desenvolvimento Orientado a Especificações

Uma referência para implementar o desenvolvimento baseado no padrão de fábrica dentro de uma SOA empresarial.

Versão 1 - PDF - Markdown

Todas as Versões: https://thewoolleyweb.com/software-factory-practitioners-guide

Chad Woolley, thewoolleyman@gmail.com, Fevereiro de 2026

Índice

• Resumo Executivo
• Público e Conteúdo
• 1. Visão Geral e Escopo
  • Verificação da Realidade: Este é um Guia Aspiracional
• 2. Layout do Repositório
  • Exemplo de Layout
  • Adaptando o Layout
• 3. A Camada de Especificação
  • Especificações de Intenção (NLSpec)
  • Contratos
  • Restrições
• 4. Cenários como Validação de Holdout
  • A Analogia do Conjunto de Holdout
  • O que Faz um Bom Cenário
  • Armazenando e Gerenciando Cenários de Holdout
  • O Problema da Autoria de Cenários
• 5. O Ciclo de Desenvolvimento da Fábrica
  • O Padrão Atraente
  • Execução de Agentes Alinhados ao Provedor
  • Convergência e o Universo do Gêmeo Digital
  • A Métrica de Satisfação
• 6. Observabilidade de Produção e Evolução da Especificação
  • Três Categorias de Sinal de Produção
  • O Estado Atual da Produção -> Feedback da Especificação
  • Como um Ciclo de Feedback de Produção Poderia Ser
• 7. A Fronteira Interativa/Não Interativa
  • Padrão de Trabalho de Turno do StrongDM
  • Quando a Especificação Está Completa?
  • A Arquitetura de Conjuntos de Agentes Separados
  • Paisagem da Indústria
• 8. Evoluindo Especificações ao Longo do Tempo
  • Versionamento de Especificações
  • Padrões de Sistemas Existentes
  • O Fluxo de Trabalho de Emenda de Especificação
• 9. Coordenação de Fronteira SOA
  • O Problema de Coordenação
  • Fora do Escopo
• 10. Aplicabilidade Além da SOA
• 11. Resumo da Ferramenta
  • Autoria de Especificações
  • Orquestração da Fábrica
  • Contexto e Estado
  • Identidade do Agente
  • Habilidades e Capacidades
  • TUI Agente
• 12. Começando
  • Comece a experimentar
  • Deixe seus agentes lerem este guia
  • Notas sobre o uso do Kilroy
• 13. Fora do Escopo
• 14. Questões Abertas
  • Completude e Validação da Especificação
  • Sinais de Produção e Evolução da Especificação
  • Escalonamento e Complexidade
  • Integração Empresarial e Auditabilidade
  • Código Gerado como Artefato
• 15. Perspectiva de Encerramento
  • O que vem a seguir?
• Referências e Leitura Adicional
• Apêndice: Uma Nota Pessoal

Resumo Executivo

O padrão de fábrica de software representa uma mudança fundamental na forma como o software é construído: humanos escrevem especificações, agentes de codificação produzem a implementação e um processo de validação separado verifica a correção — sem revisão de código humano. Na taxonomia de cinco níveis de Dan Shapiro [1], esta é a transição do Nível 4 para o 5 — de humano como gerente de engenharia para "fábrica escura". Este guia descreve a mecânica emergente para implementar esse padrão dentro de uma arquitetura orientada a serviços empresarial — o que é conhecido, o que está funcionando e o que permanece não resolvido.

A ideia central. O repositório codifica uma divisão fundamental entre o que os humanos gerenciam e o que as máquinas produzem. Um "engenheiro de contexto/intenção" gerencia o lado humano: especificações (intenção descrevendo o que o software deve fazer e por quê, contratos definindo limites exatos da API com serviços vizinhos, restrições estabelecendo invariantes não negociáveis), cenários de holdout para validação, configuração de orquestração da fábrica e documentação. O lado da máquina é o código gerado por agentes — verificado no controle de versão para auditabilidade, mas tratado como uma saída opaca cuja correção é verificada exclusivamente através do comportamento observável externamente. A contribuição intelectual do humano está inteiramente a montante da implementação.

A inovação chave: validação de cenários de holdout. Tomada da prática de aprendizado de máquina, os cenários usados para avaliar o software são mantidos ocultos dos agentes que o constroem. Isso previne a manipulação de recompensas — agentes otimizando para testes em vez de correção genuína. Conjuntos de agentes separados impõem isso: agentes de refinamento de especificações ajudam os humanos a escrever especificações e cenários, mas nunca veem o código; agentes da fábrica implementam o código, mas nunca veem os cenários; agentes de validação avaliam o software construído, mas não veem nem o código-fonte nem as especificações.

O ciclo da fábrica. O padrão Atraente [2], pioneiro do StrongDM [3], orquestra agentes de codificação através de um pipeline estruturado em grafo de implementação, teste e fases de refinamento até que o software converja para um estado validado. O grafo é expresso em formato DOT, com cada fase governada por prompts direcionados e cada transição avaliada pelo LLM. Diferentes modelos podem ser usados para diferentes fases — modelos pesados em raciocínio para arquitetura, modelos rápidos para boilerplate.

Duplas mudanças de trabalho. A mudança interativa é onde humanos e agentes colaboram em especificações, identificam lacunas e autoram cenários. A mudança não interativa é onde a fábrica opera de forma autônoma — potencialmente por horas — produzindo software sem envolvimento humano. O StrongDM chama isso de "trabalho em turnos" [3]. A fronteira entre essas mudanças é a decisão de design central: determinar quando uma especificação está completa o suficiente para execução autônoma.

O que permanece não resolvido. A observabilidade de produção alimentando a evolução da especificação é o maior problema em aberto — nenhum sistema existente fecha totalmente esse ciclo. Governança empresarial [4], proveniência de código, propagação de contratos entre serviços, transformação organizacional e gestão de custos são todas preocupações críticas reconhecidas, mas intencionalmente escopadas.

Este é um guia aspiracional. O StrongDM [3] demonstrou o padrão em uma startup com uma base de código greenfield. Nenhuma grande empresa o implementou publicamente em escala. Eu ainda não produzi software utilizável com essa abordagem — experimentos iniciais revelaram principalmente o quão difícil é definir especificações com rigor executável por máquina. O guia descreve o que está se tornando possível, fundamentado na experiência publicada do StrongDM, 8090 [5], Superpowers [6], Spec Kit do GitHub [7] e meus próprios experimentos de fábrica usando uma implementação bifurcada do Kilroy [8] (uma implementação Attractor baseada em Go). Ele é versionado porque todos ainda estamos aprendendo, e há mais por vir.

Público e Conteúdo

Este artigo é para pessoas que desejam aprender sobre, criar e executar Fábricas de Software. É principalmente voltado para ambientes empresariais mais complexos, mas qualquer projeto de qualquer tamanho pode usar as informações e técnicas apresentadas.

Foi pesquisado, redigido e editado com a ajuda de IA — travessões e tudo — com significativa curadoria manual, adições de conteúdo e edição.

A nota pessoal no final, no entanto, foi inteiramente concebida e escrita por um humano.

É longo, mas isso é intencional.

O objetivo é ser uma combinação de "aqui estão alguns detalhes concretos sobre como você pode realmente começar a fazer isso"