LevelUpGo
Iniciar sessão
Voltar ao blog
Go · Artigo14 min de leitura

Ainda deves escrever código à mão? Quando ganha à IA em 2026

Em 2026, a IA consegue escrever a maior parte do teu código. A investigação mostra que ainda há alturas em que o deves escrever tu: quando estás a aprender, quando vais ter de fazer o debugging e quando um erro custaria dinheiro a sério.

Patrik Nilsson
Fundador do LevelUpGo
Publicado a 23 de setembro de 2026
Ainda deves escrever código à mão? Quando ganha à IA em 2026

Sim, mas não todo. Em 2026, um assistente de IA consegue escrever a maior parte do código de um serviço backend típico, e no boilerplate, na estrutura de testes e nos scripts descartáveis deves deixá-lo trabalhar. Escrever o código tu próprio continua a ser melhor quando estás a aprender algo novo, quando vais ser tu a fazer o debugging às 2 da manhã, quando um bug deixaria fugir dados ou dinheiro e quando a lógica é o que distingue o teu produto. A investigação de 2025 e 2026 é bastante concreta sobre o porquê.

Resumo rápido

  • Aprender com IA custa-te compreensão. No ensaio aleatorizado da Anthropic, os programadores que aprenderam uma biblioteca nova com ajuda da IA tiveram 50 % num questionário feito depois. Os que escreveram o código à mão tiveram 67 %, e a maior diferença foi nas perguntas de debugging (Anthropic, 2026).
  • «Quase certo» é a falha mais comum. Para 66 % dos programadores, o que mais os frustra é código de IA que está quase certo, mas não totalmente, e 45,2 % dizem que fazer o debugging de código gerado por IA demora mais (Stack Overflow Developer Survey, 2025).
  • A segurança não acompanhou. O código gerado por IA só passa nas verificações de segurança cerca de 55 % das vezes, uma taxa que se manteve entre 45 % e 55 % mesmo quando a correção sintática passou os 95 % (Veracode, 2026).
  • Não consegues sentir se a IA está a ajudar. No ensaio de 2025 do METR, programadores experientes demoraram mais 19 % com IA, mas acreditavam ter sido 20 % mais rápidos (METR, 2025).
  • A regra: deixa a IA escrever o código que podias ter escrito tu. Escreve à mão tudo o que ainda não percebes.

O que diz a investigação sobre escrever código com IA?

A IA torna-te mais rápido a produzir código e pior a aprender com ele, e nenhum dos dois efeitos é fácil de notar enquanto te está a acontecer.

A evidência mais clara vem de um estudo da Anthropic de janeiro de 2026. Os investigadores deram a 52 engenheiros, na maioria júniores e todos utilizadores semanais de Python, uma tarefa com o Trio, uma biblioteca assíncrona que nenhum deles conhecia. Metade podia usar um assistente de IA. No fim, todos fizeram um questionário sobre a biblioteca. O grupo com IA teve em média 50 %. O grupo que escreveu à mão teve 67 %, uma diferença que os investigadores descrevem como «quase duas notas na escala por letras» (Anthropic, 2026). O grupo com IA acabou apenas cerca de dois minutos mais cedo, e essa diferença não foi estatisticamente significativa.

A maior diferença foi nas perguntas de debugging. O debugging é a parte do trabalho que a IA te devolve. Quando o código gerado se parte, és tu quem tem de descobrir porquê.

Um estudo maior, fora da programação, encontrou o mesmo padrão. Num ensaio aleatorizado com cerca de 1.000 alunos de matemática do ensino secundário, os que receberam um assistente simples ao estilo do ChatGPT subiram 48 % nas notas dos exercícios de prática. No exame sem IA, ficaram 17 % abaixo dos alunos que nunca o tiveram (Bastani et al., PNAS, 2025). Fizeram mais trabalho e aprenderam menos com ele.

