A ilusão da fábrica de software

Junho de 2000. Eu era um estudante de Ciência da Computação tentando entender onde iria trabalhar nessa profissão. Havia um certo pessimismo no ar, porque a bolha da internet tinha acabado de estourar, mas isso não me preocupava tanto quanto outra coisa que, aparentemente, ninguém mais notava.

O mercado era dominado pelas famigeradas fábricas de software. Na minha cabeça, “software” e “fábrica” eram palavras que não cabiam na mesma frase, mas todo mundo parecia aceitar o termo como algo respeitável e cheio de conhecimento. Para mim, o que estavam vendendo era uma ilusão: a ilusão de respostas fáceis.

Quando software virou linha de montagem

Escrever software é, por definição, criar algo que ainda não existe. Por isso todo projeto de software é um processo de descoberta. Claro que usamos bibliotecas e não reinventamos a roda a cada projeto, mas em algum momento todo projeto pisa em terreno desconhecido.

Essa natureza contrasta totalmente com o modelo fabril, que prega previsibilidade, procedimentos padronizados, métricas de resultado, throughput, cadeias de comando e hierarquias rígidas. Na fábrica de software isso aparecia como a separação entre o analista, que escrevia a especificação, e o programador, que “só” codificava. O sucesso se media em horas/homem e pontos de função, com o ponto eletrônico batendo na entrada.

É um modelo que brilha na manufatura: depois de encontrar o processo ótimo, você se dedica a reproduzi-lo o máximo possível e extrai resultados previsíveis e controlados. Só que, em software, quando você já conhece o processo inteiro de antemão, provavelmente está construindo algo que já existe, e aí era melhor ter comprado pronto.

O gestor e a ambiguidade

Então por que o modelo é tão tentador?

Cada pessoa tem sua própria necessidade de ordem. Quando seu emprego depende de entregar resultados e você não controla nem o que seus liderados produzem nem a produtividade deles, o ambiente caótico do desenvolvimento de software se torna ameaçador. Some a isso prazos e orçamentos fechados meses antes de alguém entender o problema, e a fábrica passa a parecer não só razoável, mas responsável.

O problema é que eliminar o risco com uma receita que funciona em outro contexto é como dar o remédio de câncer a um paciente com tuberculose: com sorte pode até dar certo, mas tem tudo para dar errado. E o efeito colateral é previsível: em vez de mudar a gestão para caber no trabalho, deforma-se o trabalho para caber na gestão.

Risco não se elimina, se gerencia. Às vezes, inclusive, ele precisa ser colocado de propósito. Gosto muito de como o Jason Fried resume isso: “O trabalho de um fundador é injetar risco no negócio”. Ou seja, trazer ideias que parecem difíceis, que ninguém mais tentaria. Uma empresa que só tolera o previsível só consegue construir o que já foi construído.

Um contraponto importante: existem softwares em que todo esse controle se justifica. Em sistemas médicos, de aviação e aeroespaciais, ele se paga, porque o custo de um bug pode ser a vida de uma pessoa. Mas esses projetos costumam levar anos, às vezes décadas. Se a sua empresa não está nesse mundo e opera sob as mesmas premissas, ela está só queimando dinheiro.

Também não estou defendendo o oposto: empresas que empurram prazos insanos para espremer o máximo de produtividade das pessoas. Nem preciso dizer que esse tipo de empresa também não vai longe. O que estou criticando é a situação em que as pessoas desenvolvem algo só porque a liderança mandou. Ou aquela feature que ninguém entendeu, mas que está lá para ser construída, e, uma vez que você estimou, vai ter que dar um jeito de fazer acontecer. Repita isso por um tempo e o codebase vai te mostrar o resultado.

Gente que programa reagiu

Na minha visão, a profissão estava indo para um rumo ruim. Felizmente, pouco tempo depois, em fevereiro de 2001, um grupo de malucos publicou o Manifesto Ágil. Com o tempo, as grandes empresas o adotaram e boa parte da essência se perdeu no caminho, mas isso é assunto para outro post.

O importante é que quem programa sabe que XP funciona, porque é algo que nasceu da prática, de pessoas que vivem a programação, e não do anseio de gestores por previsibilidade e controle. Aos poucos as empresas foram abandonando o caminho waterfall, e as mesmas vozes por trás do manifesto, como Kent Beck e Martin Fowler, ajudaram a educar uma parte considerável do mercado.

Caos que funciona: Conectiva

