Dez Minutos De IA Bastam Para Reduzir A Persistência? O Que Um Estudo Com 1.222 Pessoas Diz Sobre O Seu Time

Existe um tipo de incômodo que só aparece quando a gente relê o próprio trabalho com calma. Você abre uma função que escreveu meses atrás, percebe que ela está correta, e se pega pensando que há um ou dois anos teria levado uma tarde inteira para chegar naquilo. Depois vem a pergunta menos confortável: e se eu tivesse que escrever de novo, agora, sem a ferramenta aberta na outra aba? Não tenho uma resposta honesta para isso. Tenho a suspeita de que muita gente que trabalha com tecnologia já se fez a mesma pergunta, em silêncio, e preferiu não insistir nela.

Foi essa pergunta que voltou quando vi circular de novo um artigo cujo título já é uma provocação: "AI Assistance Reduces Persistence and Hurts Independent Performance". Vale um esclarecimento logo de saída, porque o ciclo de notícias tende a embaralhar datas: o estudo não é novidade desta semana. Ele foi submetido ao arXiv em abril de 2026, e a versão que consultei é a quarta, de agosto. O que aconteceu foi que ele voltou a circular em sites e redes, com manchetes sobre "dez minutos de IA" e cérebro preguiçoso, e foi nesse formato que ele chegou até mim.

Eu li a página do artigo no arXiv e uma cobertura secundária. Não li o texto completo com tabelas e estatísticas, e isso importa para tudo que vem a seguir. Então este post não é uma resenha técnica do estudo; é uma tentativa de ler o que o resumo afirma com cuidado, separar o que foi medido do que a gente gostaria que tivesse sido medido, e pensar, como alguém que lidera gente, no que vale levar para a conversa com o time.

Vou cobrir cinco coisas: o que o estudo mediu, em termos simples; por que a persistência, e não só o acerto, é a variável interessante para quem lidera; os limites da leitura, incluindo o fato de que não se trata de programação; algumas hipóteses minhas, rotuladas como hipóteses, para a prática de um time; e a distinção entre uma IA que entrega a resposta e uma IA que devolve a pergunta.

---

O Que O Estudo Mediu, Em Termos Simples

O artigo é assinado por Grace Liu, Brian Christian, Tsvetomira Dumbalska, Michiel A. Bakker e Rachit Dubey. A página que li não lista afiliações, e por isso não vou atribuí-lo a nenhuma instituição. O argumento central, segundo o resumo, é que os sistemas de IA atuais funcionam como colaboradores míopes: foram construídos para entregar respostas instantâneas e completas, e não para apoiar o crescimento de longo prazo de quem os usa.

Para testar o que isso causa, os autores relatam ensaios controlados randomizados com 1.222 participantes. Esse número é o total informado; a página não o divide por experimento, então não sei quantas pessoas entraram em cada um. As tarefas citadas são de raciocínio matemático e de compreensão de leitura, entre uma variedade de outras. A cobertura secundária do Let's Data Science afirma que um dos subconjuntos teve 350 participantes e usou problemas de frações, mas eu trato isso como informação de segunda mão.

O desenho, em linhas gerais, compara pessoas que tiveram assistência de IA durante uma etapa com pessoas que não tiveram, e depois observa o que acontece quando a assistência é retirada. Duas consequências são testadas: a persistência, isto é, a disposição de continuar tentando, e o desempenho independente, isto é, o resultado sem a ajuda. O resumo reporta que a assistência melhorou o desempenho no curto prazo, enquanto ela estava presente. Depois, na etapa sem IA, as pessoas que a tinham usado foram significativamente piores e mais propensas a desistir. E o detalhe que gerou as manchetes: os efeitos apareceram depois de apenas cerca de dez minutos de interação com a IA.

Convém ser explícito sobre o que a página que li não traz. Não vi tamanhos de efeito, estatísticas detalhadas, discussão de limitações, nem se os efeitos persistem além das sessões do experimento. Também não está claro, pelo que li, qual sistema de IA foi usado; um agregador mencionou um produto específico, mas não consegui confirmar isso e não vou repetir. Por isso, não vou inventar nenhuma magnitude. Quando alguém disser que "a IA derruba o desempenho em X por cento", desconfie, porque esse número não está no material que eu li.

Por fim, o que o estudo não mediu: programação. Não há, no que consultei, participantes escrevendo código, depurando ou revisando pull requests. Tudo que eu disser adiante sobre engenharia de software é inferência minha, uma extrapolação de tarefas de matemática e leitura para o nosso ofício. Pode ser uma boa extrapolação ou pode ser uma má. O estudo não responde.

---

