Aprender a programar com IA: não terceirizes o teu cérebro

Q: Usar o ChatGPT para aprender a programar é fazer batota?

Não é batota, a não ser que o teu curso diga o contrário. O risco é saltares aquilo que o exercício devia ensinar. Pedir a uma IA que te explique um erro ou um conceito é como perguntar a um explicador. Pedir-lhe que escreva a solução significa que o exercício deixa de treinar o que quer que seja.

Q: Como sei se percebo mesmo o código que uma IA escreveu?

Tenta alterá-lo sem ajuda. Acrescenta uma funcionalidade, trata um novo caso limite ou diz o que acontece se uma linha for removida. Se consegues prever o que o código vai fazer antes de o correres, percebe-lo. Se só consegues corrê-lo e ver, reconheceste-o. Reconhecer parece compreender enquanto o estás a fazer, e é exatamente essa a lacuna que Soderstrom e Bjork descrevem (Soderstrom & Bjork, 2015).

Q: O que é a descarga cognitiva na programação?

É deixar uma IA decidir a estrutura, o algoritmo ou a correção em vez de chegares lá tu próprio. Isso é eficiente quando já tens a competência. Enquanto ainda a estás a construir, a descarga substitui a prática, e a investigação associa uma descarga maior a um pensamento crítico mais fraco (Gerlich, 2025).

Q: A partir de quando pode um principiante usar ferramentas de programação com IA à vontade?

Quando conseguires escrever o básico sem consultar nada: ciclos, funções, maps, structs, tratamento de erros e um handler HTTP simples. A partir daí, a IA torna-te mais rápido no trabalho que já percebes. Volta a escrever à mão sempre que começares algo novo, como o teu primeiro código concorrente ou a tua primeira camada de base de dados.

Q: A IA vai substituir os programadores júniores?

A investigação aponta um caminho claro para continuares a ser valioso. Os investigadores de Stanford sugerem que a IA está a assumir as tarefas codificáveis e verificáveis, e que está menos preparada para substituir o conhecimento tácito, a compreensão que só ganhas a fazer o trabalho (Stanford Digital Economy Lab, 2025). Essa parte está nas tuas mãos. Um júnior que consegue depurar, rever e explicar o que uma IA escreve traz algo que a ferramenta não traz, e ainda fica mais rápido com a IA.

Quando estás a aprender a programar, o programa que acabas é um efeito secundário. O que estás a construir é um modelo mental: uma imagem na tua cabeça do que o código faz e de porque é que se parte. A IA produz o código em segundos. Não consegue construir essa imagem por ti. Se a deixares pensar por ti enquanto aprendes, acabas com programas que funcionam e uma compreensão fraca deles, e essa lacuna aparece mais tarde, quando alguma coisa se parte.

Resumo rápido

Código que funciona pode parecer compreensão. Principiantes que já estavam com dificuldades acabaram por vezes uma tarefa feita com IA com «uma ilusão de competência», convencidos de que se tinham saído melhor do que realmente saíram (Prather et al., ICER, 2024).
Lembras-te menos do que não produziste. As pessoas que escreveram redações com um LLM tiveram dificuldade em citar o próprio texto minutos depois, num estudo ainda sem revisão por pares (Kosmyna et al., MIT Media Lab, 2025).
Descarregar o raciocínio anda de mãos dadas com menos pensamento crítico. Num estudo com 666 pessoas, um uso mais intenso de IA estava correlacionado com um pensamento crítico mais fraco, e a descarga cognitiva mediava estatisticamente essa relação (Gerlich, Societies, 2025).
O trabalho de entrada está a mudar. O emprego de programadores entre os 22 e os 25 anos caiu quase 20 % desde o pico do final de 2022 até setembro de 2025 (Stanford Digital Economy Lab, 2025).
Os hábitos mantêm o raciocínio teu. Tenta primeiro, pede pistas em vez de respostas, explica o resultado por palavras tuas e reconstrói-o a partir de um ficheiro vazio no dia seguinte.

O que significa terceirizar o teu cérebro para a IA?

Terceirizar o teu cérebro significa deixar a IA fazer o trabalho mental que o exercício existe para te obrigar a fazer. Os psicólogos chamam-lhe descarga cognitiva (cognitive offloading): usar uma ferramenta para um raciocínio que, de outra forma, farias tu. Uma calculadora faz isso com a aritmética e uma aplicação de mapas faz isso com as direções. Um programador experiente pode descarregar boilerplate com pouco custo, porque a compreensão já lá está. Para quem está a aprender, esse trabalho mental é de onde vem a competência, por isso descarregá-lo deixa-te com o resultado e pouco mais.

