Um ano atrás, a pergunta era se você ia usar IA para programar. Hoje a pergunta que importa é outra: em que parte do seu dia você está deixando ela decidir por você sem perceber? É aí que um dev sênior se diferencia de quem está começando: não em quanto código gera com o Copilot, mas em quando decide não usá-lo.
A conversa pública sobre IA no desenvolvimento ficou travada em dois lados: quem diz que ela substitui programadores e quem diz que é mágica que te deixa dez vezes mais produtivo. Nenhum dos dois descreve o que acontece no seu dia a dia real: a IA economiza seu tempo em coisas pontuais, te deixa mais lento em outras que você nem percebe, e em algumas mete erros que você vai pagar três sprints depois.
Onde a IA te faz ganhar tempo de verdade
Existem usos em que a economia é real e mensurável. Boilerplate, testes unitários sobre código que já existe, documentação de funções que não mudam com frequência, traduzir um erro críptico de um stack trace para algo compreensível, ou escrever a primeira versão de um script de migração que depois você vai revisar linha por linha. Em tudo isso, a IA faz em três minutos o que levaria vinte para você, e o risco de a resposta estar errada é baixo porque o contexto é limitado.
O padrão comum nesses casos é que o problema está bem definido e o custo de um erro é fácil de detectar. Se o teste que a IA gerou não compila, você vê na hora. Se a documentação saiu errada, um revisor percebe já na primeira olhada. O risco é pequeno porque tem uma rede de segurança por perto.
Onde está te custando mais do que você imagina
O problema aparece nas decisões de design: escolher entre duas formas de estruturar um serviço, decidir se um dado vai no Postgres ou no Redis, definir o contrato de uma API que três times diferentes vão consumir. Aí a IA vai te dar uma resposta com a mesma confiança de quando corrige um typo, mesmo sem fazer ideia do contexto real do seu sistema: quanto tráfego ele recebe, quais restrições seu cliente tem, qual dívida técnica já existe. A resposta soa sólida. O problema é que ela soa sólida mesmo quando está errada.
Um caso concreto: você pede para um assistente de IA sugerir como paginar um endpoint que retorna resultados de busca. Ele vai propor offset e limit, que é a resposta de manual. Mas se sua tabela tem milhões de linhas e usuários buscando em tempo real, essa paginação vai gerar queries cada vez mais lentas conforme o usuário avança de página, e só você sabe disso, porque conhece o volume real de dados e o padrão de uso. A IA não tem esse contexto a não ser que você dê a ela, e mesmo dando, nem sempre ela prioriza direito.
O custo que ninguém fatura: perder a fricção que te faz pensar
Tem uma parte mais difícil de medir do que o tempo economizado ou os bugs introduzidos: a fricção produtiva que você perde. Quando você escreve código na mão e trava, esse travamento é informação: te diz que o problema é mais complexo do que você pensava, ou que seu design tem uma suposição estranha. Quando a IA resolve o bloqueio antes de você terminar de sentir ele, você pula esse sinal. Com o tempo, isso vira menos intuição para perceber quando um problema tem cheiro de errado, porque você deixou de passar pelo momento desconfortável onde essa intuição se constrói.
Isso não é um argumento para parar de usar IA. É um argumento para ser deliberado sobre quando você deixa ela resolver algo por você e quando escolhe brigar com o problema mesmo tendo a solução a um prompt de distância. Um sênior que vale a pena contratar sabe distinguir esses dois momentos. Um que não sabe acaba dependendo da ferramenta para raciocinar sobre problemas que, dois anos atrás, resolvia sozinho.
Como eu estou usando, e por que isso importa mais do que qualquer relatório
Os relatórios do GitHub ou da JetBrains servem para ver a tendência geral, mas o seu caso é o único dado que realmente ajuda a decidir como trabalhar. Tente isto por duas semanas: anote, tarefa por tarefa, se você usou IA e quanto tempo levou para concluí-la comparado com a última vez que fez algo parecido sem ajuda. Não precisa de uma planilha elaborada, uma anotação rápida no seu task tracker já basta. Você vai encontrar padrões que nenhum relatório da indústria consegue te dar: talvez a IA economize meia hora no debugging, mas te trave quando você está fazendo design, ou o contrário.
O ponto real
A IA não te torna um developer melhor só por usá-la mais. Ela te torna melhor se você a usa com critério: sabendo em quais tarefas confiar a ela a primeira versão, em quais brigar de propósito com o problema você mesmo, e em quais simplesmente não vai usá-la porque o contexto que você precisa não cabe em um prompt. Essa distinção, e não a quantidade de linhas que você gera por dia, é o que um bom tech lead percebe quando revisa seu trabalho.
