Dunning-Kruger com Claude Code: 4 mecanismos que aprofundam o vale (e não amenizam)

A narrativa dominante sobre IA na programação diz mais ou menos isto: “com Claude Code, curva de aprendizado achata, iniciante vira intermediário em semanas, o vale do Dunning-Kruger some”. Soa bem em thread do LinkedIn. Não é o que acontece com a maioria das pessoas que abre o editor toda manhã com um agente do lado.

O efeito Dunning-Kruger não some com IA. Muda de forma. O pico do iniciante fica mais alto, porque o agente entrega código que compila e passa em teste antes da pessoa entender o que foi escrito. E o vale do intermediário fica mais fundo, porque o dia em que a produção quebra chega com um contexto que o dono do commit nem tem na cabeça.

Este texto é uma leitura do capítulo 7 do livro Manual completo dos truques psicológicos para engenheiros, aplicada ao dia a dia com Claude Code. Quatro mecanismos concretos, o que a pesquisa recente diz de fato (e o que não diz), e as duas contramedidas que sobrevivem quando o entusiasmo passa.

O efeito Dunning-Kruger em uma frase

Dunning e Kruger publicaram o estudo original em 1999, na Universidade Cornell. A ideia central: quem tem capacidade baixa em uma área tende a superestimar a própria capacidade; quem tem capacidade alta tende a subestimar a própria capacidade. A explicação psicológica proposta é a mesma para os dois lados — a pessoa não consegue avaliar bem porque falta o próprio critério de avaliação.

Na engenharia, o padrão aparece em três estágios que qualquer sênior reconhece de longe:

Excesso de confiança do iniciante. Termina o tutorial de Python e sente que “manja de Python”. Não sabe o que é GIL, nunca precisou desenhar um retry idempotente, nunca fez rollback de migration em produção às 22h. Como não viu o mapa inteiro do que não sabe, superestima o que sabe.
Vale do intermediário. À medida que aprende, a fronteira do próprio conhecimento aparece. Quanto mais estuda, mais cresce a sensação de “quanta coisa eu não sei”. A confiança cai. Muita gente troca de área nesse ponto, achando que “não serve para isso”.
Subestimação do experiente. Depois de anos, o que era difícil vira automático. O sênior pensa “isso qualquer um faz” — e não percebe que “qualquer um” ali significa “qualquer um com 8 anos de repetição consciente”.

Este é o mapa clássico. Agora vamos ao que o Claude Code faz com ele.

Mecanismo 1: o pico do iniciante fica mais alto

O tutorial de Python leva umas 20 horas. Depois disso, o iniciante sente que “sabe Python”. Já era exagero antes; virou paródia agora.

Com um agente no editor, a mesma pessoa em 20 minutos escreve um servidor Flask, adiciona autenticação com JWT, coloca um Dockerfile, sobe no Cloud Run. Tudo funciona. O aluno olha para o próprio setup e conclui algo que do ponto de vista do resultado é verdade: ela consegue entregar um sistema que a semana passada ainda estava fora do alcance.

O que não mudou é o mapa do que ela não sabe. PyJWT tem uma pegadinha conhecida com algorithm=None que passou anos aparecendo em CVE. O Dockerfile do agente muitas vezes sobe em root e ignora a camada de cache do pip. O deploy no Cloud Run funciona enquanto a resposta média cabe em 512 MB, mas o percentil 99 não cabe. Nenhuma dessas coisas encosta no dia 1. Encosta no dia 60, quando a base tem 300 usuários e a primeira reclamação chega.

O que mudou: o pico do iniciante ficou mais alto porque o output subiu antes do repertório subir. Antes, o iniciante tinha 20 horas de tutorial e um projetinho toy. Hoje, o iniciante tem 20 horas de tutorial e um sistema em produção. A distância entre “o que a pessoa entrega” e “o que a pessoa entende” cresceu muito. E entender é a régua que o Dunning-Kruger mede.

Mecanismo 2: o feedback que corrigia o pico fica mais tarde

O mecanismo que tira o iniciante do pico é o feedback duro do código quebrando. Você achou que sabia; o servidor caiu; você entendeu que não sabia. O ciclo é curto: código, quebra, aprendizado.

Com um agente, o ciclo entre “escrever” e “quebrar” fica mais longo. Não porque o código quebre menos — os relatórios do GitHub Copilot Metrics e as análises da METR em 2025 mostram que a taxa de bug por PR não caiu significativamente para dev experiente. Fica mais longo porque o dev não lê a saída na mesma profundidade. Você aprova um bloco que o agente escreveu em 10 segundos, o CI passa, o PR merga. Semanas depois, no dia em que um usuário de outra timezone dispara uma edge case, o bug aparece — e o autor do PR já esqueceu o contexto.