A questão mais específica de quando escrever o código tu próprio e quando aceitar uma sugestão tem o seu próprio artigo, Ainda deves escrever código à mão?, que percorre os ensaios controlados. Aqui a questão é o que acontece na tua cabeça quando aprendes com um assistente, e quanto isso te vai custar daqui a um ano.

Porque é que código que funciona parece compreensão?

O teu cérebro avalia a compreensão em parte pela fluidez com que as coisas correm, e a IA faz tudo correr com fluidez. Colas um prompt, recebes código, e ele corre. É fácil confundir essa fluidez com competência.

Os cientistas da aprendizagem medem esta lacuna há décadas. Nicholas Soderstrom e Robert Bjork reviram a investigação e concluíram que o desempenho durante a prática «é muitas vezes um indicador pouco fiável» de que houve aprendizagem. Também concluíram que «as pessoas interpretam muitas vezes, erradamente, o seu desempenho durante a aquisição como um guia fiável para a aprendizagem a longo prazo» (Soderstrom & Bjork, Perspectives on Psychological Science, 2015). Condições que parecem difíceis no momento, como recordar em vez de reler, produzem muitas vezes uma aprendizagem mais duradoura. O laboratório de Bjork chama-lhes «dificuldades desejáveis» (Bjork Learning and Forgetting Lab).

Os estudos sobre o uso de IA em 2024 e 2025 apontam no mesmo sentido.

Principiantes com dificuldades podem acabar com uma ilusão de competência

James Prather e colegas observaram programadores principiantes a resolver um problema com IA generativa disponível, usando observação, entrevistas e eye tracking ao longo de 21 sessões de laboratório. Vinte dos 21 estudantes resolveram o problema. Os estudantes que já estavam com dificuldades tinham, à partida, problemas metacognitivos, e a IA «pode agravá-los e até introduzir novas dificuldades metacognitivas». Vários deles «achavam que se tinham saído melhor do que realmente saíram, e terminaram com uma ilusão de competência» (Prather et al., ICER, 2024). Os estudantes com competências metacognitivas mais fortes usaram bem a IA, e é daí que vem o título do artigo, «The Widening Gap».

Os programadores experientes também se enganam. No ensaio de 2025 do METR, demoraram mais 19 % com IA, mas acreditavam ter sido 20 % mais rápidos (METR, 2025), um resultado analisado com mais detalhe em Ainda deves escrever código à mão?. Se pessoas com anos de experiência avaliam mal o próprio progresso, um principiante tem ainda menos em que se apoiar.

Menos esforço, menos memória

Investigadores do MIT Media Lab puseram 54 pessoas a escrever redações com um LLM, com um motor de pesquisa ou sem ferramentas, enquanto registavam a atividade cerebral com EEG. O grupo sem ferramentas mostrou as redes cerebrais mais fortes e mais amplamente ligadas. Quem usou o motor de pesquisa ficou no meio, e quem usou o LLM mostrou a conectividade mais fraca. Quem usou o LLM também «teve dificuldade em citar com exatidão o próprio trabalho», redações que tinha escrito minutos antes (Kosmyna et al., MIT Media Lab, 2025). O estudo é um preprint e ainda não foi revisto por pares, por isso trata-o como evidência preliminar. Era sobre redações, não sobre código, mas o mecanismo é o mesmo de que trata este artigo: lembras-te menos do que não produziste.

Um inquérito maior chegou a algo parecido. Michael Gerlich estudou 666 pessoas e encontrou «uma correlação negativa significativa entre o uso frequente de ferramentas de IA e a capacidade de pensamento crítico, mediada por uma maior descarga cognitiva». Os participantes mais novos recorriam mais à IA e tiveram pontuações mais baixas (Gerlich, Societies, 2025). O estudo é correlacional, por isso não prova que a IA enfraquece o raciocínio. Mostra, sim, que as pessoas que dizem descarregar mais o raciocínio também têm pontuações mais baixas em pensamento crítico.

Onde é que o atalho te volta a morder?

Não notas a compreensão que saltaste no dia em que a saltas. Notas mais tarde, quando a IA não chega ou não está lá.

