Is learning to code still worth it when AI writes code

On the sixth of October I gave two Anthropic models the same prompt, in Polish: write a C# method that returns a student’s average grade rounded to one decimal place, with the grades arriving as a List<int>. The smaller model, Claude Haiku 4.5, returned this:

public double ObliczSrednia(List<int> oceny)
{
    if (oceny.Count == 0)
        return 0;

    return Math.Round(oceny.Average(), 1);
}

It compiles. Short, and reasonable-looking. The larger model, Claude Sonnet, returned almost the same thing: an exception instead of return 0, and one extra argument to Math.Round.

One of these methods gets the arithmetic wrong.

If you’re asking “is learning to code still worth it” when a model writes that method in seconds, this is the moment that answers it. A model will happily write code you can’t read. That isn’t a saving but a debt, and you pay it back at the first bug, usually with interest, because someone else finds the bug first.

What decides whether generated code saves you anything

Not whether the model can program. Both can. The deciding question is whether you can look at two answers and point to the correct one before you run it on real data.

Writing code stopped being the bottleneck. Reading it didn’t, and it matters more now than before, because there’s far more code to read and its author has no idea what you actually expected.

When you write a method yourself, you pick every default on purpose, even when you pick badly. You know you didn’t think about the empty list, because nobody else was there to think about it. Generated code takes that knowledge away. The decisions were made, just not by you, and they don’t show up in the text, because nobody types a default.

The whole difference between the two methods is one argument, MidpointRounding.AwayFromZero. Without it, .NET rounds a value sitting exactly halfway to the nearest even digit. That’s banker’s rounding, and it’s what Math.Round does unless you say otherwise.

How often the Haiku version is quietly wrong

I ran both methods over every possible grade total on the 1 to 6 scale Polish schools use, for students with anywhere from two to thirty grades, and compared each result against exact decimal arithmetic. The Sonnet version agreed in all 2349 cases.

The Haiku version missed 55 of them:

4 grades sum 5: got 1.2
4 grades sum 9: got 2.2
4 grades sum 13: got 3.2
4 grades sum 17: got 4.2
4 grades sum 21: got 5.2
55 of 2349 wrong

A student with 5, 4, 4 and 4 averages 4.25. The rounding everyone learns at school gives 4.3. The method returns 4.2, because 2 is even. No exception, no compiler warning, nothing in the console.

With four grades, it’s wrong on five of the twenty-one possible totals.

Nothing here is a syntax error. The prompt didn’t say how to round halves, so the model filled the gap with a default and didn’t mention it. Sonnet spotted the same gap and explained its choice. If you can’t read the code, you don’t know which of the two you got today.

A zero that isn’t a grade

The second problem is worse, because it moves the result by a lot more than a tenth. Early in a school year, some subjects have no grades yet. I built a tiny gradebook with three subjects and averaged the subject averages, each one computed by the Haiku method:

5 | 4.5 | 0
3.17

Maths averages 5, physics 4.5, and the student ends up with 3.17. The correct result, skipping the subject with no grades, is 4.75.

Zero isn’t a grade on a 1 to 6 scale, but it’s a perfectly valid double, so the program takes it without complaint. Anyone who can read return 0 sees the problem on the method’s first line. Anyone who can’t finds out when a parent asks where the bad mark came from.

An error message another prompt won’t fix

The Sonnet version is more honest, and on the same gradebook it stops the program. In the test program I put each method in a class named after its model. The subjects are maths, physics and chemistry in Polish, and I’ve trimmed the file paths:

