Learning to Code With AI: Don't Outsource Your Brain

Q: Is it cheating to use ChatGPT when learning to code?

It isn't cheating, unless your course says otherwise. The risk is that you skip what the exercise was meant to teach. Asking an AI to explain an error or a concept is like asking a tutor. Asking it to write the solution means the exercise no longer trains anything.

Q: How can I tell if I actually understand code an AI wrote?

Try to change it without help. Add a feature, handle a new edge case, or say what happens if one line is removed. If you can predict what the code will do before running it, you understand it. If you can only run it and see, you've recognized it. Recognition feels like understanding while you're doing it, which is exactly the gap Soderstrom and Bjork describe (Soderstrom & Bjork, 2015).

Q: What is cognitive offloading in programming?

It's letting an AI decide the structure, the algorithm or the fix instead of working it out yourself. That's efficient once you have the skill. While you're still building it, offloading replaces the practice, and research links heavier offloading to weaker critical thinking (Gerlich, 2025).

Q: At what point can a beginner use AI coding tools freely?

Once you can write the basics without looking anything up: loops, functions, maps, structs, error handling and a simple HTTP handler. From there AI speeds you up on work you already understand. Go back to writing by hand whenever you start something new, such as your first concurrent code or your first database layer.

Q: Will AI replace junior developers?

The research points to a clear way to stay valuable. Stanford's researchers suggest AI is taking over codifiable, checkable tasks and is less suited to replacing tacit knowledge, the understanding you only build by doing the work (Stanford Digital Economy Lab, 2025). That part is in your hands. A junior who can debug, review and explain what an AI writes brings something the tool doesn't, and gets faster with AI on top of it.

When you're learning to code, the program you finish is a side effect. The thing you're building is a mental model: a picture in your head of what the code does and why it breaks. AI can produce the code in seconds. It can't build that picture for you. If you let it do the thinking while you're learning, you end up with working programs and a thin understanding of them, and the gap shows up later, when something breaks.

TL;DR

Working code can feel like understanding. Novices who were already struggling sometimes finished an AI-assisted task with "an illusion of competence," believing they had done better than they had (Prather et al., ICER, 2024).
You remember less of what you didn't produce. People who wrote essays with an LLM struggled to quote their own work minutes later, in a study not yet peer-reviewed (Kosmyna et al., MIT Media Lab, 2025).
Offloading goes with less critical thinking. In a study of 666 people, heavier AI use correlated with weaker critical thinking, and cognitive offloading statistically mediated the link (Gerlich, Societies, 2025).
Entry-level work is shifting. Employment of software developers aged 22-25 fell nearly 20% from its late-2022 peak by September 2025 (Stanford Digital Economy Lab, 2025).
Habits keep the thinking yours. Attempt first, ask for hints instead of answers, explain the result back, and rebuild it from a blank file the next day.

What does it mean to outsource your brain to AI?

Outsourcing your brain means letting the AI do the mental work the exercise exists to make you do. Psychologists call this cognitive offloading: using a tool for thinking you would otherwise do yourself. A calculator does it for arithmetic and a map app does it for directions. An experienced developer can offload boilerplate at little cost, because the understanding is already there. For a learner, that mental work is where the skill comes from, so offloading it leaves you with the output and little else.

The narrower question of when to type code yourself versus accept a suggestion has its own post, Should You Still Write Code by Hand?, which walks through the controlled trials. Here the question is what happens in your head when you learn with an assistant, and what it costs you a year from now.

Why does working code feel like understanding?

Your brain judges understanding partly by how smoothly things go, and AI makes everything go smoothly. You paste a prompt, you get code, it runs. That fluency is easy to mistake for competence.

Learning scientists have measured this gap for decades. Nicholas Soderstrom and Robert Bjork reviewed the research and concluded that performance during practice "is often an unreliable index" of whether learning has happened. They also found that "people often mistakenly interpret their performance during acquisition as a reliable guide to long-term learning" (Soderstrom & Bjork, Perspectives on Psychological Science, 2015). Conditions that feel hard in the moment, like recalling instead of rereading, often produce more durable learning. Bjork's lab calls these "desirable difficulties" (Bjork Learning and Forgetting Lab).