Fazer o debugging de um panic que nunca percebeste

Imagina que um assistente escreveu a cache em memória do teu primeiro serviço em Go, com um construtor NewCache que prepara tudo, e que funcionou em todos os testes. Depois, um novo caminho no código cria a struct diretamente:

example.gogo
type Cache struct {
	items map[string]string
}

func (c *Cache) Set(key, value string) {
	c.items[key] = value
}

func main() {
	c := &Cache{}
	c.Set("session:42", "user-1893")
}

example.texttext
panic: assignment to entry in nil map

Se tivesses escrito maps à mão umas dezenas de vezes, reconhecias isto de imediato. O valor zero de um map é nil, e ler de um map nil funciona, enquanto escrever nele causa um panic. A correção é tornar o valor zero utilizável com uma verificação de nil em Set (c.items = make(map[string]string)) ou, se a cache viver no seu próprio package, manter items não exportado e documentar que quem a usa tem de chamar NewCache. var vs make em Go explica porque é que o valor zero se comporta assim. Se só tivesses aceitado código com maps, estarias a olhar para um panic numa linha que parece completamente normal, sem fazer ideia por onde começar.

Uma pergunta de code review a que não sabes responder

Um revisor pergunta porque é que o teu handler usa um pointer receiver, ou porque é que passas um context.Context a uma função que nunca o lê. Se escreveste o código, consegues responder, mesmo que a resposta seja «enganei-me». Se o aceitaste, não tens nada para dizer. A mesma lacuna aparece numa entrevista de live coding, em que tens de explicar o teu raciocínio enquanto escreves.

Ler uma base de código que não escreveste

Grande parte do tempo de um programador novo vai para ler código de outras pessoas: seguir um pedido através do middleware, descobrir onde é definido um valor de configuração, perceber porque é que uma worker pool tem o tamanho que tem. A IA consegue resumir um ficheiro. Saber onde procurar a seguir vem de já teres escrito código parecido e de te lembrares onde puseste as coisas.

Porque é que a compreensão pesa mais agora para programadores júniores?

Uma razão provável é que as tarefas em que a IA se sai bem coincidem com aquelas para que os júniores costumavam ser contratados. O Digital Economy Lab de Stanford concluiu que o emprego de programadores entre os 22 e os 25 anos caiu quase 20 % desde o pico do final de 2022 até setembro de 2025, enquanto o emprego dos trabalhadores mais experientes se manteve estável (Brynjolfsson, Chandar & Chen, Stanford Digital Economy Lab, 2025). A revisão de agosto de 2026 coloca o emprego de trabalhadores jovens em funções expostas à IA 19 % abaixo do que seria de esperar sem ela (Brynjolfsson, Chandar & Chen, 2026).

Os autores avisam que outros fatores além da IA podem ter influência. A explicação deles é que a IA «pode estar a automatizar as tarefas codificáveis e verificáveis que historicamente justificavam contratações para funções de entrada», e «pode ser menos capaz de substituir o conhecimento tácito». O conhecimento tácito é a compreensão que só ganhas a fazer o trabalho, e saber porque é que um código gerado está certo ou errado cabe nessa categoria.

Porque é que a dificuldade produtiva é o verdadeiro trabalho?

O modelo mental constrói-se enquanto estás preso. Estás confuso, formas uma hipótese, testas, e muitas vezes está errada. Esses minutos parecem perdidos, mas é aí que se aprende.

Um bug real mostra como isto funciona. Escreves uma função que vai buscar vários URLs em concorrência e sai mais cedo se algum deles falhar:

example.gogo
type result struct {
	body string
	err  error
}

func fetchAll(ctx context.Context, urls []string) ([]string, error) {
	results := make(chan result)
	for _, u := range urls {
		go func() {
			body, err := fetch(ctx, u)
			results <- result{body, err}
		}()
	}

	var bodies []string
	for range urls {
		r := <-results
		if r.err != nil {
			return nil, r.err
		}
		bodies = append(bodies, r.body)
	}
	return bodies, nil
}

Os testes passam. Uma semana depois, a memória do serviço sobe devagar até ele reiniciar. Resolver isto à mão é mais ou menos assim. Verificas runtime.NumGoroutine() e vês o número a crescer. Tiras um perfil de goroutines e encontras centenas delas paradas na mesma linha, results <- result{body, err}. Perguntas quem devia estar a receber desse channel, e a resposta é ninguém, porque fetchAll saiu no primeiro erro. O channel não tem buffer, por isso todos os emissores que sobram ficam bloqueados para sempre.

