O impacto silencioso da IA na engenharia de software

Não é segredo para ninguém que o mercado de tecnologia, assim como qualquer mercado, tem pressa. Quase sempre, a regra que manda é colocar o software no ar o quanto antes. Uma espécie de pastelaria! Com isso, ferramentas de IA como o Cursos, Copilot e o Claude acabaram virando os gênios da lâmpada de muitos diretores, gestores e até desenvolvedores. A tentação é grande: por que gastar horas raciocinando (e gastando dinheiro) com uma lógica chata ou repetindo código de API se um comando rápido resolve tudo em segundos?

Mas a questão — e que a gente raramente para pra olhar — é que essa agilidade toda pode ter um preço bem alto. Existe um efeito silencioso quando a gente usa essas ferramentas sem critério, afetando tanto no nível de contribuidores individuais, quanto estrategicamente a qualidade e longevidade do que estamos construindo. Já falei anteriormente sobre como essas ferramentas afetam nossa produtividade, mas agora tenho desenvolvido um olhar um pouco mais aprofundado sobre isso. Ou pelo menos uma outra perspectiva.

A entrega rápida e a falsa sensação de produtividade

A gente adora ver as coisas funcionando logo de cara. Pra quem trabalha com prazos apertados e metas trimestrais pesadas (alô, gestor!), a IA parece um milagre caído do céu. Afinal, se o código está pronto e a funcionalidade está rodando, a missão foi cumprida, certo? Pois é, na prática, o buraco é bem mais embaixo.

O ponto é que produzir muito ou pouco código não significa, necessariamente, produzir um software bom. O relatório de 2025 da GitClear, que analisou mais de 200 milhões de linhas de código, trouxe um dado interessante e que reafirma algo que vejo na prática: a quantidade de código "copiado e colado" já ultrapassou a de código "movido". Pra quem não é familiarizado com as métricas, "mover" código costuma indicar refatoração e cuidado. Ou seja, o esforço de reaproveitar código despencou, enquanto a clonagem de blocos inteiros disparou quase dez vezes. Me faz pensar se estamos deixando pra trás décadas e décadas de aperfeiçoamento da técnica.

Isso acaba criando uma falsa sensação de eficiência. O desenvolvedor sente que está voando, o gestor cumpre os prazos da planilha, mas o sistema, por dentro, vai virando uma colcha de retalhos. Em vez de criar componentes reutilizáveis e pensar no design, a IA incentiva (pela facilidade) a duplicar lógicas. Afinal, escrever código é instantâneo para a ferramenta. E quando um erro acontece em um desses blocos copiados? O trabalho de correção se multiplica. Não por acaso, a pesquisa do Google DORA de 2024 apontou que o aumento no uso de IA está diretamente ligado a uma queda na estabilidade das entregas.

No fim do dia, quando focamos só na entrega, perdemos aquele hábito saudável de questionar se aquela funcionalidade é mesmo necessária ou se existia um caminho mais simples. A IA nos dá a resposta pronta e a gente simplesmente para de exercitar o músculo da simplificação, da abstração e do reaproveitamento. O resultado? Um software inchado, cheio de falhas repetidas e que vai ser um pesadelo pra manter daqui a um ano.

O que a neurociência ensina sobre colocar a mão na massa

Pra entender por que a IA pode estar nos deixando mais "rasos" tecnicamente, vale olhar um pouco pra como o nosso cérebro aprende de verdade. Existe uma ciência por trás disso que a gente, na pressa do dia a dia da programação, costuma ignorar solenemente.

Um estudo importante da professora Audrey van der Meer na NTNU revelou que escrever à mão ativa áreas do cérebro ligadas à memória e ao aprendizado que a digitação nem passa perto. O esforço físico e mental de desenhar cada letra cria "ganchos" que ajudam a fixar o conteúdo de verdade.

Na nossa área, o "escrever à mão" é justamente digitar cada linha de código, encarar de frente os erros que aparecem, ler o código alheio para entender o que está implementado e entender por que aquela lógica não funcionou. É essa "briga" saudável com o computador que faz a gente aprender. Quando a IA entrega a solução mastigada, a gente pula essa etapa de esforço e o conhecimento simplesmente não fixa.

É como estudar pra uma prova: você aprende mais resolvendo os exercícios do zero ou só lendo o gabarito no final do livro? A IA é o gabarito. Ela resolve o problema agora, mas não te prepara pro próximo desafio. Sem esse esforço de construção, o desenvolvedor vira apenas um passageiro do próprio trabalho, sem entender as engrenagens do que ele mesmo está criando.

A ilusão de facilitar tudo e o desafio de quem está começando

A inteligência artificial funciona como uma camada que esconde como as coisas realmente funcionam por baixo do capô. Se antes a gente precisava entender como os dados saíam do banco e chegavam na tela, hoje parece que basta pedir com jeitinho e a mágica acontece.