Nada disto surpreende quem estuda a aprendizagem. O efeito de geração, documentado pela primeira vez por Slamecka e Graf em 1978, mostra que as pessoas se lembram melhor da informação que produzem elas próprias do que da informação que apenas leem. Com a prática de recuperação passa-se o mesmo: os alunos que treinaram recordar a matéria saíram-se pior num teste logo a seguir do que os que a releram, mas melhor uma semana depois (Roediger & Karpicke, Psychological Science, 2006). Aceitar uma sugestão da IA parece-se muito com reler. Escrever a solução de cabeça está mais perto de recuperar.

Quando é que ainda deves escrever código à mão?

Escreve código à mão quando não o perceber te sai mais caro do que o tempo que pouparias. Na prática, são seis situações.

Quando estás a aprender uma linguagem, biblioteca ou padrão

Se estás a aprender Go, escreve tu as goroutines, o encapsulamento de erros e as definições de interfaces, mesmo quando um assistente as produziria mais depressa. O estudo da Anthropic mediu exatamente esta situação, e o grupo que escreveu à mão ficou bem à frente.

O estudo também mostrou que usar IA não tem de prejudicar. Os participantes que pediram código e depois fizeram perguntas até o perceberem, ou que só fizeram perguntas conceptuais e corrigiram os próprios erros, mantiveram notas de 65 % ou mais no questionário (Anthropic, 2026). As notas caíram para quem passou o raciocínio para o assistente.

Quando vais ser tu a fazer o debugging

Se és tu quem vai ser chamado quando este código falhar em produção, precisas de saber como funciona. Se o escreveste, já tens uma ideia de como funciona. Se o aceitaste, vais construir essa ideia a meio do incidente. No inquérito de 2025 do Stack Overflow, 45,2 % dos programadores já diziam que o debugging de código gerado por IA demora mais do que o do próprio código (Stack Overflow, 2025).

Quando o código protege dinheiro, autenticação ou dados de utilizadores

A Veracode testou código de mais de 100 modelos e concluiu que 45 % das amostras introduziam uma vulnerabilidade do OWASP Top 10 (Veracode, 2025). Na atualização da primavera de 2026, a taxa global de aprovação em segurança continuava presa entre 45 % e 55 %. Em cross-site scripting, só 15 % das amostras eram seguras (Veracode, 2026). Os modelos mais novos e maiores escrevem sintaxe mais limpa, mas os números de segurança não mexeram.

A confiança piora as coisas. Num estudo de Stanford, os participantes com um assistente de IA escreveram código menos seguro e acreditavam mais vezes que o seu código era seguro (Perry et al., ACM CCS, 2023). Escreve à mão a autenticação, a autorização, o processamento de pagamentos, a validação de input e tudo o que construa SQL ou HTML, ou pelo menos lê cada linha gerada como um revisor que conta encontrar um bug.

Quando a lógica é o produto

O boilerplate é igual em todas as bases de código. As regras de preços, o algoritmo de agendamento e a forma como o teu sistema lida com uma falha parcial são específicos do teu. As decisões de design estão nesse código, e é ao escrevê-lo que encontras os casos limite que a especificação deixou escapar. Rever uma versão gerada diz-te o que o modelo assumiu sobre esses casos limite, e isso pode ou não ser a resposta certa.

Quando não consegues perceber se a IA está mesmo a ajudar

No ensaio aleatorizado de 2025 do METR, 16 programadores open source experientes trabalharam em 246 issues reais nos seus próprios repositórios. Quando podiam usar IA, as tarefas demoraram mais 19 %. Antes de começarem, esperavam ser 24 % mais rápidos, e no fim continuavam a achar que a IA os tinha tornado 20 % mais rápidos (METR, 2025).

Em abono das ferramentas, o estudo de seguimento do METR de fevereiro de 2026, com modelos mais recentes, aponta no sentido contrário. Estima que os programadores experientes são agora provavelmente mais rápidos, embora os intervalos de confiança ainda incluam o zero (METR, 2026). O que continua válido é o desfasamento na perceção: sentires-te mais rápido diz muito pouco sobre se o és. Se uma tarefa anda às voltas em ciclos de prompt e correção, para e escreve-a tu.

Quando não há IA por perto

Entrevistas técnicas, desenho de sistemas no quadro, um incidente em produção numa máquina sem nenhum assistente instalado, uma sessão de pair programming em que tens de explicar o teu raciocínio: em nenhuma destas situações podes delegar. Se só consegues produzir código com prompts, isso nota-se depressa.