Enquanto isso, aqui no Brasil havia um exemplo do outro extremo. A Conectiva, fundada em Curitiba em 1995, mantinha uma distribuição Linux inteira: empacotava milhares de programas, traduzia tudo para português e espanhol e criou ferramentas próprias, como o porte do APT para pacotes RPM. Era trabalho de exploração, sem manual, em sincronia com uma comunidade de software livre espalhada pelo mundo. Em 2005 ela se fundiu com a francesa MandrakeSoft, formando a Mandriva.

O que ouvi sobre a Conectiva veio de relatos em podcasts: um lugar quase anárquico, onde argumentos eram vencidos com código e não em reuniões, e onde o horário era totalmente livre. Não consigo confirmar o quanto disso é verdade e o quanto é folclore, mas aquilo ficou na minha cabeça como o lugar onde todo programador amaria trabalhar. E, verdade ou não, a imagem diz muito: o oposto da fábrica não é a desordem, é a confiança em quem está fazendo o trabalho.

Um pouco de bagunça

Anos depois, em 2009, li um post do Thiago Arrais chamado “Bagunça pode ser tudo o que você precisa”. Ele não me ensinou nada novo. Fez algo melhor: colocou em palavras uma coisa que eu cultivava desde a faculdade. A desordem aparente do trabalho real não é necessariamente um defeito a ser corrigido, e organizar demais o trabalho das pessoas costuma engessá-lo. O texto soava como alguém que vivia o desenvolvimento por dentro, não como um vendedor de metodologia. Recomendo muito a leitura.

A fábrica volta com agentes de IA

Estamos em 2026, e uma tecnologia disruptiva barateou radicalmente o custo de produzir software. A IA realmente mudou o cenário. E, no meio disso, o sonho fordista voltou a ser alimentado.

As promessas variam, mas a essência é a mesma: domesticar o animal selvagem e torná-lo previsível. Escreva uma especificação detalhada, entregue a um exército de agentes e espere o software sair do outro lado da esteira. Repare que é exatamente a divisão de 2000 entre o analista que pensa e o programador que executa. Só trocaram o programador pelo agente. Como já falei, parte disso se explica pela psicologia humana de rejeitar o desconhecido.

Só que gerar código nunca foi o gargalo. O gargalo mudou de lugar: escrever ficou barato, mas entender o problema, manter o sistema e alinhá-lo ao domínio do negócio continua caro, e pode até ficar mais caro quando o repositório se enche de código que ninguém precisou entender para produzir. A ideia do código descartável (“se ficar ruim, a IA reescreve”) esquece que software não vive no vácuo: tem dados em produção, integrações, regras de compliance e regras de negócio que só existem na cabeça de quem opera a empresa.

E há um custo menos visível. Quando o engenheiro vira só inspetor do que o agente produziu, o contexto se perde. Quando o sistema quebra às três da manhã, alguém precisa saber por que ele foi desenhado daquele jeito, e esse conhecimento não estava na especificação.

Há ainda uma oportunidade que poucos estão vendo. Se o código ficou barato e rápido de escrever, o programador pode participar mais do negócio, eliminar intermediários e deixar de ser centro de custo para se tornar gerador de riqueza. Prototipar, descartar o que não funciona e manter o que funciona continua sendo o caminho, só que muito mais rápido. E fazer essas escolhas vai continuar sendo trabalho artesanal.

Conclusão

Este é o momento em que as pessoas esperam que eu critique a IA. Vou decepcioná-las. Acho que a IA tem tanta capacidade quanto os humanos de escrever software quando o contexto é claro, talvez mais. LLMs são ferramentas fantásticas, mas continuam sendo ferramentas, e têm limitações. Você pode delegar a parte mecânica da escrita de software, mas não pode delegar entendimento, responsabilidade nem finalidade.

Entendimento, porque o modelo trabalha com o contexto que você entrega, e descobrir qual é o contexto certo é justamente o trabalho. Que problema estamos resolvendo? Qual concessão vale a pena? Revisar código que você não entende não é revisão, é carimbo.

Responsabilidade, porque quando algo dá errado, quem responde ao cliente, ao contrato e ao regulador é uma pessoa. Um slide atribuído a um treinamento da IBM de 1979 já dizia: “um computador nunca pode ser responsabilizado; portanto, um computador nunca deve tomar uma decisão de gestão”.

Finalidade, porque decidir o que construir, para quem e, principalmente, o que não construir é uma escolha sobre valores e sobre o negócio, não sobre sintaxe. O agente otimiza para o prompt; alguém precisa otimizar para o propósito.

A fábrica de software dos anos 2000 falhou porque fingia que essas três coisas podiam ser separadas da execução. Usar uma ferramenta poderosa ajuda muito, mas não muda a natureza intrínseca da profissão. Software continua sendo descoberta, e um pouco de bagunça continua sendo o que separa software vivo de linha de montagem.