LevelUpGo
Sign In
Back to Blog
Go · Article12 min read

Should You Still Write Code by Hand? When It Beats AI in 2026

AI can write most of your code in 2026. The research says there are still times to type it yourself: when you're learning, when you'll have to debug it, and when a mistake would cost real money.

Patrik Nilsson
Founder, LevelUpGo
Published September 23, 2026
Should You Still Write Code by Hand? When It Beats AI in 2026

Yes, but not all of it. In 2026 an AI assistant can write most of the code in a typical backend service, and for boilerplate, test scaffolding and one-off scripts you should let it. Writing it yourself is still the better choice when you're learning something new, when you'll be the one debugging it at 2am, when a bug would leak data or money, and when the logic is what makes your product different. The research from 2025 and 2026 is fairly specific about why.

TL;DR

  • Learning with AI costs you understanding. In Anthropic's randomized trial, developers who learned a new library with AI help scored 50% on a follow-up quiz. Those who coded by hand scored 67%, and the biggest gap was on debugging questions (Anthropic, 2026).
  • "Almost right" is the default failure. 66% of developers say their top frustration is AI code that is almost right but not quite, and 45.2% say debugging AI-generated code takes longer (Stack Overflow Developer Survey, 2025).
  • Security has not caught up. AI-generated code passes security checks only about 55% of the time, a rate that has stayed between 45% and 55% even as syntax correctness passed 95% (Veracode, 2026).
  • You can't feel whether AI is helping. Experienced developers in METR's 2025 trial took 19% longer with AI but believed they were 20% faster (METR, 2025).
  • The rule: let AI write code you could have written yourself. Write by hand anything you don't yet understand.

What does the research say about writing code with AI?

AI makes you faster at producing code and worse at learning from it, and both effects are hard to notice while they're happening to you.

The clearest evidence comes from a January 2026 study by Anthropic. Researchers gave 52 mostly junior engineers, all weekly Python users, a task using Trio, an async library none of them knew. Half could use an AI assistant. Afterwards everyone took a quiz on the library. The AI group averaged 50%. The hand-coding group averaged 67%, a gap the researchers describe as "nearly two letter grades" (Anthropic, 2026). The AI group finished only about two minutes faster, and that difference was not statistically significant.

The largest gap was on debugging questions. Debugging is the part of the job AI hands back to you. When the generated code breaks, you're the one who has to work out why.

A larger study outside programming found the same pattern. In a randomized trial with about 1,000 high school math students, those given a plain ChatGPT-style assistant improved their practice scores by 48%. On the exam without AI, they scored 17% lower than students who never had it (Bastani et al., PNAS, 2025). They finished more of the work and learned less of it.

None of this is surprising to learning scientists. The generation effect, first documented by Slamecka and Graf in 1978, shows that people remember information they produce themselves better than information they only read. Retrieval practice works the same way: students who practiced recalling material did worse on an immediate test than students who reread it, but better a week later (Roediger & Karpicke, Psychological Science, 2006). Accepting an AI suggestion is a lot like rereading. Typing the solution from memory is closer to retrieval.

When should you still write code by hand?

Write code by hand when the cost of not understanding it is higher than the time you'd save. In practice that comes down to six situations.

When you're learning a language, library or pattern

If you're learning Go, write the goroutines, the error wrapping and the interface definitions yourself, even when an assistant could produce them faster. The Anthropic study measured this exact situation, and the hand-coding group came out well ahead.

The study also found that AI use doesn't have to hurt. Participants who asked for code and then asked follow-up questions until they understood it, or who asked only conceptual questions and fixed their own errors, kept quiz scores of 65% or higher (Anthropic, 2026). The scores dropped for people who handed the thinking over to the assistant.

When you'll be the one debugging it

If you'll be the one paged when this code breaks in production, you need to know how it works. If you wrote it, you already have a picture of how it works. If you accepted it, you'll be building that picture during the incident. Stack Overflow's 2025 survey found that 45.2% of developers already say debugging AI-generated code takes longer than debugging their own (Stack Overflow, 2025).

When the code guards money, auth or user data

Veracode tested code from over 100 models and found that 45% of samples introduced an OWASP Top 10 vulnerability (Veracode, 2025). Its spring 2026 update found that the overall security pass rate was still stuck between 45% and 55%. For cross-site scripting, only 15% of samples were safe (Veracode, 2026). Newer and larger models write cleaner syntax, but the security numbers haven't moved.

Confidence makes it worse. In a Stanford study, participants with an AI assistant wrote less secure code and were more likely to believe their code was secure (Perry et al., ACM CCS, 2023). Write authentication, authorization, payment handling, input validation and anything that builds SQL or HTML by hand, or at least read every generated line as a reviewer who expects to find a bug.

When the logic is the product

Boilerplate is the same in every codebase. The pricing rules, the scheduling algorithm and the way your system handles a partial failure are specific to yours. The design decisions live in that code, and writing it is how you find the edge cases the spec missed. Reviewing a generated version tells you what the model assumed about those edge cases, which may or may not be the right answer.

When you can't tell whether AI is actually helping

In METR's 2025 randomized trial, 16 experienced open-source developers worked on 246 real issues in their own repositories. With AI allowed, tasks took 19% longer. Before starting they expected a 24% speedup, and afterwards they still believed AI had made them 20% faster (METR, 2025).

To be fair to the tools, METR's February 2026 follow-up with newer models points the other way. It estimates that experienced developers are now probably sped up, though the confidence intervals still cross zero (METR, 2026). What still holds is the perception gap: feeling faster tells you very little about whether you are. If a task keeps going round in prompt-and-fix loops, stop and write it yourself.

