O setor de tecnologia já viveu isso antes. Uma explosão de demanda por software, ferramentas que prometiam democratizar o desenvolvimento e uma geração de sistemas indo para produção sem a maturidade técnica necessária para sustentá-los. Foi nos anos 1970. E tem tudo para se repetir agora.
A crise que a gente esqueceu
Nos anos 1970, o setor de tecnologia viveu o que ficou conhecido como a crise do software. A demanda por sistemas cresceu muito mais rápido do que a capacidade da indústria de desenvolvê-los com qualidade. Não existiam práticas estabelecidas nem engenharia de software como disciplina consolidada. O resultado foi uma geração de sistemas caros, frágeis, cheios de falhas e extremamente difíceis de manter. Boa parte das boas práticas que a gente usa até hoje — testes automatizados, princípios de design, arquitetura em camadas, revisão de código — nasceu como resposta direta a esse período.
O que chama atenção agora é que a gente está vendo um padrão parecido se formar, só que com uma velocidade muito maior e uma escala muito maior.
Isso não é a primeira vez que uma ferramenta “ia matar o desenvolvedor”
Antes de entrar no problema atual, vale lembrar que essa narrativa não é nova. O WordPress e o Magento democratizaram a criação de sites e lojas virtuais — e geraram uma demanda enorme por desenvolvedores especializados em manter, customizar e corrigir exatamente esses sistemas. O Ruby on Rails, o Django, o scaffolding do Laravel e de dezenas de outros frameworks prometiram acelerar tanto o desenvolvimento que qualquer um poderia construir uma aplicação web. E aceleraram mesmo. Mas o que aconteceu com os sistemas que foram para produção sem uma base técnica sólida? Viraram pesadelo de manutenção.
O padrão é sempre o mesmo: a ferramenta reduz a barreira de entrada, aumenta o volume de software produzido e, inevitavelmente, aumenta também o volume de software ruim em produção. O que muda com a IA não é o padrão — é a escala.
O problema real do Vibe Coding
O Vibe Coding — termo que ficou famoso para descrever a prática de gerar código com IA sem necessariamente entender o que está sendo produzido — não é em si o problema. A IA como ferramenta de desenvolvimento é genuinamente poderosa e vai continuar evoluindo. O problema é a combinação de três fatores que estão acontecendo ao mesmo tempo.
O primeiro é o descaso com os princípios básicos da engenharia de software. Qualidade de código, cobertura de testes, controle de acesso, tratamento de erros, gestão de segredos, auditoria de ações — são requisitos não funcionais que existem em qualquer sistema sério e que raramente aparecem nos tutoriais de vibe coding. Um sistema gerado por IA que não trata autenticação corretamente não é um protótipo interessante. É uma vulnerabilidade esperando para ser explorada.
O segundo é o débito técnico que está sendo acumulado em silêncio. Código que funciona no demo muitas vezes não foi pensado para escalar, para ser mantido por outra pessoa seis meses depois, para sobreviver a uma mudança de requisito. Quando esses sistemas chegarem a produção de verdade — com dados de usuários reais, com volume real, com times que precisam evoluir o que foi construído — alguém vai ter que resolver. E esse alguém vai ser um desenvolvedor com base técnica sólida, chamado às pressas para consertar o que foi entregue rápido demais.
O terceiro fator é o mais delicado: tem muito CEO aparecendo em podcast garantindo que demitiu o time de desenvolvimento e está entregando software só com IA. Alguns desses casos são reais dentro de um escopo muito limitado. A maioria é narrativa de quem vende curso e tem interesse em alimentar o hype. Quando os problemas começarem a aparecer — e vão aparecer — essas pessoas não vão voltar ao mesmo podcast para contar que deu errado. Mas alguém vai ser chamado para resolver a privada entupida no fim de semana.
A conta do hardware e da energia que ainda vai chegar
Tem outro componente nessa equação que quase ninguém está calculando: o custo real da infraestrutura de IA.
As grandes empresas do setor estão queimando caixa em velocidade impressionante para ganhar mercado, construir as melhores ferramentas e manter os preços por token baixos o suficiente para que a adoção exploda. Isso é uma estratégia deliberada — e tem prazo de validade.
À medida que a adoção da IA aumenta, a conta de hardware e energia sobe junto. Data centers que rodam LLMs — Large Language Models, modelos de linguagem de grande escala — consomem quantidades de energia que já estão pressionando a infraestrutura elétrica em várias regiões do mundo. Os anos 1970 tiveram a crise do petróleo empurrando o setor a otimizar o consumo de hardware. A IA pode nos levar a um ponto parecido — onde o custo por token sobe de forma significativa à medida que a euforia inicial passa e as empresas precisam começar a lucrar.
Isso não significa que a IA vai ficar inviável. Os modelos vão continuar ficando mais eficientes, assim como o hardware ficou. A questão é: no equilíbrio entre custo crescente de infraestrutura e eficiência crescente dos modelos, onde o preço vai se estabilizar? Ninguém sabe. E construir toda uma estratégia de produto com dependência total de tokens baratos, de um único fornecedor, sem nenhuma camada de abstração — é exatamente o tipo de acoplamento que qualquer engenheiro de software sabe que vai cobrar um preço mais pra frente.
O que isso significa na prática
Nada disso é um argumento contra o uso de IA no desenvolvimento de software. É um argumento contra o uso irresponsável — e contra a narrativa de que qualquer pessoa sem base técnica pode construir software de produção só porque tem acesso a um LLM.
A engenharia de software existe porque software ruim tem consequências reais: prejuízos financeiros, vazamentos de dados, sistemas indisponíveis, falhas de segurança. Essas consequências não desaparecem porque o código foi gerado por uma IA. Na prática, elas ficam mais prováveis quando quem está gerando o código não tem condições de avaliar o que está sendo produzido.
O desenvolvedor com base técnica sólida não vai ser substituído por essa onda. Mas vai ser cada vez mais chamado para resolver o que ela deixar pra trás. A questão é se você quer ser quem constrói as coisas certas desde o início — ou quem é acionado às pressas quando elas quebram.
Essa reflexão foi inspirada por uma observação do Bruno Santos — mais conhecido como Bruno on Apps — desenvolvedor com mais de 20 anos de experiência que levantou exatamente esse ponto: a gente está ganhando em velocidade de produção e regredindo em engenharia. E os dois deveriam andar juntos, não em direções opostas.
Assista também: A Inevitável Evolução do Dev Backend para Dev de IA em 2026: As 7 Skills que Você Precisa Dominar
Treinamentos relacionados com essa postagem