Um exemplo em Go: o ciclo de retry que o teu autocomplete erra

Vê como é o «quase certo» na prática. Estás a escrever uma função auxiliar que repete uma chamada instável a um serviço a jusante, e o teu assistente completa o corpo:

example.gogo
func retry(ctx context.Context, fn func() error) error {
	var err error
	for i := 0; i < 5; i++ {
		if err = fn(); err == nil {
			return nil
		}
		time.Sleep(time.Second)
	}
	return err
}

Compila e passa num teste em que fn falha duas vezes e depois tem sucesso. Também está errado de três maneiras, e só as vês se souberes como os serviços em Go se comportam sob carga:

  1. Recebe um context.Context e ignora-o. Se o cliente se desligar ou o servidor começar a encerrar, esta função continua a dormir e a chamar fn durante até mais quatro segundos. Sob carga, estes retries órfãos acumulam-se.
  2. O intervalo é fixo. Quando o serviço a jusante já está em dificuldades, ter todos os clientes a repetir ao mesmo ritmo de um segundo só a deixa pior. Queres que o intervalo vá crescendo.
  3. Dorme depois da última tentativa. O último time.Sleep atrasa o erro um segundo sem ganhar nada com isso.

Esta é a versão que escreves quando percebes esses três problemas:

example.gogo
func retry(ctx context.Context, fn func() error) error {
	const maxAttempts = 5
	delay := 100 * time.Millisecond

	var err error
	for attempt := range maxAttempts {
		if err = fn(); err == nil {
			return nil
		}
		if attempt == maxAttempts-1 {
			break
		}

		timer := time.NewTimer(delay)
		select {
		case <-ctx.Done():
			timer.Stop()
			return errors.Join(err, ctx.Err())
		case <-timer.C:
		}
		delay *= 2
	}
	return err
}

Um assistente também consegue produzir a segunda versão, mas só se souberes que a tens de pedir. Esse conhecimento (cancelamento por context, backoff, o que acontece sob carga) vem de teres escrito ciclos como este e de os veres falhar. Se queres ganhar essa prática, o curso Go Concurrency Fundamentals cobre select, timers e cancelamento por context com exercícios que executam Go a sério.

Quando é que podes deixar a IA escrever o código?

Deixa a IA escrever o código quando o podias ter escrito tu e revê-lo é mais rápido do que escrevê-lo. Os programadores de Go chegaram mais ou menos à mesma lista. No Go Developer Survey 2025, os principais usos da IA foram testes unitários, boilerplate, autocomplete, refatoração e documentação (Go Developer Survey, 2026).

Bons candidatos:

  • Casos de teste em tabela, depois de escreveres os dois primeiros à mão
  • Struct tags, mapeamentos JSON e outras traduções mecânicas
  • Parsing de flags de CLI, carregamento de configuração e código de ligação semelhante
  • Migrar uma base de código para uma nova API quando o padrão já está claro
  • Scripts descartáveis que vais apagar amanhã
  • Explicar uma base de código ou uma mensagem de erro desconhecida antes de mudares alguma coisa

O mesmo inquérito lembra que convém continuar a verificar o resultado. Só 55 % dos programadores de Go estavam satisfeitos com as suas ferramentas de IA, e a queixa mais comum, com 53 %, foi código que não funciona. Um quarto dos inquiridos disse que preferia que a IA não tivesse qualquer papel na escrita de código, a maior resistência à IA de todas as tarefas do inquérito (Go Developer Survey, 2026).

Se estás a escolher uma linguagem para trabalhar com IA, Porque é que o Go é a melhor linguagem para código escrito por IA explica porque é que a linguagem pequena do Go, o compilador rigoroso e as APIs estáveis se adequam a código gerado. E para ver o que corre mal quando as equipas deixam de verificar esse código, O lado negro das ferramentas de programação com IA analisa os dados de 2026 sobre falhas em produção, bases de dados apagadas e a sobrecarga de revisões.

Uma regra simples: conseguias tê-lo escrito tu?

