Qualquer pessoa pode ser um escultor do seu próprio cérebro, se assim o desejar

A irrupção dos grandes modelos de linguagem (LLM) no trabalho diário está a alterar, de forma silenciosa, mas profunda, a forma como pensamos, aprendemos e tomamos decisões. Na engenharia de software, o seu efeito é especialmente visível: pela primeira vez dispomos de ferramentas que não apenas completam automaticamente nomes de variáveis e métodos, mas também propõem arquiteturas, redigem provas, traduzem entre linguagens de programação e sugerem soluções com uma fluidez que concorre com a perícia humana.

A evidência empírica sobre produtividade, ainda que incipiente, já aponta para melhorias mensuráveis em tarefas concretas. Numa experiência controlada com o GitHub Copilot, um grupo de programadores concluiu uma tarefa de implementação significativamente mais depressa do que o grupo de controlo ^[1].  Em paralelo, na escrita profissional observaram-se aumentos de produtividade e alguma convergência de qualidade quando se introduz um assistente tipo ChatGPT ^[2].  A estes resultados somam-se declarações particularmente apelativas de líderes do setor: Gustav Söderström (co-CEO da Spotify) afirmou recentemente, na apresentação de resultados do 4T de 2025, que os seus programadores «não escrevem uma única linha de código desde dezembro», limitando-se a orientar ferramentas de geração ^[3]. Boris Cherny, responsável por Claude Code, afirmou igualmente que «100% do seu código nos últimos dois meses foi escrito integralmente pelo Opus 4,5» ^[4]. Até Sam Altman sugeriu que o GPT-5 Codex foi parte ativa do seu próprio desenvolvimento, programando-se a si próprio ^[5].

Esta mudança de paradigma convive, no entanto, com uma pergunta incómoda, que motiva esta terceira publicação da série sobre LLM: o que acontece com as capacidades que deixamos de exercitar quando «delegamos» parte do esforço cognitivo?

Na educação, o debate polarizou-se entre a fraude e a oportunidade. Existem estudos que descrevem como o acesso generalizado a ferramentas generativas pode alterar comportamentos (e, por vezes, perceções) em torno da integridade académica; em particular, foram publicadas análises com dados anteriores e posteriores à popularização do ChatGPT que exploram a estabilidade ou a alteração de padrões de cópia e reutilização de trabalhos alheios no ensino secundário ^[6]. Para além da sala de aula, preocupa o modo como estas ferramentas reconfiguram hábitos: se um texto «é produzido» com correção suficiente, a tentação de não rever nem integrar o conteúdo no próprio quadro mental é real.

Neste ponto, importa introduzir uma distinção: não é o mesmo usar um LLM como calculadora (externalizar um cálculo mecânico) do que utilizá-lo como substituto do raciocínio (externalizar a construção do modelo mental). A literatura recente começa a apontar riscos compatíveis com esta intuição: observaram-se associações entre maior dependência da IA e níveis mais baixos de pensamento crítico, com mecanismos plausíveis — como a fadiga cognitiva — e com o papel atenuador, ainda que imperfeito, da literacia informacional ^[7].  Além disso, em tarefas de aprendizagem onde se compara o uso de um LLM com o de um motor de pesquisa tradicional, foi relatada uma redução do esforço mental acompanhada por menor profundidade de raciocínio, o que sugere que a «facilidade» pode ter um custo na aprendizagem se não for compensada com estratégias ativas ^[8].

Na engenharia de software, esta «atrofia cognitiva» ^[9] pode ser interpretada como um offloading mal calibrado: transferimos para o assistente etapas que antes eram essenciais no treino de competências criativas e analíticas no desenvolvimento do software (interpretar um erro, depurar hipóteses, desenhar uma abstração, escolher uma estrutura de dados) e ficamos, sobretudo, com tarefas de supervisão e correção. Paradoxalmente, essa supervisão também não é trivial.

A investigação clássica sobre automatização já advertia que o uso, o mau uso e o abuso de sistemas automáticos dependem de fatores como a confiança, a carga mental ou a perceção do risco, e que estes fatores podem conduzir tanto à dependência excessiva como a subutilização das nossas capacidades mentais ^[10]. Em estudos experimentais contemporâneos observou-se igualmente que a simples consciência de que um conselho provém de uma IA pode aumentar a tendência para o seguir, mesmo quando contradiz informação contextual disponível e a própria avaliação do utilizador ^[11]. No código, isto traduz-se na aceitação de sugestões plausíveis, mas defeituosas, com um custo diferido: falhas subtis, dívida técnica e, sobretudo, aprendizagem que não chega a consolidar-se porque o raciocínio é interrompido antes de se estabilizar.