Studies of AI use in 2024 and 2025 point the same way.

Struggling novices can finish with an illusion of competence

James Prather and colleagues watched novice programmers solve a problem with generative AI available, using observation, interviews and eye tracking across 21 lab sessions. Twenty of the 21 students completed the problem. Students who were already struggling had metacognitive difficulties to begin with, and AI "can compound them and even introduce new metacognitive difficulties." Several of them "thought they performed better than they did, and finished with an illusion of competence" (Prather et al., ICER, 2024). Students with stronger metacognitive skills used AI well, which is where the paper's title, "The Widening Gap," comes from.

Experienced developers misjudge it too. In METR's 2025 trial they took 19% longer with AI while believing they were 20% faster (METR, 2025), a result covered in more detail in Should You Still Write Code by Hand?. If people with years of experience misread their own progress, a beginner has even less to go on.

Less effort in, less memory out

Researchers at the MIT Media Lab had 54 people write essays with an LLM, with a search engine, or with no tools, while recording their brain activity with EEG. The no-tools group showed the strongest and most widely connected brain networks. Search users sat in the middle, and LLM users showed the weakest connectivity. LLM users also "struggled to accurately quote their own work," essays they had written minutes earlier (Kosmyna et al., MIT Media Lab, 2025). The study is a preprint and hasn't been peer-reviewed yet, so treat it as early evidence. It was about essays, not code, but the mechanism is the one this post is about: you remember less of what you didn't produce.

A larger survey found something similar. Michael Gerlich studied 666 people and found "a significant negative correlation between frequent AI tool usage and critical thinking abilities, mediated by increased cognitive offloading." Younger participants leaned on AI more and scored lower (Gerlich, Societies, 2025). The study is correlational, so it doesn't prove that AI weakens thinking. It does show that people who report offloading more also score lower on critical thinking.

Where does the shortcut come back to bite you?

You don't notice skipped understanding on the day you skip it. You notice it later, when the AI isn't enough or isn't there.

Debugging a panic you never understood

Say an assistant wrote the in-memory cache for your first Go service, with a NewCache constructor that sets everything up, and it worked in every test. Then a new code path builds the struct directly:

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

If you had written maps by hand a few dozen times, you'd recognize this immediately. The zero value of a map is nil, and reading from a nil map works while writing to it panics. The fix is to make the zero value usable with a nil check in Set (c.items = make(map[string]string)), or, if the cache lives in its own package, to keep items unexported and document that callers must use NewCache. var vs make in Go explains why the zero value behaves this way. If you had only ever accepted map code, you'd be looking at a panic on a line that looks completely normal, with no idea where to start.

A code review question you can't answer

A reviewer asks why your handler uses a pointer receiver, or why you're passing a context.Context into a function that never reads it. If you wrote the code, you can answer, even if the answer is "I got that wrong." If you accepted it, you have nothing to say. The same gap shows up in a live-coding interview, where you have to explain your reasoning as you type.

Reading a codebase you didn't write

A lot of a new developer's time goes into reading other people's code: tracing a request through middleware, finding where a config value gets set, working out why a worker pool has the size it does. AI can summarize a file. Knowing where to look next comes from having written similar code and remembering where you put things.

Why does understanding matter more for entry-level developers now?

One likely reason is that the tasks AI handles well overlap with the ones juniors used to be hired for. Stanford's Digital Economy Lab found that employment of software developers aged 22-25 fell nearly 20% from its late-2022 peak by September 2025, while employment for more experienced workers held steady (Brynjolfsson, Chandar & Chen, Stanford Digital Economy Lab, 2025). The August 2026 revision puts employment of young workers in AI-exposed jobs 19% below where it would otherwise be (Brynjolfsson, Chandar & Chen, 2026).

