No início deste ano, nossa equipe na 8090 desmontou o motor de faturamento de uma grande entidade. Eram 18 milhões de linhas de COBOL e Assembly que vinham se acumulando desde antes de alguns de nossos engenheiros nascerem. Ninguém mais o entendia por completo, mas usando nossa Software Factory, fizemos engenharia reversa dele em mais de 100.000 regras em inglês claro em 40 dias. Ao terminar esse trabalho, percebi por que a frase "software factory" de repente estava sendo usada por todos os outros também.
O conceito está sendo apropriado porque implica um certo nível de confiabilidade industrial que as empresas desejam, mas não estão obtendo. As software factories têm cinquenta anos de história por trás delas, e sua característica definidora singular é algo que as empresas precisam mais do que nunca: um sistema de produção que garanta a saída. Isso contrasta com uma frustração crescente em relação a um conjunto difuso de ferramentas que capacitam indivíduos, mas estão tornando sistemas inteiros mais caóticos.
O termo é mais antigo do que a maioria das pessoas imagina
A Hitachi abriu a "Software Works" em 1969 como uma fábrica literal: um prédio onde o software era produzido sob controle estatístico de qualidade, com taxas de defeitos medidas por mil linhas de código, processos padronizados e uma equipe de gestão responsável pela qualidade da produção. A Toshiba, a NEC e a Fujitsu seguiram o exemplo, e durante as décadas de 1970 e 1980, essas software factories japonesas entregaram alguns dos códigos mais confiáveis já escritos. Os sistemas que produziram alimentaram a infraestrutura bancária, ferroviária e de energia por décadas.
Em 2004, dois arquitetos da Microsoft publicaram um livro chamado "Software Factories" argumentando que o software deveria ser construído da mesma forma que os carros são feitos: a partir de componentes comprovados, em linhas de produção repetíveis, com a variação controlada pelo design inicial, em vez de corrigida por heroísmo downstream. A Força Aérea dos EUA opera software factories hoje. A Kessel Run constrói e opera software de missão para o Departamento de Defesa, e quando esse software quebra, eles assumem a responsabilidade.
Ao longo de sessenta anos, uma coisa permaneceu consistente até esta onda de IA. Uma fábrica nunca foi uma ferramenta ou um hack de produtividade, por mais bom que fosse. Uma fábrica era um sistema de produção que recebia entradas, produzia produtos acabados e se responsabilizava pela qualidade desses produtos. Dito de outra forma, a Ford nunca te vendeu uma chave inglesa, algumas peças e desejou boa sorte. A Ford te vendeu um carro, e se o carro falhasse, a Ford o recolhia, porque era a fábrica deles que o produziu.
Esse é o padrão, e eu argumentaria que as software factories modernas devem se adequar a ele também.
Os cinco testes
Uma software factory deve passar por cinco testes. Se falhar em qualquer um deles, você tem outra coisa. Essa outra coisa é muito provavelmente uma ferramenta de desenvolvedor, que pode ser útil, mas é um produto diferente com uma obrigação diferente.
Teste um: uma fábrica começa com a intenção do negócio. A entrada de uma fábrica é o que o negócio precisa, expresso na linguagem do negócio: requisitos, regras, restrições regulatórias, resultados desejados. Se a entrada, em vez disso, for um ticket do Jira escrito por um engenheiro para outro engenheiro, você está olhando para uma ferramenta poderosa acoplada a um processo existente. O objetivo principal de uma fábrica é que o cliente descreve o produto e a fábrica descobre a produção.
Teste dois: uma fábrica mantém a coerência sob mudanças contínuas. Este é o teste mais difícil, e é aquele sobre o qual quase ninguém no mercado de ferramentas de IA fala, porque seus produtos pioram a situação.
Escrever código novo nunca foi o gargalo no software empresarial. O gargalo é que um sistema real é alterado toda semana por dezenas de pessoas. Cada alteração é uma chance de o sistema se desintegrar. Os requisitos se distanciam da documentação. A documentação se distancia do código. O código se distancia dos testes. Deixe esse distanciamento se acumular por vinte anos e você terá o motor de faturamento que descrevi no início: 18 milhões de linhas que ninguém entende em sua totalidade, um contrato de manutenção com fornecedores que sobe de 5 a 8% ao ano e uma organização que não pode mais alterar seu próprio software sem medo.
A realidade é que a geração de código acelera o distanciamento. Se seus agentes produzem dez vezes mais código com base em especificações que não são mantidas sincronizadas, você está induzindo o distanciamento a uma velocidade sem precedentes. O problema de 18 milhões de linhas levou quatro décadas para ser construído manualmente, mas frotas de agentes sem governança construirão isso em alguns anos.
Uma software factory funcional mantém a intenção, a especificação, o código, os testes e o comportamento em produção sincronizados como um único objeto governado. Altere o requisito e o código muda. Corrija o código e o requisito é atualizado. Peça a um fornecedor para mostrar esse ciclo fechado, ao vivo, em um sistema real. Se eles não conseguirem, estão vendendo geração de código. E embora útil, é uma coisa diferente.
Teste três: uma fábrica opera independentemente de qualquer pessoa específica. Uma ferramenta é tão boa quanto a pessoa que a segura. Entregue o mesmo agente de codificação para dois engenheiros e você obterá resultados radicalmente diferentes, dependendo de quem escreve os prompts, quem revisa as diferenças e quem pega os erros. Essa variação é aceitável em uma ferramenta. É desqualificante em um sistema de produção. Uma fábrica deve produzir com velocidade e qualidade previsíveis, independentemente de quem está no turno, que é exatamente para o que os controles estatísticos da Hitachi foram construídos: qualidade como uma propriedade da linha, não do operador.
A forma como uma fábrica consegue isso é que o conhecimento se acumula no sistema, em vez de nos indivíduos. Quando uma pessoa entra, a fábrica entrega a ela tudo o que já aprendeu. Quando uma pessoa sai, nada sai pela porta. A maioria dos softwares empresariais falha catastroficamente neste teste. A razão pela qual um motor de faturamento se torna ilegível não é o código ruim. É que o entendimento do código vive nas pessoas, e ao longo de muitos anos, as pessoas mudam. Se o conhecimento delas nunca é capturado por um sistema, o sistema se tornará lentamente uma caixa preta.
Para ser claro, isso não significa que as pessoas não importam ou que uma fábrica não exija responsabilidade. Uma fábrica sempre tem alguém específico que responde pela produção. Simplesmente nunca depende de nenhum deles ser insubstituível. Um sistema que precisa de um herói para funcionar não tem responsabilidade nem fábrica. Tem um herói, e heróis eventualmente encontram novas aventuras.
Teste quatro: cada unidade de produção é rastreável. Em uma fábrica real, cada peça tem um "número de lote". Quando algo falha, você rastreia de volta pela linha de produção até o lote, a máquina e o turno. Indústrias regulamentadas exigem exatamente isso do software, e é por isso que foram as mais lentas a adotar ferramentas de codificação de IA. "O modelo escreveu" não é uma resposta que um auditor aceita. Uma software factory produz a trilha de auditoria como um subproduto da própria produção: esta regra existe por causa deste requisito, aprovado por esta pessoa, implementado nesta alteração, verificado por este teste, implantado neste momento. A proveniência precisa ser incorporada à linha de produção, o que significa que a documentação escrita depois do fato não conta.
Teste cinco: alguém é responsável pelo produto finalizado. Este é o teste que separa uma software factory de uma ferramenta de desenvolvedor, porque é aquele que a maioria dos fornecedores de ferramentas não está disposta a enfrentar.
Uma fábrica entrega um produto pelo qual se responsabiliza. Quando o motor de faturamento calcula mal uma reivindicação, quando o sistema de negociação produz um número errado, quando a validação de fabricação aprova uma peça defeituosa, alguém específico responde por isso, corrige e arca com os custos. Já li muitos contratos de ferramentas de IA e as seções de propriedade intelectual ocupam páginas, mas a seção de responsabilidade geralmente é uma frase, e a frase diz que a saída é fornecida no estado em que se encontra e a verificação é problema seu. Isso é completamente desqualificante para uma fábrica.
Um de nossos clientes, uma seguradora de saúde de capital aberto, transformou suas regras de contas a pagar em um pré-filtro determinístico e reduziu em mais de 80% as reclamações encaminhadas para um fornecedor de pagamento por captura, evitando mais de US$ 20 milhões em quatro anos. Números como esse só acontecem quando a parte que está fazendo o trabalho é responsável pelo resultado.
O que não é uma fábrica
Aplique os testes e muitos que se autodenominam fábrica são, na verdade, outra coisa.
Agentes de codificação, por melhores que sejam, são ferramentas. Eles recebem tarefas de engenharia como entrada, produzem código como saída e transferem toda a verificação e responsabilidade para os engenheiros do cliente. Chamar uma frota deles de fábrica não muda isso.
Painéis de orquestração de agentes são ferramentas de supervisão. Eles facilitam observar os agentes trabalhando.
Benchmarks são estruturas de medição para ferramentas. Uma pontuação alta indica que uma ferramenta é boa em tarefas de benchmark. Não pode dizer se seu sistema permanece coerente após dois anos de mudanças contínuas por equipes mistas de humanos e agentes.
Por que a definição é importante agora
O custo de produzir software está despencando. E quando os custos de produção despencam, o valor migrará para quem puder garantir a produção. Isso aconteceu em todos os processos de industrialização antes deste e acontecerá novamente agora na IA.
As startups que estão agarrando a palavra "fábrica" entendem isso instintivamente. Mas muitas estão buscando a credibilidade da produção industrial sem aceitar a obrigação que criou essa credibilidade em primeiro lugar.
Então, ignore demonstrações e benchmarks, e faça a cada software factory uma pergunta: quando o sistema quebrar em produção, quem atende o telefone?
No caso de uma software factory, a resposta deve ser "nós".
