O Tutor de IA Melhorou a Sessão de Prática e Não Mudou Nada na Prova

Alunos que receberam um tutor GPT com guardrails tiveram desempenho 127% melhor nos exercícios de prática de matemática do que alunos sem nenhum modelo. Depois fizeram uma prova sem assistência, e o artigo relata o resultado em uma frase seca: “O desempenho dos alunos no braço GPT Tutor foi estatisticamente indistinguível do desempenho do braço de controle.”

Isso é um ensaio controlado randomizado, conduzido em colaboração com uma grande escola de ensino médio na Turquia durante o semestre de outono do ano letivo de 2023-2024, com cerca de 1.000 alunos. Bastani e colegas publicaram na PNAS sob o título “Generative AI without guardrails can harm learning: Evidence from high school mathematics”. O braço GPT Base teve desempenho estatisticamente pior que o controle, em 17%, na prova sem assistência. Esse número é real e pertence especificamente ao braço Base. Estendê-lo a usuários de IA em geral distorce o achado.

O número que deveria preocupar mais é aquele em que nada aconteceu.

O Remédio Que Sugerimos Não Sobrevive à Prova

Já argumentamos duas vezes que a IA gera dívida cognitiva e que essa dívida já chegou ao pipeline de talento. Os dois textos carregavam a mesma correção implícita, e é a correção óbvia: impedir o modelo de entregar a resposta e obrigá-lo a ensinar. Transformar o gerador em tutor. Adicionar guardrails, usar método socrático, reter a solução, pedir que o aluno raciocine.

O braço GPT Tutor do ensaio turco é a versão com guardrails dessa intervenção. Funcionou de forma espetacular dentro da sessão. E não produziu vantagem mensurável no aluno.

Um ganho de 127% que evapora no instante em que a ferramenta é retirada carrega uma consequência grande. Significa que a sessão de prática estava medindo a dupla, aluno mais modelo, e reportando a nota como se fosse do aluno. Qualquer empresa que meça um onboarding assistido por IA pela saída da sessão está lendo o mesmo instrumento.

O Que a Sessão Mede e Quem Está Aprendendo

O mecanismo aparece mais nítido no trabalho qualitativo. O artigo da ACM “The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers” observou programadores iniciantes trabalhando com assistência de IA e registrou um descompasso entre o que os participantes acreditavam estar fazendo e o que de fato faziam. Nas palavras dos autores: “Os participantes achavam que era como ter um tutor pessoal. Pelos dados do nosso estudo … observamos que eles não usavam, de fato, ferramentas de GenAI como um tutor pessoal. Na verdade, era bem o oposto.”

Não há tamanho de amostra disponível para ele, e é qualitativo, então vale como descrição de comportamento, e não como estimativa de efeito. Os comportamentos descritos são específicos o bastante para qualquer time reconhecer. Participantes com uso intenso de IA “frequentemente pulavam etapas críticas de planejamento”. Terminavam com o que o artigo chama de “ilusão de competência”. Um deles “teve que depender do LLM para corrigir o erro que o próprio LLM havia introduzido”, que é a descrição mais limpa de dependência composta que eu já li.

O estudo da Anthropic de 2026 sobre como a assistência de IA afeta a formação de habilidades de programação chega ao mesmo mecanismo pelo outro lado: “Esforço cognitivo, e até ficar dolorosamente travado, é provavelmente importante para desenvolver maestria.” A dificuldade é insumo da expertise. Um tutor que reduz a dificuldade dentro da sessão otimiza contra aquilo que produz o resultado.

A Habilidade Que de Fato Se Correlacionou

Um grupo do estudo da ACM foi bem. O artigo descreve o que os separou. O grupo bem-sucedido, de uso mitigado, havia desenvolvido “expertise negativa, a capacidade de ignorar sugestões incorretas ou inúteis da GenAI”.

Isso é um critério de contratação e um alvo de treinamento, e fica bem longe dos programas de capacitação em IA que eu vi. Saber quando rejeitar a saída exige já ter um modelo do que é correto. Daí o desconforto de tentar construir essa capacidade com a ferramenta na mão: você a adquire ao estar certo, repetidamente, sobre algo em que o modelo estava errado, o que exige ter estado em posição de saber.

François Chollet descreve o teto que torna isso permanente em vez de transitório: “LLMs são uma base de dados estática de habilidades. São motores de interpolação. Engenharia de software, no entanto, é um exercício de adaptação e resolução de problemas inéditos. Você não consegue interpolar seu caminho através de uma falha de sistema completamente única.” O seu incidente das três da manhã não está na base. Quem responde a ele tem expertise negativa ou está chutando com um copiloto confiante ao lado.

Seis Perguntas, Disponíveis na Segunda-Feira

O ensaio de Lars Faye, “AI Coding will Prevent Expertise” (publicado em julho de 2026, portanto leia como argumento e não como achado recente), traz o artefato mais útil que vi sobre o tema. É um checklist de seis perguntas que o desenvolvedor roda antes de aceitar assistência de IA em uma tarefa. Quatro delas, nas palavras dele:

• “Se eu não tivesse acesso a uma ferramenta de IA, eu ainda conseguiria realizar esta tarefa?”
• “Estou usando o modelo para aprofundar meu entendimento ou para acelerar a resposta?”
• “Se eu tivesse que auditar e verificar a saída gerada, eu conseguiria explicar adequadamente o que estava acontecendo?”
• “Esta é uma tarefa realmente mecânica, já feita 100 vezes antes, ou uma tarefa que exige decisão executiva em algum ponto do processo?”

O checklist funciona porque separa duas coisas que costumam ser colapsadas em uma palavra só. A distinção de Faye: “Dívida cognitiva é abdicar do seu julgamento e das suas decisões, enquanto offloading cognitivo é delegar o mecânico ou tedioso.” Delegar um script de migração que você já escreveu quarenta vezes sai de graça. Delegar a decisão sobre se a migração deveria existir cria a dívida.

E tem a frase que todo líder de engenharia deveria levar para a próxima revisão de arquitetura: “Se você não consegue auditar direito a precisão do código gerado, então você não consegue auditar a precisão do conceito gerado.” A capacidade de auditar é o teto da delegação. Um time que não consegue auditar o código delegou o design sem ter decidido isso.

Faça Isto Agora

Pegue uma das suas contratações mais recentes de engenharia. Dê a ela uma tarefa dentro do código de produção, num escopo em que ela já entregou com assistência de IA, e retire a assistência pelo tempo da tarefa. Observe os primeiros trinta minutos. Você não está testando se ela é mais lenta. Claro que é mais lenta. Você está testando se ela consegue começar.

Essa é a prova sem assistência, e é a única leitura que diz se o último ano de entrega acelerada construiu capacidade ou alugou capacidade. A nota de prática é o análogo do seu gráfico de velocidade. No ensaio, ela se moveu 127% sem que o aluno se movesse nada.

Depois coloque as quatro perguntas de Faye no template de pull request, onde a decisão acontece de verdade. A primeira sozinha já muda comportamento, porque é a única do conjunto que o desenvolvedor não consegue responder com honestidade enquanto a ferramenta está aberta.

---

Fontes

• Lars Faye. “AI Coding will Prevent Expertise.” Julho de 2026.
• Bastani et al., PNAS. “Generative AI without guardrails can harm learning: Evidence from high school mathematics.” 2025.
• ACM. “The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers.” 2024.

A Victorino ajuda organizações de engenharia a medir se a entrega assistida por IA está construindo capacidade ou alugando capacidade: contato@victorino.com.br | www.victorino.com.br