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

Como manter as tuas competências de programação afiadas quando a IA escreve o código

Que competências de engenharia se perdem primeiro quando a IA escreve a maior parte do teu código, como perceber se as tuas estão a fugir e uma rotina semanal de prática em Go sem IA para as manteres.

Patrik Nilsson
Fundador do LevelUpGo
Publicado a 30 de setembro de 2026
Como manter as tuas competências de programação afiadas quando a IA escreve o código

Manténs as tuas competências de programação afiadas praticando, de propósito e sem o assistente, as partes do trabalho que a IA agora faz por ti. Para a maioria dos engenheiros isso significa fazer o debugging de um problema antes de pedir ajuda, ler código que não escreveste, resolver um problema pequeno a partir de um ficheiro vazio e escrever os testes tu próprio. Eu começaria com uma ou duas horas por semana, com regularidade. No resto da semana podes usar a IA à vontade.

Resumo rápido

  • As competências de raciocínio perdem-se mais do que as práticas. Pilotos habituados a voar com automação mantiveram a capacidade de pilotar à mão, mas tiveram mais dificuldade com a navegação e a deteção de avarias (Casner et al., Human Factors, 2014). Nos programadores, o equivalente mais próximo é o debugging e a leitura de código.
  • A perda de competência pode aparecer em poucos meses. Num estudo observacional, os médicos que usavam IA nas colonoscopias encontraram menos lesões pré-cancerosas quando a IA foi desligada, 22,4 % em vez de 28,4 % (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025).
  • Testa-te com regularidade. Consegues explicar o último diff que fizeste merge? Consegues fazer o debugging de um teste a falhar durante 20 minutos sem escrever um prompt? Se não, são essas as competências a praticar.
  • Uma rotina semanal chega. Resolve um problema pequeno à mão, faz o debugging antes de pedir ajuda à IA, revê os diffs da IA como se fossem de um júnior, lê o código-fonte da biblioteca padrão e escreve tu os testes.
  • Pergunta à IA «porquê», não «corrige». Prevê a resposta primeiro e depois compara. Os engenheiros que estavam a aprender uma biblioteca nova e usaram a IA para fazer perguntas aprenderam-na quase tão bem como os que programaram à mão. Os que lhe passaram o problema aprenderam menos (Anthropic, 2026).

Que competências se perdem primeiro quando a IA escreve o teu código?

As primeiras competências a perder-se são aquelas em que tens de descobrir alguma coisa, como o debugging, a leitura de código e a avaliação de compromissos. Escrever a sintaxe perde-se muito mais devagar.

A aviação é uma boa comparação. Num estudo de 2014, 16 pilotos de linha aérea voaram num simulador de Boeing 747-400 e foram avaliados a pilotá-lo à mão. As capacidades de pilotagem manual estavam «maioritariamente intactas». Os problemas apareceram nas tarefas de raciocínio: saber a posição do avião sem o ecrã do mapa, decidir o passo seguinte e perceber quando um instrumento tinha avariado (Casner et al., Human Factors, 2014). Os investigadores sugeriram que os pilotos mantêm essas competências se continuarem envolvidos de forma ativa na supervisão da automação.

A medicina encontrou algo parecido em 2025. Em quatro centros de endoscopia na Polónia, médicos que estavam a usar uma ferramenta de deteção com IA foram avaliados em colonoscopias feitas sem ela. A taxa de deteção de adenomas caiu de 28,4 % antes da introdução da IA para 22,4 % depois (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025). Foi um estudo observacional, não um ensaio aleatorizado, mas a queda aconteceu em poucos meses.

No software, isso aponta para cinco competências.

Duas colunas. Perde-se sem prática: debugging sem assistente, ler código desconhecido, lembrar APIs de memória, compromissos de desenho de sistemas, estimar quanto tempo demora o trabalho. Importa mais agora: rever diffs que não escreveste, escrever especificações claras, testes e casos limite, arquitetura e fronteiras.

Debugging

O debugging é a competência a vigiar mais de perto. No ensaio de 2026 da Anthropic, o grupo que programou à mão encontrou mais erros do que o grupo com IA, e os investigadores acreditam que foi resolver esses erros que construiu a capacidade de debugging (Anthropic, 2026). Se um assistente te corrige todos os erros, nunca tens essa prática.

Ler código desconhecido

Quando um agente te explica uma base de código, não constróis o teu próprio mapa dela. Isso não tem mal até a explicação estar errada ou o agente não estar disponível durante um incidente. A análise da GitClear a 623 milhões de alterações de código concluiu que as chamadas a código existente caíram de 343 para 223 por cada mil linhas alteradas entre 2023 e 2026 (GitClear, 2026). Menos reutilização é coerente com menos leitura do que já existe.