matematyka: 5
fizyka: 4.5
Unhandled exception. System.ArgumentException: Lista ocen nie może być pusta. (Parameter 'oceny')
   at Sonnet.ObliczSrednia(List`1 oceny) in Program.cs:line 34
   at Program.<Main>$(String[] args) in Program.cs:line 17

The message (“the grade list can’t be empty”) is clear, and it still doesn’t tell you what to do. The exception isn’t a bug in the method. It’s a guard doing its job, and the actual bug is on line 17, in the code that called it. I walked through the same way of reading a stack trace for a NullReferenceException that points at the wrong line.

So I did what most beginners do. I pasted that stack trace into both models with “the program crashes, fix it”.

Neither fixed anything. Both correctly pointed at line 17 and both answered with a menu. Sonnet asked outright what should happen when there are no grades and wanted to see the rest of the file. Haiku offered three options, and the second one read:

if (oceny == null || oceny.Count == 0)
    return 0; // lub double.NaN

That’s the exact bug we started with. Pick from that menu without reading the code and there’s a real chance you land back on 3.17 and call it fixed, because the exception went away.

Whether a subject with no grades gets skipped or shown as “no grades yet” isn’t something a model can decide for you. It depends on how the school works, not on C#.

Three questions to ask any generated method

Reading generated code doesn’t mean you could have written it from scratch. It means knowing where to look, and for this method three questions are enough. Each one catches one of the bugs above.

What happens when the input is empty? The first line of the Haiku method answers: it returns zero. To see why that’s wrong, you need to know that a zero in a gradebook isn’t a missing grade, it’s a grade, and that Average() over the subject averages will treat it like any other number.

What default is this code leaning on? Math.Round with two arguments has a third one you can’t see: how to round halves. It isn’t in the code because nobody passed it, which is exactly why you have to know it exists. Number formatting works the same way. The machine I ran this on uses the en-US culture and prints 4.2 with a dot; the same line under pl-PL prints 4,2.

What value can come out that shouldn’t? A double will hold 0, a negative number or NaN. A grade can only be 1 to 6. Models guess most often in that gap between what the type allows and what the domain allows.

None of this needs design patterns. It needs you to read every line and know what each call does, and you get that by writing similar methods yourself before you start ordering them.

What models get right, and where they slip

Plenty worked. Sonnet wrote a correct method and explained why it added AwayFromZero. I also asked both models, in English, to split a bill evenly between n people to the cent, and both got it right. They worked in whole cents and handed out the leftover cents one at a time. For 100 split three ways, the Sonnet method returns 33.34, 33.33 and 33.33, which adds up to exactly 100. Rounding each share naively gives 99.99. I ran both.

Models slip where the prompt leaves a gap and the code compiles however you fill it: rounding halves, empty input, time zones, number formatting. The model picks a default and usually keeps quiet about it.

Questions with one documented answer go the other way. Unprompted, Sonnet explained that .NET rounds 2.25 down to 2.2 by default, and it was right. While you’re learning, that’s the best use of a model: write the method yourself, and when the result surprises you, ask why Math.Round behaves that way. You get the explanation and keep code you understand.

Professionals feel the same slip. In the 2025 Stack Overflow Developer Survey, 66% of developers named “AI solutions that are almost right, but not quite” as their top frustration, and more of them distrust the accuracy of these tools (46%) than trust it (33%).

METR’s study, published on 10 July 2025, is less comfortable still. Sixteen experienced open-source developers worked on issues in their own repositories, some with AI tools and some without. With AI they took 19% longer, and afterwards they still believed AI had sped them up by 20% (METR’s write-up). The authors say plainly that it’s a narrow sample and doesn’t speak for most developers. The safe conclusion is a modest one: experienced people misjudge how much time they’re saving.

There’s a shorter version of the general case, five arguments, in the AI section on the home page. The gradebook measurement backs the second of them: generated code breaks, and understanding is what gets you out.

Who shouldn’t bother learning to code

If you need a script that renames the photos in a folder once, or reshapes a single CSV for your own use, a model is enough. You can check the result by eye, a mistake costs you a minute, and you throw the code away afterwards.

It also won’t pay off if you’re hoping AI makes learning shorter. It’ll find you an explanation faster, but the model in your head gets built by writing and reading code yourself, and no tool speeds that part up.

That leaves people who want to be paid for code. Then you’re the one answering for a 3.17 to someone who doesn’t care that a model wrote it, and is learning to code still worth it has a plain answer: yes, and you start by reading. To work out how many hours a week you really have for it, start with a career-change plan built around a real week.