Por Que Persistência É A Variável Que Interessa A Quem Lidera

A maior parte da conversa pública sobre IA e aprendizado gira em torno de acerto: a pessoa respondeu certo ou errado, entregou mais rápido ou mais devagar. É uma métrica fácil de coletar, e o estudo confirma que, com a IA presente, o desempenho melhora. Nada de surpreendente aí. Se você dá uma ferramenta boa a alguém, o resultado imediato costuma ficar melhor, e seria estranho um time de engenharia ignorar isso.

A persistência é outra coisa. É a variável que descreve o que a pessoa faz quando a resposta não vem de primeira, quando o problema resiste, quando o caminho óbvio não funciona. Quem já liderou um time sabe que boa parte do que separa um engenheiro confiável de um engenheiro apenas rápido está nesse momento: o bug que não reproduz, o desempenho que degrada só em produção, o requisito que não fecha. É o trabalho que não cabe numa estimativa e que, justamente por isso, é onde a experiência aparece.

Se for verdade, em contexto de engenharia, que um período curto de assistência instantânea muda a disposição de insistir quando a ajuda some, isso tem uma consequência estranha para quem gerencia. O ganho de produtividade que a gente mede, com o agente ligado, pode estar convivendo com uma perda que a gente não mede, no momento em que ele está desligado, indisponível, ou simplesmente errado. Repare no "se for verdade" e no "em contexto de engenharia": são duas condições que o estudo não cumpre por mim.

Há uma segunda razão para a persistência importar. Ela não é uma habilidade técnica isolada; é em parte hábito, em parte expectativa. Quem trabalha anos com um colega que sempre devolve uma pergunta aprende a esperar perguntas e a formulá-las sozinho. Quem trabalha com algo que sempre devolve uma resposta pode aprender a esperar respostas. A hipótese dos autores vai exatamente nessa direção: eles postulam que a IA condiciona as pessoas a esperar respostas imediatas, e que isso reduz a persistência. Reforço o verbo, porque é fácil perdê-lo: eles postulam. É uma proposição, não um resultado testado pelo estudo.

Por último, um detalhe que muda o público desta conversa. É tentador ler isso como um problema de quem está começando. Eu desconfio que o mecanismo, se existir, não escolhe senioridade. A hipótese de condicionamento a respostas rápidas vale em princípio para qualquer pessoa exposta a ela, inclusive quem tem quinze anos de estrada. Não sei se o efeito é maior, menor ou igual para quem tem mais repertório; o estudo não me dá isso. Mas a ideia de que seniors estão imunes é uma suposição, e eu gostaria de não a tratar como fato.

---

Leitura Crítica: O Que O Estudo Não Pode Dizer

Quando um resumo diz "significativamente pior" e "mais propensas a desistir", a primeira reação é aceitar a direção e discutir a gravidade. Prefiro fazer o contrário e começar pelos limites, porque eles dizem mais sobre o que se pode decidir com essa informação.

O primeiro limite é a duração. Dez minutos de interação é uma exposição muito curta, e o efeito observado depois dela é, também, medido logo em seguida. Uma sessão de laboratório não é um semestre de trabalho. Pode ser que o efeito dure, pode ser que se dissipe em horas, pode ser que se acumule. A página que li não informa se os efeitos duram além das sessões, e a própria cobertura secundária registra que faltam estudos de longo prazo. Até lá, o que temos é um efeito de curto prazo observado em situação controlada.

O segundo limite é o tipo de tarefa. Raciocínio matemático e compreensão de leitura são tarefas bem delimitadas, com um enunciado, um objetivo claro e um fim. O trabalho de engenharia é cheio de contexto, de ambiguidade sobre o que é a pergunta, de colegas, de histórico, de pressão de prazo. Uma pessoa que desiste de um problema de frações numa tela de experimento está num cenário muito diferente de alguém que desiste de investigar um incidente em produção, com um cliente esperando e um repositório que ela conhece por dentro. Nada garante que a persistência se comporte igual nos dois.

O quarto limite é o que a cobertura secundária acrescenta por conta própria. O Let's Data Science fala de descarregamento cognitivo e de desamparo aprendido como chaves de interpretação. Essas são leituras do veículo, não achados dos autores, e prefiro mantê-las rotuladas assim. São conceitos plausíveis e conhecidos da psicologia, mas uma coisa é um mecanismo ser plausível e outra é o estudo ter testado esse mecanismo. As outras matérias que encontrei, como a do Tech Lusive e o registro no repositório do Stanford SCALE, só consegui ver pelos títulos, então não atribuo a elas nenhum detalhe.

