O Problema de Identidade: Por Que Desenvolvedores Resistem à IA e o Que Isso Realmente Significa

Em fevereiro de 2026, Dave Gauer publicou um ensaio que articulou algo que milhares de desenvolvedores estavam sentindo mas não conseguiam nomear. O título era direto: “A Programmer’s Loss of Identity.” A tese, mais direta ainda: a onda de IA não ameaça o emprego dos programadores — ameaça quem eles acreditam ser.

Gauer aplica a teoria de identidade social de Samuel Bagg para argumentar que “programador” nunca foi apenas uma descrição de função. Era uma identidade construída em torno de maestria — design de linguagens, sistemas de tipos, abstração elegante, a diferença entre código que funciona e código que é bom. A IA redefiniu o jogo. O que conta agora é volume de output, não qualidade do ofício.

A observação de Gauer é qualitativa e pessoal. Ele mistura três fenômenos distintos — ética corporativa, capacidade de ferramentas e cultura comunitária — num único ensaio. Não é pesquisa. Mas quando você cruza com os dados disponíveis, o padrão que ele descreve aparece com clareza.

O Que os Dados Mostram

O Stack Overflow Survey de 2025, com 49 mil desenvolvedores, capturou uma mudança de sentimento que nenhuma pesquisa anterior havia registrado. 84% dos desenvolvedores usam ferramentas de IA no trabalho. Mas apenas 29% confiam na precisão do output — uma queda de 40% em relação a pesquisas anteriores. 66% citam o problema do “quase certo”: código que parece funcional mas carrega erros sutis. O sentimento positivo sobre IA caiu de mais de 70% para 60%.

Releia esses números. A adoção subiu. A confiança caiu. Ao mesmo tempo.

Isso não é o perfil de uma tecnologia que falhou. É o perfil de uma tecnologia que funciona o suficiente para ser obrigatória mas não o suficiente para ser confiável. E quando você força profissionais a usar uma ferramenta em que não confiam, o resultado não é resistência racional. É crise de identidade.

O estudo METR de 2025 — um ensaio clínico randomizado, não uma pesquisa de opinião — encontrou que desenvolvedores experientes ficaram 19% mais lentos com ferramentas de IA, apesar de acreditarem que estavam aproximadamente 20% mais rápidos. O viés de percepção é revelador: a ferramenta cria a sensação de produtividade sem a substância.

E há um dado de Stanford que contextualiza a pressão: o emprego de desenvolvedores juniores (22-25 anos) caiu aproximadamente 20% desde 2022. A porta de entrada está encolhendo. Quando desenvolvedores seniores olham para esse cenário, não veem progresso — veem a erosão do caminho que eles próprios percorreram.

”Heirloom Programmer” — Um Nome Para o Que Já Existia

Gauer cunha o termo “heirloom programmer” para descrever desenvolvedores que valorizam o ofício de programar em si — não como meio para um fim, mas como disciplina intelectual. Design de linguagens, elegância algorítmica, a satisfação de um sistema de tipos bem construído.

O termo é útil porque dá nome a algo que a indústria trata como anacronismo. Mas a realidade é mais complexa do que um rótulo sugere.

A cultura do ofício em programação sempre foi fragmentada. Não existe “uma” comunidade de artesãos de código. Existem subculturas — a turma de Haskell, os entusiastas de Rust, os puristas de Unix, os defensores de Lisp. O que essas subculturas compartilham não é uma linguagem ou paradigma. É uma epistemologia: a crença de que qualidade técnica é um valor em si e que maestria importa independente de produtividade.

Quando a narrativa dominante muda de “escreva código bom” para “gere output rápido”, essa epistemologia fica sem chão. Não porque o ofício morreu — a comunidade migrou para espaços menores e mais intencionais. Mas porque o enquadramento institucional mudou. E é o enquadramento institucional que define promoções, contratações e o que aparece na descrição de vagas.

72% dos desenvolvedores na pesquisa do Stack Overflow 2025 disseram que “vibe coding” — o ato de gerar código via IA sem compreender plenamente o que foi gerado — não faz parte do trabalho profissional. Isso não é opinião marginal. É supermaioria.

A Diferença Categórica Que Ninguém Quer Discutir

Há um argumento técnico no ensaio de Gauer que merece atenção separada.

Abstrações tradicionais em software — compiladores, sistemas de tipos, verificação formal — são determinísticas. Você consegue auditar o que fazem. Consegue provar propriedades sobre seu comportamento. Quando um compilador transforma código, a transformação é governável: previsível, reprodutível, auditável.

Output de LLM não é nada disso. É estocástico. A mesma entrada pode gerar saídas diferentes. As propriedades do output não derivam das propriedades da entrada de forma previsível. Você não consegue provar que o código gerado faz o que deveria sem inspecioná-lo — e a inspeção exige exatamente a expertise que o discurso “a IA faz isso por você” promete eliminar.

92% dos líderes de engenharia dizem que IA aumenta o raio de explosão de código ruim. Não é uma opinião conservadora. É reconhecimento de que quando você multiplica a velocidade de geração de código sem multiplicar proporcionalmente a capacidade de verificação, o resultado líquido é mais risco, não menos.

Essa não é uma diferença estética entre quem prefere código “artesanal” e quem aceita código “industrial”. É uma diferença categórica de governabilidade. Um compilador é governável por design. Um LLM é governável apenas por processo — e o processo depende de pessoas que entendem o que estão revisando.

A Economia do Luto

Kent Beck — talvez o desenvolvedor mais respeitado em exercício — argumenta que IA muda a economia da programação preservando o ofício. Em “Programming Deflation”, ele aplica o Paradoxo de Jevons: quando programar fica mais barato, a demanda por software cresce desproporcionalmente. O ofício não morre. Muda de forma.