Antes de aceitares uma sugestão, faz uma pergunta: conseguia ter escrito isto eu próprio, com um pouco mais de tempo?

Se sim, aceita, lê e segue em frente. Estás a usar a IA como um teclado mais rápido, e vais apanhar o que ela errar.

Se não, esse é o código a escrever à mão, ou pelo menos a reconstruir de memória depois de leres a sugestão. É aí que aprendes, e é também aí que tens menos hipóteses de apanhar um bug.

Isto bate certo com o que a Microsoft Research e a Carnegie Mellon concluíram num inquérito de 2025 a 319 trabalhadores do conhecimento: «uma maior confiança na GenAI está associada a menos pensamento crítico, enquanto uma maior autoconfiança está associada a mais pensamento crítico» (Microsoft Research, 2025). Saberes que conseguias escrever o código tu próprio é o que te faz continuar a lê-lo com espírito crítico. Se já usas IA todos os dias e queres manter essa capacidade, Como manter as tuas competências de programação afiadas quando a IA escreve o código propõe uma rotina semanal de prática sem IA.

Onde entra o LevelUpGo

O LevelUpGo foi construído em torno da parte de escrever código à mão. Cada lição mostra o conceito à esquerda e um editor a sério à direita, e só avanças quando o teu código Go compila e passa nos testes. O editor não tem autocomplete, por isso os erros e as correções são teus. Começa pelo curso Go Fundamentals, que é grátis. Quando te sentires à vontade, o Training Ground tem exercícios independentes para manteres a competência afiada enquanto a IA trata do boilerplate no trabalho.

Se ainda estás a decidir por onde começar, Como aprender a programar em 2026 explica como usar a IA como tutor em vez de atalho, e 10 erros comuns em Go a evitar enumera os bugs que vale a pena saber detetar em código gerado. Para perceberes o que acontece à tua aprendizagem quando a IA pensa por ti, lê Não terceirizes o teu cérebro.

Perguntas frequentes

Ainda vale a pena aprender a programar se a IA consegue escrever código?

Sim. A IA escreve código que muitas vezes está quase certo, e 66 % dos programadores dizem que essa é a sua maior frustração com ela (Stack Overflow, 2025). Para detetar e corrigir a parte errada precisas de perceber o código tanto como se o tivesses escrito tu. Aprender a programar hoje significa ser capaz de avaliar código, não apenas de o produzir.

Usar IA torna-te pior programador?

Pode tornar, se a usares para saltar o raciocínio. No estudo de 2026 da Anthropic, os programadores que delegaram na IA enquanto aprendiam ficaram 17 pontos percentuais abaixo em compreensão. Os programadores que usaram a IA para fazer perguntas conceptuais e corrigiram os próprios erros tiveram resultados quase tão bons como os que escreveram o código à mão (Anthropic, 2026).

Os principiantes devem usar assistentes de programação com IA?

Usa-os como tutor, não como autocomplete. Pede a um assistente que te explique um erro, que compare duas abordagens ou que te faça perguntas sobre um conceito. Escreve tu a solução. Desliga as sugestões inline enquanto estás a aprender o básico, porque aceitar uma sugestão parece progresso, mas salta a parte que constrói a memória.

Que código deve ser sempre revisto linha a linha?

Autenticação, autorização, pagamentos, validação de input e tudo o que construa queries SQL, HTML ou comandos de shell. O código gerado por IA ainda falha as verificações de segurança cerca de metade das vezes, e as defesas contra cross-site scripting só passam 15 % das vezes (Veracode, 2026).

A IA torna mesmo os programadores experientes mais rápidos?

Provavelmente, mas menos do que parece. O ensaio de 2025 do METR mediu um abrandamento de 19 %, enquanto os programadores acreditavam ter ficado 20 % mais rápidos. O estudo de seguimento de 2026 sugere que as ferramentas mais recentes já dão um ganho de velocidade modesto, com uma incerteza grande (METR, 2026). Mede as tuas próprias tarefas em vez de confiares na sensação.

Fontes

Escreve Go como um engenheiro sénior

Lições interativas no navegador. As primeiras são grátis.

Experimenta uma lição grátisOu cria uma conta gratuita