No início de 2026, pesquisadores que tentavam medir o efeito da IA sobre a produtividade de desenvolvedores encontraram um problema profundamente humano: alguns profissionais já não queriam aceitar tarefas que talvez precisassem executar sem IA.
Os pesquisadores chamaram isso de efeito de seleção. Eu continuo pensando nisso como uma pequena confissão.
Não faz tanto tempo, a IA era um experimento escondido em um painel lateral. Nós a abríamos quando o autocomplete falhava ou quando uma expressão regular começava a ficar constrangedora. Hoje, para muita gente, ela simplesmente faz parte da sala. Está ali quando abrimos o editor de manhã, quando herdamos um repositório em que ninguém mexe há anos e quando um teste fica vermelho tarde da noite.
Podemos fechar o painel. Podemos desligar o agente. Ainda sabemos programar.
Então por que trabalhar sem IA já parece trabalhar com uma mão a menos?
A IA ocupou as pausas
A IA não entrou no desenvolvimento de software anunciando que iria nos substituir. Ela chegou trazendo um pequeno alívio de cada vez.
Primeiro completou a linha que já estávamos prestes a escrever. Depois criou o teste que vínhamos adiando. Explicou uma função desconhecida, traduziu um stack trace para uma linguagem compreensível e encontrou uma configuração escondida numa documentação que não queríamos ler de novo.
Nada disso parecia dependência. Parecia embalo.
Pense na última vez em que seu assistente ficou indisponível. O incômodo provavelmente não foi ter esquecido a linguagem. Foi o silêncio antes do primeiro movimento. Era preciso decidir sozinho onde procurar. Sustentar a incerteza sem companhia. Encarar o erro por tempo suficiente para que uma hipótese começasse a surgir.
Essas pausas já foram normais. Agora parecem atrito.
Talvez essa seja a mudança mais profunda causada pela IA. Ela não mudou apenas a forma como produzimos respostas. Mudou também quanto tempo estamos dispostos a ficar a sós com uma pergunta.
O alívio é real
É fácil falar de dependência de IA como se desenvolvedores estivessem trocando disciplina por preguiça. Essa leitura ignora o que a ferramenta representa por dentro do trabalho.
O desenvolvimento de software contém uma quantidade surpreendente de vergonha silenciosa. Há o engenheiro sênior que esqueceu a sintaxe de um comando básico. A pessoa recém-contratada que teme que mais uma pergunta confirme todas as dúvidas dos outros. O desenvolvedor que trabalha em outro idioma, entende exatamente o problema, mas não consegue formular a explicação rápido o bastante. Quem entra numa base de código de dez anos em que cada decisão importante só existe na memória de outra pessoa.
A IA tem paciência com todos eles.
Ela não suspira quando repetimos a pergunta. Não diz: “Você já deveria saber isso.” Está disponível às duas da manhã e consegue transformar uma tela vazia em algo com que podemos discutir. Mesmo imperfeita, uma resposta muda o peso emocional de começar.
Isso importa. Às vezes, o que parece produtividade é, antes de tudo, alívio: menos medo de ficar travado, menos constrangimento, menos solidão diante de uma máquina que se recusa a se explicar.
Para muitos desenvolvedores, a IA também devolveu energia às partes do trabalho que realmente importam. Ela pode carregar o código repetitivo, os testes de rotina, a estrutura de uma migração e a centésima variação de um cliente de API. A mente chega menos cansada ao problema interessante.
Não deveríamos tratar isso apenas como atalho. Uma ferramenta que dá às pessoas mais coragem para explorar está oferecendo algo genuinamente valioso.
A dificuldade é que conforto e dependência crescem da mesma raiz.
Usamos aquilo em que não confiamos por completo
As pesquisas com desenvolvedores continuam mostrando a mesma relação estranha: usamos IA o tempo todo e, ao mesmo tempo, desconfiamos do que ela entrega.
Quem já viu uma resposta cheia de confiança desmoronar diante de um único caso extremo conhece essa tensão. O código parece certo. Os nomes são bons. A explicação é tranquila. Só depois do terceiro teste quebrado percebemos que o modelo inventou um método, entendeu mal uma regra de negócio ou resolveu um problema mais simples que o nosso.
E, mesmo assim, na próxima vez que travamos, perguntamos de novo.
Isso não é hipocrisia. Confiança não é uma coisa só.
Talvez não confiemos à IA a decisão final, mas confiamos nela para apontar uma primeira direção. Talvez não confiemos no patch, mas confiamos na conversa que desfaz um nó no pensamento. Podemos duvidar da resposta e ainda acreditar que haverá alguma coisa na tela, em vez de nada.
A IA se tornou aquele colega a quem jamais daríamos permissão para fazer merge direto na main, mas cuja ausência sentimos assim que ele sai da sala.
Avançamos mais rápido porque o próximo passo aparece depressa. Continua sendo nossa responsabilidade conferir se ele aguenta nosso peso.
O que desaparece quando a dificuldade desaparece
Existe um tipo de conhecimento que só nasce quando ficamos travados.
Antes da IA, um erro desconhecido podia nos levar do stack trace ao ponto de chamada, dali para a documentação e, por fim, até uma suposição que nem sabíamos ter feito. O caminho era ineficiente. Também era assim que uma base de código se transformava em um lugar, e não apenas numa coleção de arquivos.
Nós nos lembramos dos sistemas que um dia resistiram a nós.
O bug que tomou uma tarde ensina onde o estado realmente vive. O incidente em produção explica por que existe uma proteção aparentemente entediante. A biblioteca que entendemos errado três vezes se torna aquela que um dia saberemos explicar a outra pessoa.
Quando a IA remove a resistência, ela pode levar junto a história que faz a lição permanecer.
Um estudo inicial com desenvolvedores aprendendo uma biblioteca desconhecida encontrou algo intuitivo: quem delegou a tarefa inteira aprendeu menos do que quem usou a IA para fazer perguntas conceituais e testar o próprio entendimento. A diferença importante não era “IA ou sem IA”, e sim se a ferramenta substituía o pensamento ou participava dele.
Isso é especialmente delicado para quem está começando. Engenheiros experientes reconhecem uma abstração suspeita porque já construíram a abstração errada. Percebem que um patch bem organizado não pertence ao sistema porque conhecem as cicatrizes dele. Mas onde a próxima geração vai desenvolver esse instinto se toda aresta for suavizada antes que ela possa tocá-la?
Mentoria nunca foi apenas transferir respostas. Era transmitir critério aos poucos: com o que se preocupar, quando parar, qual concessão ficará cara depois e por que uma solução que funciona ainda não está pronta.
A IA consegue explicar todas essas ideias. Ainda não consegue reproduzir a sensação de outra pessoa escolher permanecer ao nosso lado enquanto aprendemos.
O atalho pode ser real. O entendimento ainda precisa atravessar a distância.
O código costumava carregar impressões digitais
Há outra mudança mais difícil de medir porque ela acontece entre pessoas.
O código escrito por alguém costuma guardar traços de quem o criou. Uma função auxiliar estranha pode carregar a lembrança do incidente que a tornou necessária. Um comentário desajeitado pode mostrar onde houve dúvida. Durante uma revisão, não examinamos apenas a mudança: reconstruímos o pensamento por trás dela. Fazemos perguntas, e outra pessoa responde a partir do caminho que percorreu.
O código gerado por IA pode chegar sem esse caminho.
Ele pode ser polido e tecnicamente plausível, mas ainda parecer estranhamente sem dono. O autor consegue explicar o que pediu, mas nem sempre por que o resultado tomou aquela forma. Então, quem revisa assume parte do trabalho que antes também cabia a quem escreveu: reconstruir a intenção, verificar premissas e descobrir as bordas ocultas de uma decisão que ninguém se lembra de ter tomado.
Esse é o desconforto por trás de muitas conversas da comunidade sobre pull requests geradas por IA. A reclamação não é simplesmente que o código pode ser ruim. Código ruim sempre existiu. A inquietação mais profunda vem da mudança no contrato social.
Uma pessoa consegue produzir uma grande alteração em minutos. Outra ainda precisa gastar atenção humana para compreendê-la. O tempo economizado no teclado reaparece silenciosamente na revisão, na manutenção, na segurança ou na noite em que o sistema falha e alguém precisa explicar o que aquele patch gerado pretendia fazer.
Código sempre foi comunicação. Quando gerar se torna quase gratuito, atenção vira o recurso escasso. E atenção pertence às pessoas.
Talvez o ofício esteja mudando de lugar
Para alguns desenvolvedores, nada disso parece perda. Parece finalmente poder trabalhar no nível em que sempre quiseram.
Eles escrevem menos linhas e passam mais tempo dando forma ao problema. Comparam vários projetos antes de escolher um. Pensam no usuário, na arquitetura, nas formas de falha e nos limites que um agente não pode atravessar. O ofício se desloca de produzir cada peça para dirigir o conjunto.
Isso pode ser uma evolução real. Não deixamos de ser desenvolvedores quando assembly substituiu código de máquina ou quando frameworks substituíram infraestrutura feita à mão. O software sempre subiu novas camadas de abstração.
Mas toda abstração depende de alguém que entenda o que existe por baixo.
Um desenvolvedor que dirige a IA ainda precisa de bom gosto técnico. Quem revisa ainda precisa de um modelo mental. Um arquiteto ainda precisa saber o que acontece quando o diagrama limpo encontra uma rede lenta, uma mensagem corrompida, uma equipe exausta ou um usuário assustado.
Se a IA escreve uma parte maior da implementação, o julgamento humano não fica menos importante. Fica mais fácil de ignorar e mais difícil de cultivar.
A versão esperançosa desse futuro não é aquela em que desenvolvedores importam menos. É aquela em que nos tornamos mais conscientes do que só pessoas conseguem carregar: contexto, cuidado, dúvida, responsabilidade e a capacidade de reconhecer quando uma resposta tecnicamente correta está errada para este sistema e para estas pessoas.
Permanecer sem desaparecer
Ainda conseguimos abrir mão da IA?
Como indivíduos, sim. Podemos fechar o painel amanhã. Como profissão, a resposta já é mais complexa. As expectativas estão mudando. As bases de código estão se enchendo de trabalho gerado. Novos desenvolvedores encontram a IA no começo da carreira, não no meio. Mesmo quem nunca usa um assistente terá cada vez mais código vindo de um para revisar e manter.
Não existe um caminho individual de volta para uma indústria de software anterior à IA.
Talvez, porém, ir embora seja a medida errada de liberdade. A pergunta mais importante é se conseguimos continuar presentes enquanto a ferramenta permanece.
Continuar presentes significa ler o patch mesmo quando todos os testes estão verdes. Perguntar por quê depois que a resposta funciona. Recusar o merge daquilo que não conseguimos explicar. Dar a profissionais juniores tempo para lutar sem chamar esse tempo de desperdício e reconhecer o trabalho invisível de quem protege o sistema contra erros convincentes durante a revisão.
Também significa preservar momentos em que nenhum assistente responde imediatamente. Não como ritual de pureza, mas como uma forma de voltar a ouvir o próprio pensamento.
A maioria de nós continuará usando IA. O alívio é real. As possibilidades são reais. Também são reais o desconforto, a dependência e o medo silencioso de que alguma coisa que amávamos no trabalho esteja escapando.
Não precisamos escolher entre negação e rendição.
O futuro do software não será decidido pela porcentagem de código escrita pela IA. Será decidido em momentos menores: se entendemos antes de aceitar, se ensinamos em vez de apenas encaminhar uma resposta, se protegemos a atenção de outra pessoa e se continuamos assumindo responsabilidade quando o código gerado chega ao mundo real.
A IA pode ficar.
Precisamos garantir que nós também fiquemos.