Para jovens, o risco é duplo. Os engenheiros em início de carreira encontram-se perante a dicotomia do Dr. JekyLLM e Mr. Hyde: a IA pode tornar-se numa alavanca de aprendizagem ou numa tentação perigosa que lhes retira a oportunidade de aprender com os erros iniciais, quando ainda são controláveis. Por um lado, os LLM podem acelerar a entrega e criar uma falsa sensação de competência (ao escrever código com o qual o sistema «funciona»), reduzindo o tempo que antes era investido em compreender por que razão funciona. Por outro lado, se as organizações derem prioridade unicamente ao throughput, é fácil deslocar o treino da exploração guiada para a mera execução supervisionada.

Os estudos de usabilidade são muito reveladores: em testes com engenheiros recém-licenciados surgem fricções (por exemplo, dúvidas sobre o que aceitar), mal-entendidos (sobre o que o modelo realmente garante) e estratégias de compensação (revisão a posteriori, patching rápido). Por isso, não basta saber escrever prompts: É necessário aprender a incorporar os LLM sem substituir o raciocínio ^[12]. Em paralelo, as comparações de qualidade alertam que a correção, a manutenção ou a segurança do código gerado não são uniformes: a saída pode ser válida e, ainda assim, subótima ou frágil ^[13].

Neste artigo, defendo que este cenário não é inevitável e que esconde uma oportunidade extraordinária. Com um esforço modesto, o mesmo LLM pode transformar-se numa tecnologia de andaime cognitivo, mais do que de substituição; uma ferramenta que, nas palavras de Ramón e Cajal, nos permita «tornarmo-nos escultores do nosso próprio cérebro» e potenciar a aprendizagem a uma escala difícil de imaginar há apenas algumas décadas.

O primeiro conselho (ou truque) consiste em separar explicitamente dois modos de trabalho complementares: modo entrega rápida e modo aprendizagem. No modo entrega, o objetivo é avançar, mas com controlos de qualidade estritos (testes, análise estática, revisão por pares). No modo aprendizagem, o objetivo continua a ser avançar com esses controlos, mas sem abdicar de fortalecer o modelo mental: pedir alternativas e os respetivos compromissos; exigir explicações com invariantes e complexidade; solicitar que o assistente derive casos limite e justifique porque razão as soluções «ingénuas» falham; ou forçar uma «segunda volta» na qual o próprio engenheiro reescreve a solução sem olhar para o resultado anterior.

Esta inversão é consistente com os resultados de investigações que alertam para a «preguiça metacognitiva»: quando a ferramenta melhora o produto final, pode não melhorar o ganho de conhecimento se não se induzir autorregulação, reflexão e algum nível de esforço pessoal ^[14]. Na linha de revisões críticas recentes sobre IA e aprendizagem, a chave parece estar precisamente nesse processo em que nos moldamos a nós próprios pela prática, centrando menos a atenção na ferramenta em si e mais na forma como se desenha a tarefa e o processo de aprendizagem: que processos cognitivos ativa, que tipo de atenção promove e que hábitos consolida ^[15].

Estas estratégias podem materializar-se em rituais simples, compatíveis com um contexto corporativo e com equipas com membros mais jovens. Por exemplo:

1. Comparação ativa: pedir ao LLM uma solução e, antes de a aceitar, escrever uma própria (ainda que parcial) e depois comparar.
2. Análise post-mortem breve: registar, com palavras próprias, o que se aprendeu (um padrão, uma API, um erro conceptual) e que sinal permitiu detetar uma falha.
3. Restrições deliberadas: reservar pequenas «zonas sem copiloto» (katas, módulos de formação, revisões) onde o jovem programe a partir do zero.
4. Prompts orientados para tutoria personalizada: «não me dê o código final; faça perguntas, sugira passos e valide as minhas hipóteses».
5. Verificação como aprendizagem: transformar a revisão numa atividade intelectual mais exigente (propriedades, invariantes, testes de esforço), e não num simples «passa ou não passa o teste».

Mantendo esta disciplina, o LLM deixa de ser um atalho que «adormece o cérebro» e passa a ser um multiplicador da nossa curiosidade e das nossas possibilidades de crescimento profissional: um sparring intelectual com certas limitações, mas disponível 24/7, que exige que o engenheiro mantenha a responsabilidade pelo raciocínio.