Escrevi sobre isso em Confiei que a IA me deixava mais rápido — os dados dizem que fiquei mais lento. O RCT da METR mostrou que devs experientes em código familiar ficaram 19% mais lentos com ferramentas de IA, e — o dado que dói mais — mesmo depois de terminar o experimento, os participantes ainda acreditavam ter ficado 20% mais rápidos. A percepção não colou na realidade nem depois de vivê-la.

Para o iniciante, o efeito é ainda mais forte, mas ao contrário: como ele não tem repertório para desconfiar, o dia em que o vale chega vem sob a forma de um incidente sério, não de um pytest vermelho. Aprendi o meu por conta em as três horas em que o contexto apodreceu com Claude Code e depois em postmortem de agente 24 horas — a hora em que o feedback chega tende a coincidir com a hora em que o custo já é alto.

Mecanismo 3: a autoridade textual mascara o “eu não sei”

Um sênior humano, quando fica em dúvida sobre um trecho, diz “estou em dúvida”. A frase carrega o próprio grau de confiança. O leitor cala e pergunta.

Um LLM não faz isso por padrão. Ele produz texto formatado, com aparência de convicção, com comentário // concurrent-safe sobre um trecho que decididamente não é concurrent-safe. Não é maldade. É que o modelo foi treinado para gerar texto que passa em plausibilidade, e “estou em dúvida” é um output menos plausível do que uma frase declarativa.

O viés de autoridade explica por que essa saída convence. Milgram mostrou nos anos 60 que aceitamos afirmações sem cheque se elas vierem em tom autoritativo. A pesquisa da Georgetown CSET (2024) sobre desenvolvedores usando IA mostra o mesmo fenômeno em código: a taxa de aceitação sem verificação sobe com a pressão de tempo, justamente quando a verificação mais importa.

O que isso faz com a curva de Dunning-Kruger é específico: o iniciante recebe avaliação enviesada positivamente do próprio código. O agente diz “seu código está correto”. Não está. Mas na cabeça do iniciante, o feedback do agente vira parte da avaliação do próprio nível. É como colocar um espelho torto no vestiário. A pessoa acha que emagreceu. O peso não mudou.

Mecanismo 4: a síndrome do impostor fica exposta na outra direção

O primeiro mecanismo empurra o iniciante mais para cima do pico. Os três primeiros somados fazem outra coisa com o experiente: aprofundam a síndrome do impostor.

A síndrome do impostor é o estado psicológico em que, mesmo entregando resultados objetivos, a pessoa sente “o sucesso foi sorte, não habilidade” e “uma hora vão descobrir”. O termo foi cunhado por Clance e Imes em 1978 no contexto clínico. Em engenharia de software, o único estudo recente com amostra grande é o arXiv:2312.03966 (Guenes et al., 2023), que aplicou um instrumento validado a 624 engenheiros de software em 26 países. Os achados centrais são estes, verbatim:

52,7% dos engenheiros de software relatam sentimentos de impostor de frequentes a intensos
Mulheres 60,6% vs. homens 48,8%
Asiáticos 67,9%, negros 65,1%, brancos 50,0%
Menor prevalência entre casados com filhos
Efeito negativo estatisticamente significativo em todas as construções do framework SPACE de produtividade percebida

O que o estudo NÃO diz. Não afirma que “a velocidade das mudanças tecnológicas alimenta o fenômeno”. Essa é uma leitura comum que aparece em posts sobre o tema, mas o paper não mede essa relação — o dado é prevalência e diferenças demográficas, não causa tecnológica. Vale a distinção porque uma coisa é interpretação (razoável, mas hipótese), outra coisa é achado (o que o instrumento mediu).

Com Claude Code, o experiente entra num loop novo: entrega mais, com menor sensação de mérito. Um sênior que resolveu um bug complicado em uma hora, com metade da hora sendo o agente escrevendo os primeiros drafts, guarda para si a sensação de que “não foi eu, foi ele”. Escrevi sobre uma amostra dessa dinâmica em pushback do Google (21% mais em code review) e o reflexo no meu sub-agente solo — o crédito emocional pela solução some quando o próprio agente redigiu o texto que convenceu.

O mecanismo é o mesmo do pico invertido: a avaliação da própria capacidade perde ancoragem. Antes, você calibrava por tempo de resolução, número de linhas escritas, complexidade do commit. Com o agente entre você e o código, o número de linhas você não escreveu, o tempo caiu, a complexidade ficou opaca. Sobra a sensação. E a sensação é enviesada para “não fui eu”.

O que a crítica do Nuhfer nos obriga a moderar

Aqui é onde vale parar antes de virar mais um post que trata Dunning-Kruger como lei da natureza. A pesquisa metodológica dos últimos dez anos foi implacável com o efeito original.