Saber as APIs de memória

Lembrar importa menos do que as outras competências desta lista, mas continuas a precisar de uma base. Não precisas de decorar todas as funções de strings. Precisas de saber que context.WithTimeout devolve uma função de cancelamento que tens de chamar, e que http.Error não sai do teu handler. Sem esse conhecimento, não consegues perceber quando uma sugestão está errada.

Desenho de sistemas e compromissos

A IA propõe-te um desenho se lho pedires. Escolher entre dois desenhos razoáveis exige critério, e o critério constrói-se a tomar decisões e a viver com os resultados. Se é o agente a escolher a fila, o esquema e a política de retries, nunca descobres quais dos teus instintos estavam certos.

Estimar

Se um assistente faz parte do trabalho, a tua noção de quanto tempo as coisas demoram pode desviar-se. No ensaio de 2025 do METR, programadores experientes demoraram mais 19 % com IA, mas no fim acreditavam que ela os tinha tornado 20 % mais rápidos (METR, 2025). Se a tua própria noção de velocidade pode estar assim tão errada, as tuas estimativas também podem.

Como sabes se as tuas competências estão a fugir?

Descobres testando-te sem o assistente, porque é difícil notar enquanto trabalhas com ele. A Microsoft Research e a Carnegie Mellon concluíram que os trabalhadores do conhecimento com mais confiança na IA diziam pensar de forma menos crítica sobre o que ela produzia (Lee et al., CHI, 2025).

Experimenta estas verificações uma vez por mês:

  1. Explica o último diff que fizeste merge. Escolhe um pull request recente escrito sobretudo pela IA. Explica a um colega, ou em voz alta, porque é que cada alteração lá está. Se não consegues explicar uma alteração, não a conheces de verdade.
  2. Faz debugging durante 20 minutos sem prompts. Pega no próximo teste a falhar ou relatório de bug e trabalha nele só com logs, um debugger e o código-fonte. Repara se vais buscar o assistente logo nos primeiros dois minutos.
  3. Escreve uma função pequena a partir de um ficheiro vazio. Faz o parsing de um ficheiro de configuração, repete uma chamada HTTP com backoff ou remove duplicados de um slice mantendo a ordem. Vê se te lembras das chamadas da biblioteca padrão ou se tens de procurar cada uma.
  4. Prevê antes de executar. Antes de correr um teste, escreve se vai passar. Se falhar, escreve o que vai dizer o erro. Se erras muitas vezes, o teu modelo mental do código afastou-se do código.
  5. Estima e depois mede. Estima quanto tempo uma tarefa vai demorar e compara com o tempo que demorou de facto. Uma diferença cada vez maior sugere que perdeste a noção de para onde vai o tempo.

Nenhuma destas verificações demora muito. Se te deixam desconfortável, isso diz-te que competência praticar.

Qual é a diferença entre delegar trabalho e delegar o raciocínio?

Delegar trabalho é passar à IA algo que já percebes, para poderes pôr a atenção noutro lado. Delegar o raciocínio é passar-lhe algo que não percebes, para nunca teres de o perceber. O primeiro é engenharia normal. O segundo é onde as competências se perdem.

O ensaio da Anthropic concluiu que a forma como as pessoas usaram o assistente importou mais do que usá-lo ou não, e os investigadores concluíram que o esforço cognitivo, «e até ficar dolorosamente bloqueado», é provavelmente importante para dominar um tema (Anthropic, 2026). Ainda deves escrever código à mão? analisa que padrões de uso tiveram bons resultados.

A investigação sobre aprendizagem explica porquê. Robert e Elizabeth Bjork chamam a este tipo de esforço uma «dificuldade desejável»: parece mais lento no momento, mas leva a uma aprendizagem melhor a longo prazo (Bjork & Bjork, 2011). Um dos exemplos que dão é o espaçamento. A prática distribuída ao longo de semanas fixa-se melhor do que a mesma quantidade concentrada numa só sessão, e é por isso que a rotina abaixo é semanal. Recordar algo também é melhor do que relê-lo (APS Observer sobre Roediger & Karpicke, 2006), um estudo que Ainda deves escrever código à mão? trata com mais detalhe.

Para saberes qual dos dois fizeste, pergunta-te uma semana depois: conseguia reescrever este código sem olhar para ele? Se sim, delegaste trabalho que percebes. Se não, volta atrás e aprende-o antes de construíres por cima dele.

Uma rotina semanal de prática sem IA

