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 a engenharia reversa de tudo em mais de 100.000 regras em inglês claro em 40 dias. Ao terminar esse trabalho, percebi por que a expressão "fábrica de software" de repente estava sendo usada por todo mundo 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. Fábricas de software têm cinquenta anos de história por trás delas, e sua característica definidora singular é algo de que as empresas precisam mais do que nunca: um sistema de produção que garanta a entrega. Isso contrasta com uma frustração crescente em relação a um conjunto disperso de ferramentas que empoderam indivíduos, mas estão tornando os sistemas inteiros mais caóticos.
O termo é mais antigo do que a maioria 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 defeito 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 fábricas de software 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 como os carros são construídos: 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 esforços heroicos posteriores. A Força Aérea dos EUA opera fábricas de software hoje. A Kessel Run constrói e opera software de missão para o Departamento de Defesa, e quando esse software quebra, eles são responsáveis.
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 insumos, produzia bens acabados e respondia pela qualidade desses bens. Dito de outra forma, a Ford nunca te vendeu uma chave inglesa, algumas peças e te 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 diria que as fábricas de software modernas devem se conformar a ele também.
Os cinco testes
Uma fábrica de software deve passar em cinco testes. Erre qualquer um deles e 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 pela intenção do negócio. O insumo 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 o insumo, em vez disso, for um ticket do Jira escrito por um engenheiro para outro engenheiro, você está olhando para uma ferramenta elétrica acoplada a um processo existente. O objetivo central 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. Toda alteração é uma chance para 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. Dê a esse distanciamento vinte anos para se acumular e você obtém 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 aumenta de 5 a 8% ao ano e uma organização que não consegue 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 fábrica de software 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. Faça um hotfix no 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. Dê o mesmo agente de codificação para dois engenheiros e você obterá resultados radicalmente diferentes, dependendo de quem escreve os prompts, quem revisa os diffs e quem detecta 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 o que os controles estatísticos da Hitachi foram construídos para garantir: a qualidade como uma propriedade da linha, não do operador.
A maneira 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 for 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 exige responsabilidade. Uma fábrica sempre tem alguém específico que responde pela produção. Só que nunca depende de nenhum deles ser insubstituível. Um sistema que precisa de um herói para funcionar não tem nem responsabilidade nem fábrica. Ele 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 elas têm sido as mais lentas na adoção de ferramentas de codificação de IA. "O modelo escreveu" não é uma resposta que um auditor aceita. Uma fábrica de software 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 tem que ser incorporada na linha de produção, o que significa que documentação escrita depois do fato não conta.
Teste cinco: alguém é responsável pelo produto finalizado. Este é o teste que separa uma fábrica de software de uma ferramenta de desenvolvedor, porque é aquele que a maioria dos fornecedores de ferramentas não está disposta a cumprir.
Uma fábrica entrega um produto pelo qual ela se responsabiliza. Quando o motor de faturamento calcula mal uma reclamaçã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 produção é 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% os sinistros encaminhados a um fornecedor de pagamento por captura, evitando mais de US$ 20 milhões em quatro anos. Números como esses só acontecem quando a parte que faz o trabalho é responsável pelo resultado.
O que não é uma fábrica
Aplique os testes e muitos que se autodenominam uma fábrica são, na verdade, outra coisa.
Agentes de codificação, por mais bons 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 te 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 fábrica de software uma pergunta: quando o sistema quebrar em produção, quem atende a chamada?
No caso de uma fábrica de software, a resposta deve ser "nós".