Concordo com Beck, mas com uma ressalva importante: a transição não é automática nem indolor.

O que Gauer descreve não é resistência à mudança. É luto. E o luto tem uma lógica própria que organizações ignoram por sua conta e risco.

Quando desenvolvedores orientados ao ofício ficam quietos em reuniões sobre adoção de IA, não é porque aceitaram. É porque se desconectaram. A diferença é crucial. Aceitação gera comprometimento. Desconexão gera saída silenciosa — física ou intelectual.

O relatório Deloitte Tech Trends 2026 captura a assimetria que alimenta esse luto: 93% do investimento em IA vai para tecnologia. 7% vai para pessoas. Noventa e três contra sete. Quando uma organização investe treze vezes mais na ferramenta do que nas pessoas que usam a ferramenta, a mensagem é clara — mesmo que ninguém a articule.

O luto dos desenvolvedores não é pela tecnologia. É pela cultura. Pela ideia de que expertise e cuidado técnico eram valorizados. Pela expectativa de que saber fazer algo bem importava tanto quanto fazer rápido.

A Armadilha do Medo

A adoção de IA na maioria das organizações segue uma narrativa implícita: “Aprenda IA ou fique obsoleto.” É um argumento de medo. E argumentos de medo produzem conformidade, não comprometimento.

Conformidade significa que desenvolvedores usam as ferramentas nos reports e nas demos. Comprometimento significa que integram as ferramentas no fluxo de trabalho real, adaptam processos, identificam onde a ferramenta agrega e onde atrapalha.

A diferença entre conformidade e comprometimento é a diferença entre 84% de adoção e 29% de confiança. As pessoas usam. Não confiam. E quando não confiam, não investem o esforço cognitivo necessário para usar bem.

Pior: a narrativa de medo acelera a saída dos profissionais mais experientes. São justamente os desenvolvedores com mais opções no mercado — os que possuem a expertise para governar código gerado por IA — que saem primeiro quando o ambiente profissional desvaloriza o que sabem fazer.

O Que Isso Significa Para Quem Decide

Se você lidera uma equipe de engenharia ou uma organização que depende de software, há três implicações diretas.

Primeira: resistência não é problema de treinamento. A maioria das organizações enquadra resistência à IA como gap de habilidade. Oferece cursos, workshops, programas de certificação. Nada disso endereça o problema real, que é identitário. Desenvolvedores orientados ao ofício não precisam aprender a usar Copilot. Precisam de um enquadramento institucional que reconheça que verificação é trabalho — e trabalho valioso.

Segunda: governança é infraestrutura de identidade. Quando uma organização implementa processos sérios de revisão de código gerado por IA — com critérios explícitos, métricas de qualidade, e reconhecimento formal da expertise necessária para revisão — está fazendo duas coisas simultaneamente. Está gerenciando risco técnico. E está dizendo aos desenvolvedores seniores: “Sua expertise é o que torna essa tecnologia segura, não o que essa tecnologia substitui.”

Terceira: o silêncio é mais caro que a resistência. Resistência vocal é informação. Um desenvolvedor que questiona a confiabilidade de código gerado por IA está dizendo algo útil. O perigo real é quando a resistência vira silêncio — quando os profissionais mais experientes param de questionar e começam a planejar a saída.

A Governança Como Ponte

A tese de Gauer é que a identidade de “programador” fraturou. Discordo parcialmente. A identidade não fraturou — está em transição. E transições de identidade profissional dependem de infraestrutura institucional.

Historicamente, outras profissões passaram por transições similares. Contadores sobreviveram à planilha eletrônica porque a profissão construiu frameworks de governança — auditorias, certificações, padrões — que definiram o papel humano como complementar à ferramenta, não substituível por ela. Radiologistas não foram eliminados pela leitura automatizada de imagens porque a profissão redefiniu o papel como interpretação e decisão clínica, não como detecção de padrões.

A engenharia de software não construiu essa ponte ainda. Governança de código gerado por IA — quem revisa, com que critérios, com que consequências — é a ponte entre a identidade de ofício que desenvolvedores construíram e a realidade de que IA é permanente.

Sem essa ponte, a transição produz exatamente o que os dados mostram: adoção alta, confiança baixa, e os profissionais mais capazes se desconectando em silêncio.

O Que Não Estou Dizendo

Não estou dizendo que toda resistência à IA é legítima. Existe resistência baseada em desinformação, em medo irracional, em recusa de aprender. Também existe resistência instrumental — desenvolvedores que usam o discurso anti-IA para proteger posições de conforto.

Também não estou dizendo que Gauer tem razão em tudo. Ele trata a identidade de programador como se fosse monolítica, quando sempre foi fragmentada. E subestima a capacidade de adaptação das comunidades técnicas — muitos desenvolvedores usam IA intensamente e continuam valorizando o ofício. Beck é o exemplo mais visível, mas está longe de ser o único.

O que estou dizendo é mais específico: quando uma organização trata a resistência de desenvolvedores à IA exclusivamente como problema de treinamento ou atitude, está ignorando um fenômeno de identidade que tem consequências operacionais reais. Perda de profissionais seniores. Adoção superficial sem comprometimento. Acumulação de dívida técnica por código gerado sem revisão adequada.

Governança não é só controles técnicos. É a infraestrutura que permite a transição de identidade sem destruir o que fazia esses profissionais valiosos em primeiro lugar.

A Victorino Group ajuda organizações a implementar governança de IA que funciona — incluindo os aspectos humanos que a maioria dos frameworks ignora. Se o cenário descrito aqui se parece com o que você observa na sua equipe, fale conosco: contato@victorino.com.br