A rotina abaixo leva uma a duas horas por semana. Podes distribuí-la ou fazê-la de uma vez. O difícil é mantê-la durante meses.

Resolve um problema pequeno à mão

Uma vez por semana, abre um ficheiro vazio com o assistente desligado e resolve um problema pequeno e real. Escolhe algo próximo do teu trabalho: um rate limiter, um parser de CSV que trate campos entre aspas, um worker pool que pare ao primeiro erro. Não passes dos 30 a 45 minutos. Estás a praticar o passo de um ficheiro vazio até código que funciona, por isso o problema pode ser pequeno.

Se queres problemas que já trazem testes, o Training Ground do LevelUpGo tem exercícios de Go independentes pensados exatamente para isto.

Faz o debugging antes de pedir ajuda à IA

Quando algo se parte, dá a ti próprio um tempo fixo, por exemplo 20 minutos, antes de perguntares ao assistente. Forma uma hipótese, reproduz o bug, mede e só depois pergunta.

Este é um bug bom para praticar. Um serviço vai buscar taxas de câmbio a uma API lenta a montante e desiste ao fim de 10 milissegundos:

example.gogo
package main

import (
	"context"
	"errors"
	"fmt"
	"os"
	"runtime"
	"runtime/pprof"
	"time"
)

type Rate struct {
	Currency string
	Value    float64
}

func fetchRate(currency string) Rate {
	time.Sleep(50 * time.Millisecond) // a slow upstream API
	return Rate{Currency: currency, Value: 1.08}
}

func rateWithTimeout(ctx context.Context, currency string) (Rate, error) {
	ctx, cancel := context.WithTimeout(ctx, 10*time.Millisecond)
	defer cancel()

	result := make(chan Rate)
	go func() {
		result <- fetchRate(currency)
	}()

	select {
	case r := <-result:
		return r, nil
	case <-ctx.Done():
		return Rate{}, errors.New("rate lookup timed out")
	}
}

func main() {
	timeouts := 0
	for range 100 {
		if _, err := rateWithTimeout(context.Background(), "EUR"); err != nil {
			timeouts++
		}
	}
	fmt.Println("timeouts:", timeouts)
	time.Sleep(100 * time.Millisecond)
	runtime.GC()
	fmt.Println("goroutines:", runtime.NumGoroutine())
	pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
}

Em produção, o sintoma é um crescimento lento da memória, não um crash. A primeira medição a fazer é o número de goroutines. O Go 1.27 tornou o perfil goroutineleak disponível para todos (notas de lançamento do Go 1.27), por isso o runtime consegue apontar-te a fuga. Executar o programa no Go 1.27 imprime:

example.texttext
timeouts: 100
goroutines: 101
goroutineleak profile: total 100
100 @ 0x1048c59a8 0x10485e854 0x10485e468 0x10491c5ac 0x1048cbc74
#	0x10491c5ab	main.rateWithTimeout.func1+0x5b	./main.go:29

As 100 consultas excederam o tempo limite, e continuam vivas 100 goroutines além da main. A linha 29 é result <- fetchRate(currency). Cada consulta que excede o tempo deixa uma goroutine para trás, bloqueada num envio que ninguém vai receber, porque rateWithTimeout já retornou. A correção é um buffer de um, para que o envio tenha sempre sucesso:

example.gogo
result := make(chan Rate, 1)

Com essa alteração, o mesmo programa imprime goroutines: 1 e goroutineleak profile: total 0. Um assistente encontraria provavelmente este bug depressa. A prática está em encontrá-lo tu, porque a próxima fuga pode estar numa biblioteca que o assistente nunca viu, durante um incidente em que estás por tua conta. A palavra-chave chan em Go explica com mais detalhe as regras dos channels por trás deste bug.

Revê o diff da IA como se fosse de um júnior

Quando um agente abre um pull request, lê-o como lerias um de um membro novo da equipa, inteligente mas sem conhecer o teu sistema. Não perguntes apenas se parece certo. Pergunta o que assumiu. Verifica os caminhos de erro, o tratamento do context, os locks e o que acontece na segunda chamada.

A confiança nestas ferramentas já é baixa. No inquérito de 2025 do Stack Overflow, 84 % dos inquiridos usavam ou planeavam usar ferramentas de IA, mas só 3,1 % confiavam muito na sua precisão (Stack Overflow, 2025). A equipa DORA da Google concluiu que a IA não conserta uma equipa. Ela «amplifica o que já lá está» (DORA 2025, 2025). Para ver o que acontece quando a revisão falha, O lado negro das ferramentas de programação com IA analisa os dados de 2026.

Lê o código-fonte da biblioteca padrão