O quinto limite é a replicação. Um resultado de um conjunto de experimentos, por mais bem desenhado que seja, ganha peso quando outros grupos o reproduzem em outras populações e outros contextos. A própria cobertura secundária aponta que a literatura precisa dessa replicação. Eu acrescentaria algo que é só opinião minha: para quem toma decisões sobre times, o custo de esperar a replicação é baixo e o custo de reorganizar o processo em cima de um único estudo é alto. Isso não significa ignorar o resultado; significa tratá-lo como um bom motivo para olhar com mais atenção, e não como uma sentença.

---

O Que Poderia Mudar Na Prática De Um Time (Hipóteses)

Tudo nesta seção é proposta minha, não conclusão do estudo, e nenhuma delas foi testada por mim em time algum. Escrevo como exercício de quem lidera e se pergunta o que faria com a dúvida, não como receita validada.

A primeira hipótese é reservar momentos deliberados sem assistência em tarefas formativas. Imagine um time que decide que, quando alguém assume um tipo de problema pela primeira vez, como diagnosticar uma consulta lenta ou desenhar o modelo de um novo domínio, os primeiros passos são dados sem o assistente, e a IA entra depois, para criticar e ampliar. A ideia não é proibir a ferramenta, é proteger o trecho em que o repertório se forma. Já discuti algo parecido quando falei de preparação deliberada antes de acionar o agente: pensar o problema antes de delegar muda a qualidade do que se delega e, talvez, o que a pessoa aprende no caminho.

A segunda é usar a revisão de código para pedir o raciocínio. Em vez de aprovar um pull request porque os testes passam e o diff parece razoável, o revisor pergunta por que aquela abordagem, que alternativas foram descartadas, o que acontece se o requisito mudar. Um cenário hipotético: um dev apresenta uma solução gerada com ajuda de IA e, ao ser perguntado por que escolheu aquele tratamento de erro, responde que não sabe. Isso não é um julgamento moral sobre ele; é um sinal de que o código entrou no repositório sem entrar na cabeça de ninguém. Pedir a explicação é barato e cria o hábito de não terceirizar o entendimento.

A terceira é o onboarding. Quando uma pessoa nova chega, o time costuma ter pressa de vê-la produtiva, e a IA acelera isso de forma real. A hipótese é que valeria separar, no plano dos primeiros meses, o que é para entregar rápido do que é para aprender fundo, e tratar os dois com regras diferentes. Já escrevi sobre o pipeline de talento e a contratação de juniores por outro ângulo; aqui o ponto é mais estreito, e vale para quem entra em qualquer nível: aprender um sistema novo exige atrito, e atrito é exatamente o que um assistente de resposta instantânea tende a remover.

A quarta é discutir isso com o time sem moralismo. Se o líder chega dizendo que a IA está estragando o raciocínio das pessoas, ele perde a conversa e provavelmente a confiança, porque as pessoas usam a ferramenta e veem o ganho. A postura que me parece mais honesta é a de dividir a dúvida: existe um estudo, ele tem limites, a gente não sabe se vale para o nosso trabalho, e a gente pode combinar algumas práticas baratas enquanto observa. Negar o ganho de produtividade seria desonesto, e ignorar a possibilidade de um custo seria igualmente.

---

IA Que Entrega Resposta Contra IA Que Devolve Pergunta

O diagnóstico dos autores, lembrando, é que os sistemas atuais são colaboradores míopes, projetados para dar respostas instantâneas e completas. A hipótese que segue é que esse desenho condiciona a expectativa de resposta imediata. É uma proposição deles sobre como o produto molda o hábito, e não um achado do experimento. Mas ela abre uma direção de projeto interessante, que vale discutir mesmo sem a prova.

Se o problema fosse a IA em si, a conclusão seria usar menos. Se o problema é o formato da interação, a conclusão pode ser outra: usar de um jeito diferente. Existe uma distância grande entre pedir "resolve isso" e pedir "me ajude a entender onde estou travado, e não me dê a solução ainda". No segundo caso, o assistente atua como um colega que devolve perguntas, que faz a pessoa nomear a hipótese, testar, olhar o log de novo. Não sei se isso preserva a persistência; o estudo que li não testa essa variante. Mas é uma hipótese testável por qualquer time com disciplina para observar o próprio comportamento.

Isso conversa com o que escrevi sobre a passagem de prompt engineering para context engineering. Uma boa parte do trabalho de quem usa IA bem é decidir o que dar de contexto, o que pedir e o que reter. Essa decisão é, em si, um exercício de raciocínio. Pode ser que a diferença entre o uso que fortalece e o uso que enfraquece esteja menos na ferramenta e mais em quanto da decisão de enquadrar o problema continua com a pessoa.

