IA acaba com a classe média da engenharia de software
Lembre-se de 2020. Você é a pessoa mais experiente da sua equipe, responsável pela qualidade do código e pela arquitetura. Você estabeleceu boas práticas de engenharia, revisa minuciosamente os PRs (Pull Requests, ou solicitações de pull, que são propostas de mudanças no código) de colegas menos experientes e trabalha duro para manter uma base de código (codebase) saudável.
Aí, em algum momento, você tira férias. Quando volta, a base de código está uma bagunça. Todo mundo mergeou os PRs uns dos outros sem muita atenção, alguém adicionou um monte de tabelas novas ao banco de dados para desnormalizá-lo (otimizar para leitura, duplicando dados) porque era mais fácil, e adicionaram serverless ou Kafka ao stack sem nenhuma evidência sólida de que precisavam de um ou de outro. Tudo bem. Você consegue consertar isso.
Agora, avance para 2026. Você não tirou férias. É apenas uma segunda-feira de manhã normal. Você prepara um bom café, abre seu computador e se depara com 7 PRs para revisar. Você abre o primeiro: +24506 -3938 linhas, acompanhado de uma descrição gerada por IA sobre o que deveriam fazer. De alguma forma, sua equipe fez mais mudanças desde sexta-feira do que costumava fazer enquanto você estava fora por algumas semanas.
A IA Removeu o Limite de Velocidade
A IA faz com que projetos com uma cultura de engenharia fraca falhem muito mais rapidamente. Antes, as pessoas se sentavam e conversavam sobre como fariam algo. Agora, elas podem apenas "promptar" (dar um comando) a um agente por algumas horas e abrir um PR. O aspecto mais trágico dessa forma de trabalhar é que, aos olhos destreinados, funciona.
Se você puxar a branch (ramo de desenvolvimento) e testá-la, provavelmente obterá algo funcional. Então, o que eles fazem? Continuam. De novo e de novo. Até que o projeto atinge um ponto em que ninguém sabe como nada funciona. É como alguém comprando um carro de luxo com um cartão de crédito. Você não vê a dívida. Você apenas vê o carro que parece ótimo.
Mas então os usuários começam a relatar um bug estranho. É a quarta vez que sua equipe tenta corrigi-lo. Ou melhor... pedindo à IA para corrigi-lo. Infelizmente, parece que nem mesmo o Fable consegue descobrir. Você vai conversar com a pessoa que trabalhou nessa funcionalidade.
- "Então, de onde vêm os dados?"
- "Hmm... na verdade, não sei. Deixe-me perguntar ao Claude."
Vocês se sentam lado a lado, observando uma parede infinita de texto aparecer na tela. Nenhum de vocês tem ideia se algo daquilo é verdade, mas o Claude parece muito confiante.
- "Vamos apenas ligar o ultracode e pedir para ele verificar novamente?"
Isso vai demorar um pouco. Vocês começam a conversar sobre o último drama no X. Finalmente, vocês recebem uma resposta.
- "Isso faz algum sentido para você?"
- "Não tenho certeza."
- "Você não construiu isso... na semana passada?"
Silêncio. Este projeto se tornou tão complicado, com tantas camadas e serviços, que ninguém na sua equipe poderia sequer começar a entender o que está acontecendo.
O Custo Oculto da Produtividade Superficial
Sempre que falo sobre isso, alguém acaba me dizendo que ninguém nunca entendeu sistemas grandes por completo. É verdade. Você nunca foi obrigado a entender cada serviço e cada banco de dados. Mas pelo menos alguém entendia e poderia explicar para você. Agora, eles perguntam a um LLM (Large Language Model, ou Modelo de Linguagem Grande) porque eles próprios não sabem.
Você não pode mais se dar ao luxo de ter engenheiros ruins. Em toda equipe, há pessoas competentes que tornam o projeto possível. Há também pessoas que, essencialmente, dificultam as coisas para todos os outros. E agora, qualquer um pode produzir mais código em um dia do que costumava produzir em um ano.
Na história acima, todos estão falhando:
- O engenheiro que abre um PR de 25.000 linhas deveria ter parado o agente muito antes de chegar a esse ponto. Ele deveria ter entendido o que estava fazendo, dividido o trabalho em partes menores e questionado cada nova abstração que a IA introduzia.
- A pessoa que revisa deveria ter se recusado a revisar algo tão grande, em vez de ceder.
- A pessoa que adicionou o Kafka (uma plataforma de streaming de dados) deveria ser capaz de explicar exatamente por que era necessário.
- A pessoa que construiu a funcionalidade deveria ser capaz de explicar de onde vinham os dados sem enviar um link para uma conversa do Claude.
Mas qual é o problema então? Apenas use a IA para consertar. Bem, não é tão fácil...
Reverter uma decisão ruim é difícil. Muito difícil. Por exemplo, quanto tempo levaria para um LLM adicionar um monte de tabelas e colunas ao banco de dados? 10 minutos? Mas depois que você começa a armazenar dados lá, você não pode simplesmente removê-los. Você tem que criar um plano de migração, garantir que não interrompa o sistema porque as pessoas estão pagando para usá-lo todos os dias. Você tem que pensar no que fará se a migração falhar. Certificar-se de não acabar com chaves estrangeiras órfãs (referências a dados que não existem mais). É muito mais difícil de consertar. Mesmo com o melhor modelo que você pode conseguir.
E enquanto você está consertando, mais PRs continuam chegando. Mais código, mais abstrações, mais decisões. Uma pessoa pode gerar 20.000 linhas de código em uma tarde, mas você ainda tem que sentar e entender o que essas linhas realmente fazem.
Por Que Isso Importa: A Demanda por Engenheiros de Alto Calibre
A IA não é uma bala de prata que substitui o pensamento crítico; ela o amplifica. Em vez de remover a "classe média" da engenharia de software, a IA está elevando o sarrafo. Ela está filtrando aqueles que dependem apenas da geração de código e não possuem uma compreensão profunda dos princípios de engenharia, arquitetura de sistemas e as implicações de longo prazo de suas decisões.
Para construtores e tomadores de decisão em tecnologia, a lição é clara: a proficiência em IA é crucial, mas a capacidade de questionar, entender, decompor problemas complexos e manter a qualidade do código é mais valiosa do que nunca. Invista em uma cultura de engenharia robusta, onde a revisão crítica, a justificação de decisões técnicas e o entendimento profundo do sistema são priorizados. Só assim você poderá aproveitar o poder da IA sem se afogar na dívida técnica que ela pode gerar.
Fontes
📬 Gostou? Assine a newsletter do Vaccari's Code e receba as próximas tendências em software e IA direto no seu e-mail: Assinar aqui