Gergely Orosz: a IA gera 100x de código, e o que muda?

Em maio de 2026, Gergely Orosz fez algo que quase ninguém fez no auge da euforia com IA generativa: voltou quarenta anos para trás e releu um ensaio pessimista. O texto é "No Silver Bullet", que Fred Brooks, o autor do clássico "The Mythical Man-Month", publicou em 1986. Orosz, que escreve a maior newsletter de engenharia de software do mundo, usou o velho ensaio para fazer a pergunta que o mercado evita: a IA que gera código aos montes é, finalmente, a bala de prata que Brooks jurava não existir? A resposta dele é desconfortável para quem mede progresso contando linhas.

O que ele está dizendo

Comecemos por Brooks. A tese de "No Silver Bullet" é uma frase só, e continua afiada: não existe um único avanço, seja em tecnologia ou em técnica de gestão, que sozinho prometa nem mesmo uma melhora de uma ordem de grandeza, ou seja, dez vezes, em produtividade, confiabilidade ou simplicidade. Brooks não era pessimista por moda. O argumento dele é que a parte difícil de construir software não está em escrever o código, a complexidade que ele chamava de acidental, mas em decidir o que o software deve ser, a complexidade essencial. E essa parte essencial nenhuma ferramenta mágica derruba.

Orosz testa essa tese contra a história recente. Ele lista os avanços que de fato mudaram o trabalho de engenharia desde os anos noventa: controle de versão, IDEs modernas, CI/CD e teste automatizado, open source somado ao GitHub, a nuvem, os times de plataforma, a disciplina de confiabilidade que o Google batizou de SRE. A conclusão é reveladora. Nenhum desses, sozinho, foi a bala de prata. O ganho enorme que tivemos, talvez de dez a cem vezes na velocidade de entregar software incremental, veio da combinação deles, mais uma mudança de método, mais a remoção de atritos negativos como linguagens de máquina horríveis e ciclos de retorno lentos. Foi soma paciente, não milagre único.

E a IA? Orosz é direto. À primeira vista, a IA gera cem vezes ou mais de código. Mas as melhoras que interessam, em produtividade real, confiabilidade e simplicidade, são, nas palavras dele, pouco impressionantes, ao menos por ora. Ele lembra que Brooks, ao revisitar o próprio ensaio em 1995, encontrou uma exceção curiosa: motivação, e não tecnologia, é que consegue efeito parecido com o de uma bala de prata, enquanto fatores acidentais, por melhores que sejam, não aumentam produtividade sozinhos, só a derrubam quando são ruins. O ponto que atravessa quarenta anos é que remover atrito ajuda, mas não transforma a natureza essencial do problema.

Não existe um único avanço que, sozinho, prometa dez vezes de melhora em produtividade, confiabilidade ou simplicidade. Brooks escreveu isso em 1986. Orosz mostra que ainda vale.

A nossa leitura

A releitura do Orosz é útil porque desarma a métrica errada que dominou a conversa sobre IA em produção. Contar linhas de código geradas, ou pull requests abertos, é medir a complexidade acidental, justamente a parte que sempre foi fácil e que a IA de fato acelera. O gargalo nunca esteve aí. O gargalo está em decidir o que construir, integrar com sistemas que já existem, manter o que foi feito e operar isso com confiabilidade. Gerar dez vezes mais código para um problema mal definido só acelera a produção de dívida.

Isso conversa direto com coisas que a gente defende aqui. Quando Andrej Karpathy diz que a IA automatiza tudo que dá para verificar, ele está dizendo o mesmo de outro ângulo: a bala de prata não é o modelo, é a sua capacidade de definir o que é bom e checar se foi entregue. Quando Kent Beck lembra que ninguém quer agente, todo mundo quer resultado, é a complexidade essencial de Brooks aparecendo de novo. A ferramenta é acidental. O resultado é essencial.

Há um contraponto honesto que a própria história do Orosz sugere. Se controle de versão, CI/CD e nuvem não foram balas de prata sozinhos, mas somados mudaram tudo, talvez a IA seja mais uma peça dessa soma, não a soma inteira. A leitura madura não é nem "a IA muda tudo" nem "a IA não muda nada". É que a IA entra na longa lista de alavancas que só rendem dez vezes quando combinadas com disciplina, método e uma definição clara do problema. Sozinha, ela multiplica o que você já faz, para o bem e para o mal.

O uso prático disso é quase um alívio. Você não precisa esperar o modelo perfeito para ter ganho, e não precisa temer que uma única ferramenta torne obsoleto tudo que você sabe. O trabalho essencial, entender o domínio, decidir o que importa, integrar, manter e operar com confiabilidade, continua sendo o trabalho. A IA torna caríssimo continuar fingindo que dava para pular essa parte. Quem já a fazia bem ganha uma alavanca. Quem terceirizava o julgamento para a ferramenta descobre que a ferramenta agora escreve mais rápido o software errado.

Se você quer parar de medir a sua adoção de IA por volume de código e começar a medir pelo que Brooks chamaria de essencial, resultado, confiabilidade e simplicidade, fale com a AI Boutique no WhatsApp. A gente ajuda a trocar a métrica de vaidade pela métrica que paga a conta.