When there's no AI in the room

Technical interviews, whiteboard system design, a production incident on a box with no assistant installed, a pairing session where you have to explain your reasoning: none of these let you delegate. If prompting is the only way you can produce code, it shows quickly.

A Go example: the retry loop your autocomplete gets wrong

Here's what "almost right" looks like in practice. You're writing a helper that retries a flaky call to a downstream service, and your assistant completes the body:

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
}

It compiles, and it passes a test where fn fails twice and then succeeds. It's also wrong in three ways, and you only spot them if you know how Go services behave under load:

  1. It takes a context.Context and ignores it. If the client disconnects or the server starts shutting down, this function keeps sleeping and calling fn for up to four more seconds. Under load, those orphaned retries stack up.
  2. The delay is fixed. When the downstream service is already struggling, every caller retrying on the same one-second beat makes it worse. You want the delay to grow.
  3. It sleeps after the final attempt. The last time.Sleep delays the error by a second for no benefit.

Here's the version you write when you understand those three problems:

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
}

An assistant can produce the second version too, but only if you know to ask for it. That knowledge (context cancellation, backoff, what happens under load) comes from having written loops like this and watching them fail. If you want those reps, the Go Concurrency Fundamentals course covers select, timers and context cancellation with exercises that run real Go.

When is it fine to let AI write the code?

Let AI write the code when you could have written it yourself and reviewing it is faster than typing it. Go developers have largely settled on the same list. In the 2025 Go Developer Survey, the top AI use cases were unit tests, boilerplate, autocomplete, refactoring and documentation (Go Developer Survey, 2026).

Good candidates:

  • Table-driven test cases once you've written the first two by hand
  • Struct tags, JSON mappings and other mechanical translation
  • CLI flag parsing, config loading and similar glue code
  • Migrating a codebase to a new API when the pattern is already clear
  • One-off scripts you'll delete tomorrow
  • Explaining an unfamiliar codebase or error message before you change anything

The same survey is a reminder to keep checking the output. Only 55% of Go developers were satisfied with their AI tools, and the most common complaint, at 53%, was code that doesn't work. A quarter of respondents said they'd rather have no AI involvement in writing code at all, the most resistance to AI of any task in the survey (Go Developer Survey, 2026).

If you're choosing a language for AI-assisted work, Why Go Is the Best Language for AI-Written Code covers why Go's small language, strict compiler and stable APIs suit generated code. For what goes wrong when teams stop checking that code, The Dark Side of AI Coding Tools goes through the 2026 data on production failures, deleted databases and review overload.

A simple rule: could you have written it yourself?

Before you accept a suggestion, ask one question: could I have written this myself, given a bit more time?

If yes, accept it, read it, and move on. You're using AI as a faster keyboard, and you'll catch what it gets wrong.

If no, that's the code to write by hand, or at least to rebuild from memory after you've read the suggestion. That's where the learning happens, and it's also where you're least likely to catch a bug.

This matches what Microsoft Research and Carnegie Mellon found in a 2025 survey of 319 knowledge workers: "higher confidence in GenAI is associated with less critical thinking, while higher self-confidence is associated with more critical thinking" (Microsoft Research, 2025). Knowing you could write the code yourself is what keeps you reading it critically. If you already use AI every day and want to keep that ability, How to Keep Your Coding Skills Sharp When AI Writes the Code lays out a weekly routine of AI-free practice.

Where LevelUpGo fits

LevelUpGo is built around the hand-coding part of this. Every lesson puts the concept on the left and a real editor on the right, and you only advance once your Go code compiles and passes the tests. There's no autocomplete in the editor, so the mistakes and the fixes are yours. Start with the free Go Fundamentals course. Once you're comfortable, the Training Ground has standalone exercises for keeping the skill sharp while AI handles the boilerplate at work.

If you're still deciding where to start, How to Learn to Code in 2026 covers using AI as a tutor instead of a shortcut, and 10 Common Go Mistakes to Avoid lists the bugs worth being able to spot in generated code. For what happens to your learning when AI does the thinking, read Don't Outsource Your Brain.

FAQ

Is it still worth learning to code if AI can write code?

Yes. AI writes code that is often almost right, and 66% of developers say that is their top frustration with it (Stack Overflow, 2025). Spotting and fixing the part that's wrong takes the same understanding as writing it yourself. Learning to code now means being able to judge code, not only produce it.

Does using AI make you a worse programmer?

It can, if you use it to skip the thinking. In Anthropic's 2026 study, developers who delegated to AI while learning scored 17 percentage points lower on understanding. Developers who used AI to ask conceptual questions and fixed their own errors scored nearly as well as those who coded by hand (Anthropic, 2026).

Should beginners use AI coding assistants?

Use them as a tutor, not as an autocomplete. Ask an assistant to explain an error, compare two approaches or quiz you on a concept. Write the solution yourself. Turn off inline completions while you're learning the basics, because accepting a suggestion feels like progress but skips the part that builds memory.

Which code should always be reviewed line by line?

Authentication, authorization, payments, input validation, and anything that builds SQL queries, HTML or shell commands. AI-generated code still fails security checks roughly half the time, and cross-site scripting defenses pass only 15% of the time (Veracode, 2026).

Is AI actually faster for experienced developers?

Probably, but by less than it feels. METR's 2025 trial measured a 19% slowdown while developers believed they'd sped up by 20%. Its 2026 follow-up suggests newer tools now give a modest speedup, with wide uncertainty (METR, 2026). Measure your own tasks instead of trusting the feeling.

Sources

Write Go like a senior engineer

Interactive lessons in your browser. The first ones are free.

Try a free lessonOr create a free account