Já percebeu que, quanto mais a tecnologia avança e economiza recursos, mais a gente parece consumir?

Pois é, essa contradição não é de hoje. Lá em 1865, o economista britânico William Jevons já tinha percebido isso: enquanto as máquinas a vapor se tornaram mais eficientes e passaram a gastar menos carvão, o consumo total de carvão não caiu - muito pelo contrário. Como a energia ficou mais barata, a indústria encontrou um monte de novas utilidades para ela, fazendo a busca por carvão disparar como nunca. Esse fenômeno ficou conhecido como o Paradoxo de Jevons (ou, mais popularmente, efeito rebote).

Avançando para os dias de hoje, na era da inteligência artificial generativa, esse mesmo efeito rebote governa a produção de software. A IA derrubou drasticament o custo para gerar código, criar boilerplates e escrever testes. No entanto, Jevons não falha: com o código ficando mais “barato”, a demanda por ele explodiu, e o volume de software e a complexidade dos sistemas dispararam. Projetos que antes eram engavetados por falta de verba ou tempo - como criar e testar microsserviços inteiros com equipes reduzidas - tornaram-se subitamente viáveis.

O papel do desenvolvedor

Com isso, o verdadeiro gargalo do desenvolvimento mudou de lugar. Escrever código deixou de ser a parte mais difícil. Hoje, o desafio da engenharia de software reside na orquestração de ambientes altamente distribuídos, garantir observabilidade, cuidar da segurança e desenhar arquiteturas robustas.

O papel do desenvolvedor mudou: viramos supervisores da IA. Mas isso traz um preço alto, que podemos chamar de dívida técnica cognitiva. Quando a IA gera um código que funciona de primeira, fazemos uma revisão superficial, igual quando aprovamos o Pull Request de um colega sem olhar direito. Sim, eu sei que você também já fez isso :P.

Só que existe uma diferença importante entre produzir software rapidamente e absorver conhecimento rapidamente. A IA acelera brutalmente o primeiro processo; o segundo continua limitado pelo cérebro humano.

Antes, um desenvolvedor passava horas transformando entendimento em código. Agora, ele passa horas tentando transformar código gerado automaticamente em entendimento. E esse processo é muito mais lento, cansativo e traiçoeiro.

Ao pular a etapa de quebrar a cabeça desenhando a solução, você perde o modelo conceitual do sistema. Aí, quando dá pau em produção, você é obrigado a fazer uma engenharia reversa na sua própria codebase pra entender por que aquela abstração existe, qual era a intenção original daquela camada intermediária ou por que existem três classes diferentes fazendo praticamente a mesma coisa.

E o mais perigoso é que, na maioria das vezes, o código nem está “errado”. Ele compila, passa nos testes e entrega a feature. O problema é outro: ninguém realmente entende o sistema como um todo.

A explosão do software descartável

Existe um outro efeito colateral curioso em tudo isso: quando o custo de criar software cai drasticamente, passamos a criar software para problemas que talvez nem devessem ser resolvidos com software.

Automatizamos tarefas irrelevantes porque agora “é rápido fazer”. Criamos skills para bater ponto com um prompt, onde antes bastava clicar em alguns botões. Surgem ferramentas internas que vivem poucas semanas, APIs experimentais e integrações que ninguém sabe se ainda são relevantes, mas que estão lá porque “vai que quebra alguma coisa”.

Antes, criar um novo serviço exigia planejamento, alinhamento entre times, implementação, testes, infra e uma dose de sofrimento. Hoje, basta um prompt relativamente bom, meia hora refinando respostas e pronto, nasceu mais um serviço candidato a virar dívida técnica.

O novo recurso escasso

Durante décadas, o desenvolvimento era limitado principalmente pela capacidade humana de escrever código. Agora, o limite passou a ser nossa capacidade de compreender, manter e operar a quantidade absurda de código que conseguimos gerar. Estamos entrando em uma era onde software deixa de ser escasso, e o recurso escasso passa a ser entendimento.

Nesse cenário, o valor do desenvolvedor muda. O diferencial deixa de ser “quem escreve código mais rápido” e passa a ser “quem consegue controlar a complexidade sem perder entendimento do sistema”. Arquitetura, modelagem, observabilidade, capacidade de debugging e pensamento sistêmico deixam de ser habilidades secundárias e passam a ser o verdadeiro núcleo da engenharia de software moderna.

No fim das contas, código nunca foi o produto final. Código é apenas o mecanismo que transporta entendimento humano para a máquina. E entendimento continua caro.

O Paradoxo de Jevons mostra que eficiência raramente reduz consumo - ela apenas muda a escala do problema. A IA não está eliminando a complexidade do software, e sim nos permitindo produzir complexidade numa velocidade sem precedentes.