Edward Nuhfer e colegas argumentaram entre 2016 e 2017 que o gráfico icônico do Dunning-Kruger é um artefato estatístico — uma autocorrelação. A crítica técnica é a seguinte: se você correlaciona duas variáveis, elas precisam ser medidas de forma independente. No gráfico original, a nota do teste entra nos dois eixos, o que gera a curva mesmo em dados aleatórios. Nuhfer demonstrou isso gerando datasets sintéticos sem nenhum efeito Dunning-Kruger embutido — e o gráfico canônico apareceu igual. Gignac e Zajenkowski (2020) fizeram uma crítica próxima com metodologia bayesiana.

Dunning respondeu, e há filósofos como Amy Seymour argumentando que as críticas foram superestimadas. A discussão acadêmica continua aberta.

O que a crítica nos obriga a fazer: parar de usar “Dunning-Kruger” como se fosse uma lei observada com precisão. Continua sendo uma heurística útil para lembrar que sabemos menos do que sentimos e sabemos mais do que sentimos, dependendo do estágio. Mas o número exato da curva, o tamanho da diferença entre iniciante e experiente, tudo isso tem incerteza metodológica. Use como espelho aproximado. Não como régua de precisão.

E, do outro lado, o estudo do Guenes et al. sobre impostor tem 624 respostas e um instrumento validado. É um dado sólido de prevalência, não uma inferência sobre a causa tecnológica.

As duas contramedidas que sobrevivem

O capítulo 7 do livro sugere duas contramedidas para o par Dunning-Kruger + impostor. As duas continuam funcionando na era Claude Code, com pequenos ajustes. Nenhuma delas envolve virar cético amargo.

Mapa de skills que separa “sei” de “vi o Claude fazer”

A contramedida original para Dunning-Kruger é o mapa de skills: você lista as áreas do seu domínio técnico e classifica cada uma em cinco níveis — “não sei”, “sei o nome”, “já usei”, “consigo explicar”, “consigo ensinar”. As duas primeiras posições existem porque saber que uma coisa existe já reduz o efeito. Você não superestima o que sabe que não sabe.

Na era do agente, adiciono uma sexta classificação: “vi o Claude fazer”. Essa categoria contém a maior parte do meu setup atual de projetos que rodam bem — configuração de Cloudflare Workers, alguns patterns de retry em cliente HTTP, um punhado de queries Cypher no Neo4j, integrações de deploy que uso mas não escreveria do zero se o agente sumisse amanhã. Reconhecer “vi o Claude fazer” separa “produção que funciona” de “capacidade minha instalada”. As duas coisas são valiosas, mas uma delas some no dia em que o agente decidir bugar naquele campo específico.

Registro semanal de entregas focado no que eu decidi

A contramedida para síndrome do impostor é o registro de entregas. Uma vez por semana, você anota o que fez e concluiu. Não é a auto-avaliação do RH — é um registro só seu. Ler três meses depois costuma trazer a percepção “fiz mais do que sentia”.

Ajuste para a era do agente: em cada entrada, marque especificamente o que você decidiu, não o que o agente executou. “Decidi mudar a arquitetura de fila para stream porque o padrão de acesso mudou” é uma linha sua. “Escrevi o refactor” é uma linha do Claude. Separar os dois dá dois efeitos: (1) você mede a própria contribuição real, e (2) você percebe onde depende demais do agente para decisão — que é o oposto de onde ele deveria depender de você.

O que se tira daqui

O efeito Dunning-Kruger é um espelho útil e impreciso. A era do Claude Code inclina o espelho para os dois lados: sobe o pico do iniciante porque o output engana o repertório, e cava o vale do experiente porque o crédito emocional pela solução vai parar num agente.

As duas contramedidas do capítulo 7 continuam sendo o que sobra depois que o entusiasmo passa: mapa que separa “sei” de “vi o Claude fazer”, e registro que separa “eu decidi” de “ele executou”. Nenhuma delas é ferramenta. As duas são hábitos. É por isso que sobrevivem quando o modelo troca de versão de novo semana que vem.

E se você quer aprofundar os outros três vieses que decidem carreira — status quo, sobrevivente, e o próprio Dunning-Kruger em situação de decisão de virada (IC → EM, freelancer, mudança de stack) — o capítulo 7 do Manual completo dos truques psicológicos para engenheiros tem esses quatro vieses com contramedidas concretas.

Referências

Guenes, P.; Tomaz, R.; Kalinowski, M.; Baldassarre, M. T.; Storey, M.-A. (2023). Impostor Phenomenon in Software Engineers. arXiv:2312.03966. Link
Nuhfer, E. et al. (2016–2017). Random Number Simulations Reveal How Random Noise Affects the Measurements and Graphical Portrayals of Self-Assessed Competency. Numeracy Journal.
Gignac, G. E.; Zajenkowski, M. (2020). The Dunning-Kruger effect is (mostly) a statistical artefact. Intelligence, 80.
Kruger, J.; Dunning, D. (1999). Unskilled and Unaware of It. Journal of Personality and Social Psychology, 77(6).
METR (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity.
Center for Security and Emerging Technology / Georgetown (2024). Cybersecurity Risks of AI-Generated Code.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews