Uso obrigatório de IA na programação pode comprometer qualidade e aprendizado

A obsessão atual por obrigar desenvolvedores a usar IA para escrever código me lembra um fenômeno antigo no meio acadêmico: medir pesquisadores pela quantidade de artigos publicados, e não pela qualidade do que produzem. O resultado foi inflação de Papers, mas não necessariamente de conhecimento relevante.

Quando universidades passaram a valorizar volume acima de profundidade, criaram incentivos previsíveis. Publicar virou meta em si mesmo. Fragmentaram-se ideias em múltiplos artigos menores, repetiram-se temas, multiplicaram-se textos que pouco acrescentavam. A métrica moldou o comportamento.

Algo semelhante começa a surgir em algumas empresas com a adoção compulsória de IA para codificação. O discurso é eficiência. A promessa é produtividade. Mas, quando o uso da ferramenta deixa de ser opcional e passa a ser indicador de desempenho, tipo “quantas sugestões aceitou?”, “quanto código foi gerado por IA?”, a métrica começa a dirigir o processo técnico.

E assim como medir programadores por linhas de código gerou excesso de código desnecessário, medir produtividade por “uso de IA” tende a gerar excesso de código gerado, nem sempre necessário, nem sempre plenamente compreendido.

Há um problema estrutural aqui. Código não é apenas entrega funcional. É compreensão, intenção arquitetural e clareza para manutenção futura. Quando o desenvolvedor terceiriza sistematicamente a geração para um modelo, sem internalizar as decisões, cria-se uma assimetria perigosa: os sistemas crescem mais rápido do que a capacidade humana de entendê-los.

No curto prazo, pode parecer ganho de velocidade. No médio prazo, o custo aparece na manutenção. Código gerado em excesso, com abstrações pouco refletidas ou padrões inconsistentes, aumenta a complexidade cognitiva. Refatorar se torna mais difícil. Debugar exige mais tempo. O time pode passar a depender da própria IA para interpretar o que foi produzido, criando uma dependência circular.

Há também implicações na formação de habilidades. Desenvolvedores aprendem escrevendo, errando, revisando, entendendo trade-offs. Se a prática deliberada é substituída por aceitação automática de sugestões, o aprendizado tende a se tornar mais superficial. Forma-se alguém capaz de operar a ferramenta, mas não necessariamente de projetar sistemas.

Nada disso significa rejeitar IA. Como toda ferramenta, ela pode ampliar produtividade quando usada com critério. O problema começa quando o uso vira obrigação e métrica de valor profissional.

Na engenharia de software, a métrica correta não é quantidade de código nem percentual gerado por modelo. É qualidade arquitetural, clareza, sustentabilidade do sistema e evolução de competências humanas. Ferramentas devem ampliar capacidade. Não substituir pensamento.