Why learn to code when the machine writes it for you?

Start with what is true

A model will write a working Flask endpoint faster than you can open the file. It will produce the pandas one-liner you half-remember, the regular expression you would have got wrong twice, and every line of boilerplate nobody has ever enjoyed typing. Anyone telling you otherwise is defending a business, not describing the tools.

So the question is not whether machines write code. They do, every day, including for the people who built this site. The question is what that leaves for the person sitting in front of it.

The cost of writing code collapsed. The cost of being wrong did not.

Picture a retry wrapper around a payment call. It looks right. It catches the timeout and tries again, which is what every article about resilient systems tells you to do. Now picture the timeout landing after the charge went through and before the response came back. The retry charges the customer twice. No test fails, no exception is printed, and it surfaces three days later as a refund request and an apology somebody has to write.

Nothing about generated code makes that class of bug rarer. If anything it makes it more common, because code that reads cleanly and arrives instantly gets less scrutiny than code you had to sweat over. The reviewer’s eye slides straight across it.

The work moved from writing to judging

You are the reviewer now, and the review is the job. That means looking at forty lines you did not write and being able to say, without running them:

• this loop is quadratic over a table that has four million rows today;
• this opens a file and never closes it, which is fine until it runs in a loop;
• this keeps money in a float, so the books will be off by a cent and nobody will know which cent;
• this catches every exception, including the one that mattered;
• this mutates the list the caller passed in, and the caller has no idea.

None of those are typing skills. They are reading skills — and reading is learned by writing. There is no route where you become a good judge of code you never had to make work yourself. That is the whole argument; the rest of this page is detail.

This has happened at every layer before

“Why learn to program when the compiler writes the machine code?” was a real question, asked seriously, by people who wrote assembly for a living. The compiler won. It did not make programmers redundant — it moved them up one floor, where the job became deciding what the program should do rather than which register held what.

The same thing happened with memory management, with web frameworks, with every library that replaced a fortnight of work with an import. Each layer removed a chore and raised the bar for whoever stood on top of it. A C programmer was never freed from understanding memory, only from typing the allocations. Expect this to have that shape.

What actually stays

Strip away the syntax, the frameworks and the year, and what survives is unglamorous:

• How data is shaped. Why a dictionary and not a list — and why the wrong shape makes every later step harder.
• State and mutation. Who is allowed to change this, and what else is holding a reference to it.
• What is expensive. Not micro-optimisation. Just knowing which line is the one that falls over when the data is a hundred times bigger.
• How failure travels. What the rest of the system does when this call never comes back.
• Reading a traceback. The highest-return hour a beginner can spend, and the one most courses skip. Ours does not — there are 45 errors written up, each with the code that causes it.
• Naming. Sounds trivial. It is how you find the bug six months later.

Every one of those is a decision about your problem, taken with context a model does not have. Which is exactly why they cannot be handed over.

Where models are weakest is where your value is

A model is strongest on code that exists ten thousand times in public repositories: the login form, the CRUD endpoint, the bar chart. It is weakest on the thing nobody has written before — your employer’s strange data, your lab’s instrument format, the one rule your field has that no framework models and no tutorial mentions.

That is also, and not by coincidence, the only code anyone has ever been paid well to write.

Why Python in particular

Because the syntax gets out of the way fastest. Your attention goes to the ideas above instead of to semicolons and type declarations, and the same language then carries you into data analysis, machine learning, automation and the web without starting over. Here it also runs in the browser, which matters more than it sounds: you can train a small neural network on 1,347 real handwritten digits in under a second, in a tab, with no framework at all. Understanding comes much faster when an experiment costs nothing to run.

What we will not claim

• That this gets you a job. The market for “can produce the boilerplate on request” has genuinely narrowed, and it was always the weakest reason to learn. What has not narrowed is the market for people who can be trusted with a system.
• That AI coding is a fad. It is not. Learn to use it — it is a faster first draft than anything that came before.
• That you should type everything by hand. Use the model. Then read what it handed you, carefully, and be the person in the room who can tell whether it is right. That is the skill, and it is the one this site teaches.

And the reason that has nothing to do with work

There is a spreadsheet somewhere in your life that should be doing something it cannot do. Two hundred photographs with the wrong names. A page worth checking every morning that you check by hand. Programming is what turns each of those from a chore you live with into twenty lines you write once.

It is the difference between being handed a tool and being able to make one — and now, between being handed an answer and being able to tell whether it is true.