A correção rápida é uma linha, results := make(chan result, len(urls)), para que todas as goroutines possam enviar e terminar, quer alguém leia quer não. Uma correção melhor também cancela o context, para que os outros pedidos parem mais cedo. Encontrar essa linha ensinou-te mais do que a própria linha: um envio num channel sem buffer espera por um recetor, um return antecipado pode deixar goroutines abandonadas e um perfil de goroutines mostra-te onde estão presas. Um assistente podia ter-te dado a versão corrigida à primeira, e terias código correto sem aprender nada disto. O curso Concurrency Fundamentals põe-te a escrever e a corrigir código com channels que bloqueia desta forma.

Como aprender a programar com IA sem terceirizar o teu cérebro?

Trata a IA como um colega sénior paciente. Pede-lhe que te explique coisas ou que verifique o teu raciocínio quando estiveres preso, e guarda o exercício propriamente dito para ti.

Tenta primeiro, com um limite de tempo

Dá a ti próprio 20 a 30 minutos num problema antes de pedires ajuda. Escreve o que tentaste e onde ficaste preso. Essa nota serve para duas coisas: obriga-te a formular o problema com clareza e dá à IA contexto suficiente para te oferecer uma pista em vez de uma solução completa.

Pede pistas, não soluções

Diz ao assistente que papel deve fazer. Muitas vezes, uma única frase separa um prompt que faz o trabalho por ti de um que te mantém a trabalhar:

Prompt que faz o trabalho por ti	Prompt que te mantém a trabalhar
«Corrige este panic de nil map.»	«Estou a aprender Go. Não escrevas código. Dá-me uma pista sobre porque é que isto causa um panic e faz-me uma pergunta que aponte para a causa.»
«Reescreve esta função para não deixar goroutines penduradas.»	«Aqui está a minha função. Não a reescrevas. Se deixasse goroutines penduradas sob carga, que linha verias primeiro, e porquê?»
«Escreve uma worker pool em Go.»	«Vou escrever uma worker pool. O que devo decidir antes de começar, e o que costuma correr mal?»
«Explica os maps em Go.»	«Faz-me três perguntas sobre maps em Go. Espera pela minha resposta antes de me dizeres se acertei.»

Na coluna da direita, a IA explica ou faz perguntas, e o código continuas a escrevê-lo tu.

Explica o código outra vez por palavras tuas

Se aceitares código de um assistente, não avances enquanto não conseguires explicar cada linha. Escreve a explicação em comentários ou di-la em voz alta. A linha que não consegues explicar é a que tens de ir aprender. Explicar é também a forma mais rápida de perceberes se compreendeste uma coisa ou se apenas a reconheceste.

Reconstrói-o a partir de um ficheiro vazio no dia seguinte

Fecha o ficheiro, abre um vazio amanhã e volta a escrever a solução sem olhar. Vai ser mais lento, e vais ficar preso em alguns sítios. Esses sítios são o que ainda não tinhas aprendido. É a mesma prática de recuperação que faz os flashcards funcionar, aplicada a código.

Mantém a IA fora da fase dos fundamentos

Nas primeiras semanas com uma linguagem, escreve os fundamentos sem assistente: variáveis, ciclos, slices, maps, structs, erros e as tuas primeiras goroutines. Tão cedo, o autocomplete com IA preenche cada linha antes de teres tido oportunidade de pensar nela. Quando o básico já te sair automaticamente, traz as ferramentas de volta para as partes que já percebes. Como aprender a programar em 2026 tem um plano mais completo para essa primeira fase, e 13 erros comuns de principiantes em programação aborda os hábitos que tornam qualquer código, gerado ou não, mais difícil de depurar.

O LevelUpGo foi construído em torno de escreveres o código tu próprio. Cada exercício põe o conceito ao lado de um editor de Go a sério, sem autocomplete de IA, e só conta como concluído quando o teu código compila e passa nos testes. Começa pelas lições grátis de Go Basics, o primeiro curso do percurso Go Fundamentals. Depois mantém a competência afiada com exercícios independentes no Training Ground.

Perguntas frequentes

Usar o ChatGPT para aprender a programar é fazer batota?