Uma vez por semana, lê uma função da biblioteca padrão do Go. Está escrita com cuidado, e os comentários de documentação explicam muitas vezes as decisões de design. Não precisas de instalar nada:

example.bashbash
go doc -src net/http.Error
example.gogo
// Error replies to the request with the specified error message and HTTP code.
// It does not otherwise end the request; the caller should ensure no further
// writes are done to w.
// The error message should be plain text.
//
// Error deletes the Content-Length header,
// sets Content-Type to “text/plain; charset=utf-8”,
// and sets X-Content-Type-Options to “nosniff”.
// This configures the header properly for the error message,
// in case the caller had set it up expecting a successful output.
func Error(w ResponseWriter, error string, code int) {
	h := w.Header()
	// ...
	h.Del("Content-Length")
	h.Set("Content-Type", "text/plain; charset=utf-8")
	h.Set("X-Content-Type-Options", "nosniff")
	w.WriteHeader(code)
	fmt.Fprintln(w, error)
}

A segunda linha do comentário explica um bug comum: http.Error escreve uma resposta, mas não para o teu handler. Se te esqueceres do return a seguir, o handler continua a correr. Este é um handler com exatamente esse erro no ramo que descodifica o JSON:

example.gogo
type Order struct {
	ID       string `json:"id"`
	Quantity int    `json:"quantity"`
}

func createOrder(w http.ResponseWriter, r *http.Request) {
	var o Order
	if err := json.NewDecoder(r.Body).Decode(&o); err != nil {
		http.Error(w, "invalid JSON", http.StatusBadRequest)
	}
	if o.Quantity <= 0 {
		http.Error(w, "quantity must be positive", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(o)
}

Sugestões como esta passam numa revisão rápida porque o segundo ramo parece correto. Depois de leres o código-fonte, o return em falta salta à vista. Boas leituras a seguir são sync.Once.Do, errors.Is, context.WithCancel e http.MaxBytesReader.

Escreve tu os testes

Deixa o assistente escrever a implementação se quiseres, mas escreve tu os casos de teste. Decidir o que conta como correto é a parte do trabalho que não deves delegar. Este é um teste em tabela para o handler acima:

example.gogo
func TestCreateOrder(t *testing.T) {
	tests := []struct {
		name     string
		body     string
		wantCode int
		wantBody string
	}{
		{"valid order", `{"id":"A1","quantity":2}`, http.StatusCreated, `{"id":"A1","quantity":2}` + "\n"},
		{"zero quantity", `{"id":"A1","quantity":0}`, http.StatusBadRequest, "quantity must be positive\n"},
		{"malformed JSON", `{"id":`, http.StatusBadRequest, "invalid JSON\n"},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			req := httptest.NewRequest(http.MethodPost, "/orders", strings.NewReader(tt.body))
			rec := httptest.NewRecorder()

			createOrder(rec, req)

			res := rec.Result()
			body, _ := io.ReadAll(res.Body)
			if res.StatusCode != tt.wantCode {
				t.Errorf("status = %d, want %d", res.StatusCode, tt.wantCode)
			}
			if string(body) != tt.wantBody {
				t.Errorf("body = %q, want %q", body, tt.wantBody)
			}
		})
	}
}
example.texttext
--- FAIL: TestCreateOrder (0.00s)
    --- FAIL: TestCreateOrder/malformed_JSON (0.00s)
        handler_test.go:35: body = "invalid JSON\nquantity must be positive\n", want "invalid JSON\n"
FAIL

A verificação do status passa, porque a primeira chamada a WriteHeader é a que conta e a resposta continua a ser um 400. Só a verificação do body apanha o bug. Um servidor real também registaria http: superfluous response.WriteHeader call no log, mas só se alguém ler os logs. Escrever essa asserção sobre o body é um juízo sobre o que pode correr mal, e esse juízo é a competência que estás a praticar. Com o return acrescentado, os três casos passam.

Como deves usar a IA para que te ensine em vez de te substituir?

Usa a IA para testar e explicar o teu raciocínio, e pensa tu primeiro. Há cinco hábitos que ajudam:

  • Prevê primeiro e depois compara. Antes de pedires uma solução, escreve a tua abordagem numa ou duas frases, ou esboça o código. Depois pergunta ao assistente e compara. As diferenças mostram-te o que não sabias.
  • Pergunta «porquê» em vez de «corrige». «Porque é que esta goroutine nunca termina?» dá-te uma explicação que podes verificar. «Corrige isto» dá-te um patch que vais aceitar sem aprender nada.
  • Pede pistas. Diz ao assistente que estás a praticar e que queres uma pista de cada vez. A maioria dos assistentes aceita isso.
  • Põe-no a fazer-te perguntas. No fim de uma sessão, pede três perguntas sobre o código que acabaste de alterar. Se não lhes consegues responder, lê o código outra vez.
  • Reescreve de memória. Quando aceitas código gerado que não percebeste bem, fecha-o e volta a escrevê-lo mais tarde nesse dia. Os sítios onde encravas são as partes que não aprendeste.