Há um limite prático. Boa parte das ferramentas comerciais é otimizada justamente para a resposta rápida, porque é o que o mercado recompensa e o que dá demonstração bonita. Pedir a um assistente que se comporte como um parceiro socrático exige instruções específicas, e nem sempre ele as segue de forma consistente. Um líder que queira esse comportamento num time provavelmente vai precisar escrever convenções, configurar prompts de sistema e, sobretudo, aceitar que o modo mais lento é o que dá menos satisfação imediata. E satisfação imediata, vale notar, é parte do que a hipótese dos autores sugere que condiciona o hábito.

Também não quero romantizar a pergunta. Para uma sintaxe esquecida ou um boilerplate, devolver pergunta é só atrito. Para o conhecimento que precisa ficar, o atrito talvez seja o preço. Quem lidera pode ajudar a separar as duas categorias, em vez de deixar cada pessoa decidir sob pressão de prazo.

---

O Que Eu Mediria E O Que Eu Não Saberia Medir

Se eu quisesse transformar a dúvida em alguma coisa observável num time real, a primeira tentação seria um indicador de persistência: o tempo que alguém gasta num bug difícil antes de pedir ajuda, ou de desistir. Reconheço de saída que isso é muito difícil de medir sem distorcer. Quem sabe que está sendo cronometrado muda o comportamento, e o tempo antes de pedir ajuda também pode refletir uma decisão sensata de não perder horas num problema que um colega resolve em minutos. Persistir não é virtude em todo contexto; teimosia também custa caro.

Mais viável, pelo menos em tese, seria observar sinais indiretos e qualitativos. Como as pessoas explicam as próprias decisões em revisões. Se conseguem reproduzir, sem a ferramenta, o raciocínio por trás de um trecho que entregaram. Como se saem em incidentes, quando a assistência é limitada ou o contexto é novo demais para o modelo. Nenhum desses sinais é uma métrica limpa, e todos exigem conversa, não dashboard. Já escrevi sobre o risco de medir mal o que é difícil de medir quando falei do desgaste de quem supervisiona agentes; a lição se repete aqui: o que não se mede costuma ser ignorado, e o que se mede mal costuma ser distorcido.

O que eu não saberia medir é a coisa mais importante e também a mais difícil: se o efeito do estudo, caso exista no nosso ofício, se acumula ao longo de meses, se é reversível, se depende de como cada pessoa usa a ferramenta. Para isso seriam necessários estudos longitudinais com profissionais de software, e eu não conheço nenhum que responda isso de forma conclusiva. Aceitar essa lacuna é parte do trabalho. Decidir sem a resposta, com práticas baratas e reversíveis, é o que me parece mais defensável enquanto a evidência não chega.

---

Conclusão

Releio o resumo do artigo e me impressiono menos com o número, 1.222 pessoas, e mais com a pergunta que ele deixa em aberto: o que acontece com a nossa disposição de insistir quando a ferramenta que nos ajuda deixa de estar lá. O estudo responde, para tarefas de matemática e leitura em sessões curtas, que algo muda. Não responde para engenharia de software, não diz quanto dura, e não me deu tamanhos de efeito. Quem usar a manchete para afirmar além disso está lendo mais do que está escrito.

Como alguém que lidera gente, não tiro daí uma proibição nem uma tranquilidade. Tiro uma atenção. Continuo achando que a IA melhora o que o time entrega, e o próprio estudo registra esse ganho enquanto a assistência está presente. Mas passo a querer proteger alguns espaços onde o raciocínio continua sendo da pessoa: tarefas formativas, revisões que pedem explicação, o começo de quem chega. São apostas baratas, reversíveis, e que fazem sentido mesmo que o estudo não se replique.

Fico, então, com uma incerteza que prefiro não esconder. Não sei se o time que eu imagino, produtivo com a IA ligada e frágil com ela desligada, existe de fato ou é uma possibilidade que o estudo me fez enxergar. Talvez a resposta seja que depende do uso, e que a diferença entre uma coisa e outra se decide em decisões pequenas do dia a dia de quem lidera. Se for isso, a melhor contribuição que consigo oferecer neste momento é manter a pergunta viva, sem pânico e sem indiferença, até que a evidência diga mais.

Fontes:

• arXiv — AI Assistance Reduces Persistence and Hurts Independent Performance (2604.04721)
• Let's Data Science — AI Reduces Human Persistence and Independent Performance
• Stanford SCALE — AI Assistance Reduces Persistence and Hurts Independent Performance (índice do repositório)
• Tech Lusive — Is using 10 minutes of AI making your brain lazy? (cobertura)