Em última análise, a chave está na prática deliberada e na aprendizagem contínua para manter as capacidades «afiadas», na linha da máxima atribuída a Benjamin Franklin. Parte do meu trabalho consiste em fazer co que a IA evolua, seja útil e responsável em setores onde a fasquia de qualidade é muito elevada. Neste artigo, partilho o que aprendi para que qualquer pessoa — desde quem está a começar até quem tem décadas de experiência — possa refletir e partilhar a sua própria experiência. Se esta série de publicações o ajudou a olhar para a IA com um pouco mais de calma num contexto sobrecarregado de hype, então já cumpriu a sua função.

Autor: David Miraut

Referências:

[1]         S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, «The Impact of AI on Developer Productivity: Evidence from GitHub Copilot», Feb. 13, 2023, arXiv: arXiv:2302.06590. doi: 10.48550/arXiv.2302.06590.

[2]         S. Noy and W. Zhang, «Experimental evidence on the productivity effects of generative artificial intelligence», Science, vol. 381, no. 6654, pp. 187–192, Jul. 2023, doi: 10.1126/science.adh2586.

[3]         «Spotify asegura que sus programadores no han escrito “ni una sola línea de código” en 2026 y eso dice mucho del futuro que nos aguarda». Accessed: Feb. 24, 2026. [Online]. Available: https://www.elconfidencial.com/tecnologia/2026-02-14/programadores-spotify-no-escriben-codigo-1qrt_4302850/?utm_source=chatgpt.com

[4]         M. Zeff, «Cómo Claude Code está transformando el software, empezando por Anthropic», WIRED. Accessed: Feb. 24, 2026. [Online]. Available: https://es.wired.com/articulos/como-claude-code-esta-transformando-el-software-empezando-por-anthropic

[5]         B. Edwards, «How OpenAI is using GPT-5 Codex to improve the AI tool itself», Ars Technica. Accessed: Feb. 24, 2026. [Online]. Available: https://arstechnica.com/ai/2025/12/how-openai-is-using-gpt-5-codex-to-improve-the-ai-tool-itself/

[6]         V. R. Lee, D. Pope, S. Miles, and R. C. Zárate, «Cheating in the age of generative AI: A high school survey study of cheating behaviors before and after the release of ChatGPT», Comput. Educ. Artif. Intell., vol. 7, p. 100253, Dec. 2024, doi: 10.1016/j.caeai.2024.100253.

[7]         J. Tian and R. Zhang, «Learners’ AI dependence and critical thinking: The psychological mechanism of fatigue and the social buffering role of AI literacy», Acta Psychol. (Amst.), vol. 260, p. 105725, Oct. 2025, doi: 10.1016/j.actpsy.2025.105725.

[8]         M. Stadler, M. Bannert, and M. Sailer, «Cognitive ease at a cost: LLMs reduce mental effort but compromise depth in student scientific inquiry», Comput. Hum. Behav., vol. 160, p. 108386, Nov. 2024, doi: 10.1016/j.chb.2024.108386.

[9]         N. Kosmyna et al., «Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task», Dec. 31, 2025, arXiv: arXiv:2506.08872. doi: 10.48550/arXiv.2506.08872.

[10]      R. Parasuraman and V. Riley, «Humans and Automation: Use, Misuse, Disuse, Abuse», Hum. Factors, vol. 39, no. 2, pp. 230–253, Jun. 1997, doi: 10.1518/001872097778543886.

[11]      A. Klingbeil, C. Grützner, and P. Schreck, «Trust and reliance on AI — An experimental study on the extent and costs of overreliance on AI», Comput. Hum. Behav., vol. 160, p. 108352, Nov. 2024, doi: 10.1016/j.chb.2024.108352.

[12]      P. Vaithilingam, T. Zhang, and E. L. Glassman, «Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models», in Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems, in CHI EA ’22. New York, NY, USA: Association for Computing Machinery, Apr. 2022, pp. 1–7. doi: 10.1145/3491101,3519665.

[13]      B. Yetiştiren, I. Özsoy, M. Ayerdem, and E. Tüzün, «Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT», Oct. 22, 2023, arXiv: arXiv:2304.10778. doi: 10.48550/arXiv.2304.10778.

[14]      E. Fan et al., «Beware of metacognitive laziness: Effects of generative artificial intelligence on learning motivation, processes, and performance», Br. J. Educ. Technol., vol. 56, no. 2, pp. 489–530, 2025, doi: 10.1111/bjet.13544.

[15]      E. Bauer, S. Greiff, A. C. Graesser, K. Scheiter, and M. Sailer, «Looking Beyond the Hype: Understanding the Effects of AI on Learning», Educ. Psychol. Rev., vol. 37, no. 2, p. 45, Apr. 2025, doi: 10.1007/s10648-025-10020-8.