The authors caution that factors other than AI may play a role. Their explanation is that AI "may be automating the codifiable, checkable tasks that historically justified entry-level headcount," and it "may be less capable of replacing tacit knowledge." Tacit knowledge is the understanding you only get by doing the work, and knowing why a piece of generated code is right or wrong falls in that category.

Why is productive struggle the actual work?

The mental model gets built while you're stuck. You're confused, you form a guess, you test it, and often it's wrong. Those minutes feel wasted, but they're where the learning happens.

Here's what that looks like with a real bug. You write a function that fetches several URLs concurrently and returns early if any of them fails:

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
}

The tests pass. A week later the service's memory climbs slowly until it restarts. Working it out by hand goes something like this. You check runtime.NumGoroutine() and see it growing. You take a goroutine profile and find hundreds of goroutines parked on the same line, results <- result{body, err}. You ask who is supposed to receive from that channel, and the answer is nobody, because fetchAll returned on the first error. The channel is unbuffered, so every remaining sender blocks forever.

The quick fix is one line, results := make(chan result, len(urls)), so every goroutine can send and exit whether or not anyone reads. A better fix also cancels the context so the other requests stop early. Finding that line taught you more than the line itself: a send on an unbuffered channel waits for a receiver, an early return can strand goroutines, and a goroutine profile shows you where they're stuck. An assistant could have handed you the fixed version on the first try, and you'd have had correct code without learning any of that. The Concurrency Fundamentals course has you write and fix channel code that blocks like this.

How do you learn to code with AI without outsourcing your brain?

Treat AI like a patient senior colleague. Ask it to explain things or to check your thinking when you're stuck, and keep the exercise itself for yourself.

Attempt first, with a time box

Give yourself 20 to 30 minutes on a problem before asking for help. Write down what you tried and where you got stuck. That note helps twice. It makes you state the problem clearly, and it gives the AI enough context to offer a hint instead of a full solution.

Ask for hints, not solutions

Tell the assistant what role to play. Often a single sentence separates a prompt that does the work for you from one that keeps you working:

Prompt that does the work for you	Prompt that keeps you working
"Fix this nil map panic."	"I'm learning Go. Don't write code. Give me one hint about why this panics, and ask me a question that points toward the cause."
"Rewrite this function so it doesn't leak goroutines."	"Here's my function. Don't rewrite it. Which line would you look at first if it leaked goroutines under load, and why?"
"Write a worker pool in Go."	"I'm about to write a worker pool. What should I decide before I start, and what usually goes wrong?"
"Explain Go maps."	"Quiz me with three questions about Go maps. Wait for my answer before telling me if I'm right."

In the right-hand column the AI explains or asks questions, and you still write the code.

Explain the code back in your own words

If you do take code from an assistant, don't move on until you can explain every line. Write the explanation as comments, or say it out loud. The line you can't explain is the one to go and learn. Explaining is also the quickest way to tell whether you understood something or only recognized it.

Rebuild it from a blank file the next day

Close the file, open an empty one tomorrow, and write the solution again without looking. It will be slower, and you'll get stuck in places. Those places are what you hadn't learned yet. It's the same retrieval practice that makes flashcards work, applied to code.

Keep AI out of the fundamentals phase

For your first few weeks with a language, write the fundamentals without an assistant: variables, loops, slices, maps, structs, errors and your first goroutines. This early on, AI autocomplete fills in each line before you've had a chance to think about it yourself. Once the basics are automatic, bring the tools back for the parts you already understand. How to Learn to Code in 2026 has a fuller plan for that first stretch, and 13 Common Beginner Programming Mistakes covers the habits that make any code, generated or not, harder to debug.

LevelUpGo is built around writing the code yourself. Each exercise puts the concept next to a real Go editor with no AI completions, and it only counts as complete once your code compiles and passes the tests. Start with the free lessons in Go Basics, the first course of the Go Fundamentals track. Then keep the skill sharp with standalone exercises in the Training Ground.

FAQ

Is it cheating to use ChatGPT when learning to code?