A facilidade de gerar código criou uma expectativa surreal: a de que software é só o que aparece na tela.

Antes de mais nada, deixe eu reforçar: não sou contra IA, longe disso - uso Deepseek e Claude diariamente. Dito isso, deixa eu contar um negócio que me aconteceu recentemente.

Você está construindo um sistema novo pra operações. Na hora de refinar os requisitos, ninguém do negócio tem tempo, e ninguém quer definir prioridades. O que você faz? O básico bem feito: entrega um MVP decente, com arquitetura, funcional e confiável, e empurra o “nice to have” pra versão seguinte.

O tempo passa, e logo vêm os Tá demorando. Cadê a feature X?

Aí, ao invés de sentar para um alinhamento, alguém da operação abre o Claude e resolve botar a mão na massa, e três dias depois o sujeito aparece com um sistema que tem tudo que eles pediram, e é bonitinho, clicável, navegável. A gestão, obviamente, adora, e já fica o questionamento no ar: “Se fulano fez isso em três dias com IA, por que antes tava demorando tanto?”

Bom, aí que tá - a resposta está justamente naquilo que não aparece na tela. Você abre o código do “sistema mágico” e… bem, é uma experiência: não tem backend, o banco de dados é o localStorage do navegador, junto do token JWT, a regra de negócio tá misturada num arquivo só — cinco mil linhas de JavaScript cru. Sem testes, sem governança. Segurança? So yo. Isso tem um nome, que é vibe coding.

O paralelo com arte gerada por IA é impossível de ignorar: assim como qualquer um consegue gerar uma ilustração bonita com IA mas isso não faz da pessoa um artista, o vibe coding gera software com aparência de sistema, mas sem ninguém que entenda o que tem por baixo e, quando quebra, não tem quem conserte. Nos dois casos, o resultado é o mesmo: o ofício é banalizado e a percepção de valor do trabalho especializado desaba.

Enquanto isso, o “produto demorado” tem arquitetura definida, banco relacional, migrations, CI/CD, observabilidade, testes automatizados. Numa demo de cinco minutos, os dois parecem iguais, mas a diferença é que um é projeto de feira de ciências feito pra impressionar em pitch, e o outro é software desenhado pra sobreviver ao usuário real em plena segunda-feira de manhã, sem acordar ninguém de madrugada dois anos depois.

O que me incomoda não é ciúme porque “a IA tá escrevendo código”. O que cansa é ver o trabalho invisível ser completamente ignorado. Mas né, ninguém bate palma pra pipeline de deploy bem configurada, teste de cobertura não deixa a interface com borda arredondada, e arquitetura, segurança e monitoramento são o fundo do iceberg. É o trabalho que ninguém vê sustentando o trabalho que todo mundo vê.

Se for ver bem, a IA só trouxe à tona a obsessão da indústria por velocidade a qualquer custo. Só que qualquer um (nem precisa ser dev), com um mínimo de experiência, sabe que, quando tudo é pra ontem, nada é prioridade. Nesse caso, o resultado não é entrega, é uma pilha de dívida técnica crescendo em silêncio. Passamos décadas refinando metodologia ágil, sprints, code review, CI/CD para, com a desculpa de que “a IA acelera tudo”, voltarmos pro bom e velho go horse: faz o que der, entrega o que sair, testa em produção e torce.

A IA deixou uma coisa escancarada: se gerar 500 linhas de código ficou instantâneo, o gargalo da engenharia nunca foi digitar. O verdadeiro gargalo sempre foi decidir:

• Decidir o que não fazer;
• Decidir quais trade-offs arquiteturais assumir agora e quais deixar depois;
• Decidir como não transformar o sistema num grande espaguete.

Nenhuma IA toma essas decisões por você.

Tem um estudo recente da GitClear mostrando exatamente isso: estamos gerando código com IA num ritmo frenético, mas o code churn (aquele código que é escrito e apagado ou reescrito na mesma semana) disparou. Ou seja, estamos digitando mais, mas criar software melhor é outra história. Voltamos a medir produtividade por linha de código, o que é um retrocesso absurdo.

O problema não é a área de negócios usar IA pra resolver dores pontuais. O perigo é a falta de maturidade técnica pra distinguir um sistema que parece pronto de um sistema que está pronto pro mundo real. Engenharia de software nunca foi sobre produzir o máximo de código possível, mas sim sobre resolver problemas de forma sustentável. Muitas vezes, a melhor decisão técnica é saber a hora de não adicionar uma feature, ou de não tratar tudo como incêndio; fazer software bem feito exige pensar, e pensar leva tempo.

Se nos reduzirmos a otimizadores de “escrever código mais rápido”, o Jevons vai rir da nossa cara: vamos passar a próxima década só corrigindo os bugs que geramos em três dias.

Desculpem o meu rant, mas fiquei indignado, decepcionado e reflexivo com essa situação. De qualquer forma, nos vemos num próximo post.

Até breve!