Claro, alguém pode argumentar — e com razão — que a história da computação é a história das abstrações. Se não fosse por elas, ainda estaríamos furando cartões ou brigando com registradores em Assembly. Cada nova camada (do C pro Java, do Java pro Python, do bare metal pra nuvem) nos permitiu focar no que realmente importa: o problema de negócio. A IA seria, em teoria, só mais um degrau nessa escada.

O problema é que, diferente das abstrações anteriores que eram estruturais e previsíveis, a IA é uma abstração probabilística e, muitas vezes, opaca. Quando você usa um framework, você ainda entende a lógica por trás daquela ferramenta se precisar cavar um pouco. Na IA, o desenvolvedor muitas vezes aceita uma solução sem ter a menor ideia de como ela foi construída. A abstração deixa de ser uma "ferramenta de produtividade" e vira uma "muleta cognitiva".

Isso me preocupa muito, especialmente por quem está começando. O mercado está encolhendo as vagas pra iniciantes (como aponta este artigo no blog do Stack Overflow), sob a falsa premissa de que a IA faz o trabalho deles. Mas o trabalho mais simples era justamente o campo de treino. Sem passar por essas tarefas básicas, o iniciante não cria a casca necessária pra virar um profissional sênior de verdade no futuro.

A ironia da coisa é que, com a IA, estamos pedindo pra quem tem menos experiência fazer o trabalho de revisar código. Só que revisar o código dos outros (ou da IA) é muito mais difícil do que escrever o próprio. Exige uma visão de conjunto e uma malícia que só o tempo de estrada dá — algo que aprendi na prática revisando códigos em grandes projetos de código aberto.

Se o iniciante não "suja as mãos" na construção básica, ele nunca desenvolve o olhar crítico pra saber quando a IA está sugerindo uma bobagem que pode comprometer a segurança ou o desempenho. No fundo, estamos criando uma geração de revisores que não sabem como as coisas são construídas do zero. Isso é perigoso.

Engenharia de software estratégica contra o imediatismo

No fim das contas, a discussão não é só técnica, é sobre a saúde do negócio no longo prazo. As empresas querem funcionalidades prontas pra ontem, mas o que elas realmente precisam é de sistemas que continuem funcionando e evoluindo daqui a dois ou cinco anos.

É aqui que o papel estratégico do desenvolvedor se torna vital. Conceitos como o Domain-Driven Design (DDD), que o Martin Fowler explica tão bem, mostram que o software deve refletir o negócio. É um tema que considero fundamental e que já explorei aqui no blog há algum tempo. Se a gente deixa a IA ditar o código, corremos o risco de criar soluções genéricas que não atendem às necessidades específicas da empresa.

Um desenvolvedor que entende o negócio sabe quando uma exceção é importante ou quando uma regra precisa ser flexível. A IA não tem esse contexto. Ela olha pra padrões estatísticos, não pra estratégia do seu produto. Depender demais dela é abrir mão do que torna o software um diferencial competitivo real.

A verdadeira engenharia de software não é sobre digitar rápido, mas sobre tomar decisões inteligentes que evitem problemas lá na frente. Se o time de tecnologia vira apenas um "aprovador de sugestões da IA", a empresa perde a capacidade de inovar de verdade e de criar soluções que sejam sólidas e fáceis de evoluir.

A IA como aliada, não como substituta do pensamento

Não quero parecer um ludista aqui. Não estou dizendo que a gente deva ignorar a tecnologia ou voltar pra idade da pedra. A IA é uma ferramenta que tem seu potencial e pode ajudar pontualmente, sugerir caminhos ou automatizar aquelas tarefas que são realmente chatas e repetitivas.

O segredo do ponto de vista individual, como quase tudo na vida, está em como a gente usa. A IA deve ser como um parceiro de trabalho que te dá dicas, não como alguém que faz a lição de casa por você. O desenvolvedor precisa continuar sendo o dono das decisões, entendendo cada linha de código que entra no projeto.

Mas, do ponto de vista empresarial, a conversa é ainda mais séria. A verdadeira vantagem competitiva de uma empresa não é a quantidade de linhas de código que ela gera por hora, mas a resiliência do seu sistema e o domínio que o seu time tem sobre o próprio produto. Se a liderança incentiva apenas a métrica da velocidade cega, ela está essencialmente terceirizando a inteligência do negócio para um algoritmo opaco.

Para os profissionais e líderes do futuro, o desafio é manter esse equilíbrio. Precisamos aproveitar o benefício de desenvolvimento assistido por IA, mas sem abrir mão da profundidade técnica e do entendimento real. Se a gente sacrificar o aprendizado pela pressa, o boleto vai chegar — e geralmente ele vem em forma de sistemas instáveis e profissionais despreparados. O segredo é manter a curiosidade e nunca parar de querer saber como as coisas funcionam de verdade.