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