A mesma ideia aplica-se quando estás a aprender do zero. Como aprender a programar em 2026 explica como os principiantes podem usar a IA como tutor.

Que competências importam mais agora, e não menos?

As competências de que precisas para orientar a IA e verificar o trabalho dela valem mais agora do que antes.

Rever é a mais óbvia. Os agentes conseguem abrir pull requests mais depressa do que uma equipa os consegue ler, e alguém continua a ter de rever cada um e decidir quais entram.

Escrever especificações é outra. Uma descrição clara do problema, das restrições e dos casos limite dá-te melhores resultados de um agente, e escrevê-la obriga-te a pensar bem no problema.

Os testes contam mais quando não foste tu a escrever o código. São a forma de dizeres a um agente o que é correto e de o apanhares quando erra, por isso os testes em tabela, o fuzzing (tutorial de fuzzing do Go) e o race detector passam a ser mais usados.

Falta a arquitetura. Os agentes trabalham bem dentro de fronteiras claras, mas decidir onde ficam essas fronteiras, que pacote é dono de quê e que interfaces se mantêm estáveis continua a ser trabalho teu.

A escolha da linguagem ajuda nas quatro. O compilador rigoroso do Go, a linguagem pequena e as ferramentas incluídas apanham muitos erros gerados antes da revisão, o que Porque é que o Go é a melhor linguagem para código escrito por IA explica em detalhe. Vale a pena aprender Go em 2026? trata do lado da carreira dessa escolha.

Onde entra o LevelUpGo

O LevelUpGo é um sítio para fazer a parte da rotina sem IA. Cada lição mostra o conceito à esquerda e um editor a sério à direita, sem autocomplete, e só avanças quando o teu código Go compila e passa nos testes. O curso Go Basics, que podes começar grátis, parte dos fundamentos. O Professional Go Testing é onde praticas escrever tu testes em tabela, e o Concurrency Fundamentals cobre goroutines, channels e cancelamento, o código que mais vale a pena saber depurar à mão.

Perguntas frequentes

Quanto tempo devo passar a programar sem IA por semana?

Eu começaria com uma a duas horas por semana e manteria isso durante meses. A investigação sobre aprendizagem favorece sessões curtas e espaçadas em vez de sessões longas e ocasionais (Bjork & Bjork, 2011). Um problema pequeno resolvido à mão, um bug depurado antes de pedir ajuda à IA e uma função da biblioteca padrão lida por semana cobrem as competências mais em risco.

Como pratico quando a minha equipa espera a velocidade da IA?

Faz a prática fora do caminho crítico. Para o hábito de fazer o debugging primeiro, escolhe bugs e tickets que não estejam a bloquear ninguém, e resolve o problema à mão no teu tempo ou num orçamento de formação, se a tua empresa tiver um. Rever diffs e escrever tu os testes encaixam no trabalho normal e quase não te atrasam. Se a tua equipa só mede a produção, fala com a tua chefia sobre a qualidade das revisões e a preparação para as escalas de prevenção. As duas dependem das mesmas competências.

Os engenheiros sénior também perdem competências por causa da IA?

Sim. A experiência não te protege. Os pilotos do estudo de aviação e os médicos do estudo das colonoscopias eram profissionais experientes, e os dois grupos mostraram competências mais fracas onde a automação tinha assumido parte do trabalho (Casner et al., 2014, Budzyń et al., 2025). Os seniores começam com mais competência para perder, e as competências de raciocínio são as que convém vigiar.

Rever código de IA chega para manter as minhas competências?

Sozinho, não. Rever usa o reconhecimento, que é mais fácil do que produzires tu uma solução. Consegues reconhecer uma resposta certa muito depois de teres perdido a capacidade de a escrever. Junta a revisão a prática regular de escrever e depurar código do zero.

As competências perdidas para a IA podem voltar?

A investigação sobre isto é escassa, por isso ninguém o pode garantir. Os estudos acima mediram a competência num dado momento, não a recuperação. O que mostram é que as competências que as pessoas continuaram a usar se mantiveram intactas, como a pilotagem manual dos pilotos (Casner et al., 2014). A resposta prática é começar pelas autoavaliações acima, encontrar a competência mais fraca e praticar essa primeiro.

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