Should You Still Learn to Code? Wrong Question.

Someone asked on X whether learning to code from scratch is still worth it. The replies split the way they always do. One camp said yes, fundamentals matter, you have to understand what the machine is doing. The other camp said no, the model writes it now, learn to prompt.

Both camps are answering a question that has stopped meaning anything.

“Learn to code from scratch” assumes that coding is a body of knowledge you acquire before you are allowed to make something. Learn the language, learn the standard library, learn the framework, then build. That is how bootcamps sell it and how universities schedule it. In twenty-some years of hiring and building, I have not watched it work that way for anyone who got good, and it works even less now that the syntax costs nothing.

The real question is different and older. Can you build something real, today, with the tools that exist, and are you curious enough to keep doing it after the first one works?

The question underneath “should you still learn to code”

Strip the software out of the question and you get this: do I need to know how the thing works before I am allowed to make the thing?

That question is older than computers. Every apprentice has asked some version of it, usually while being handed a broom instead of a chisel, and every craft that produced masters answered it the same way.

What makes it urgent now is that the model writes the syntax. The person asking “should I still learn to code” is really asking whether there is anything left for them to learn. There is plenty, and none of it was ever the syntax.

What Aristotle said about builders

In the second book of the Nicomachean Ethics, Aristotle wrote that the things we have to learn before we can do them, we learn by doing them. People become builders by building and lyre-players by playing the lyre. Courage works the same way in his account. You are born able to receive it, and the habit of doing frightening things badly is what finishes the job.

That is how every craft ran for two thousand years. Nobody learned carpentry from a book and then touched wood. You swept the shop, then you held the board, then you cut the board wrong, then the master showed you why, then you cut it again. The knowledge arrived as scar tissue from things you had made.

Software borrowed the university model instead. Theory first, then practice. Data structures in the fall, algorithms in the spring, an internship if you were lucky. It produced two generations of engineers who could explain a linked list on a whiteboard and could not ship a login page. I hired some of them, and I was one of them for a while.

The people I have watched get good, including the version of me that finally did, all followed Aristotle’s path whether they knew it or not. They wanted something to exist, so they built it with whatever they had. They hit a wall, learned exactly what the wall required and nothing else, and then went and built the next thing. Ask any of them where their fundamentals came from and they will tell you about a project, not a course.

How the question went wrong

The “learn from scratch” camp gets three things wrong.

The first is that they think syntax is the skill. It was always the cheapest part of the job. A language is a few hundred rules and a standard library you look up. Now it costs nothing. A model will write correct syntax in any language you name, and the person who spent a year memorizing it is competing with an afternoon.

The second is that they think you must understand the full stack before you touch it. Nobody who ships has ever waited for that. Every significant leap in software came from engineers using abstractions they did not fully understand. We built web apps before we could explain TCP. We used frameworks before we could write one. Somewhere there is a systems programmer who genuinely understands every layer beneath them, and they got there by shipping for thirty years, not by waiting.

The third is that they hear “skip the curriculum” and assume the alternative is vibing it. The alternative I am describing is building with the model, reading what it built, and asking why until you know.

The “you don’t need to learn anything” camp gets one thing wrong, and it is a big one. They think the model replaces the need to understand what is possible, which falls apart the first time the work gets specific. Someone who cannot tell a queue from a cron job cannot direct an agent to build either one, and cannot tell when it built the wrong one. Someone who does not know what a database index is for will watch the model add one, or not add one, and have no opinion. The model will happily build a request path that should have been a nightly batch, and the person who does not know the difference will ship it.

What you actually need is architectural understanding, by which I mean knowing what a system can be made to do and what each shape of it costs. What a database is for. Why a request path is different from a batch job. What it costs to hold state and where you hold it. Where the money moves and what has to be true about that path. How things fail. My estimate from watching people learn it is a few weeks of curiosity rather than four years, and it arrives fastest from building something and hitting the wall that requires it.

Tradeoffs are the part nobody can teach you in advance. You will not learn why caching exists from a lecture on caching. You will learn it the day your page takes nine seconds. You will not learn why idempotency matters from a definition. You will learn it the day a retry charges a customer twice. A lecture can hand you the word, and then you carry the word around for years without knowing what it weighs.

What curiosity plus reps actually looks like

The scarce skill now is genuine curiosity plus reps building real things. Curiosity is what makes you read the code the model wrote instead of just running it. Reps are what turn “I read it” into “I know why.”

Treat curiosity as a practice, not a personality trait you either got or missed. In the work it comes down to asking one more question than you feel like asking, when the thing already runs and you could close the laptop. Anybody can do that on a Tuesday when they are tired, which is the only reason this essay applies to everyone and not just to the naturally nosy.

There is a tension here worth naming. I said memorized syntax does not transfer, and now I am telling you to read every diff, which sounds like it requires the syntax knowledge I just called worthless. Reading code is a different skill from recalling it. You are reading for intent and consequence, what this is trying to do and what it will cost, and you build that by reading real diffs on your own project with the model answering questions, not by memorizing a grammar first.

Here is what that looks like at my desk. I build with Claude and Cursor all day. I read the diff before I run it. When the model does something I would not have done, I ask it why, and I ask for the alternative and the tradeoff. Then I run the thing, and then I try to break it. That loop, a few hundred times, is the whole curriculum. I have learned more about how systems fail from reading agent diffs and asking questions than from any book on my shelf, because every question was attached to a thing I wanted to work.

Some of the old “learn to code” path transfers, and some of it does not.

What transfers: reading code, breaking a problem into pieces small enough to build, knowing what data structures cost, knowing how systems fail and where, and asking a precise question. Those were always the job, and they are more of the job now, because the model makes the other parts free.

What does not transfer: memorized syntax, framework trivia, the ability to recite internals under interview pressure, and the four-year sequence that insisted on theory before the first build. Those were always the tuition rather than the skill, and the tuition has dropped to roughly zero.

For a beginner in 2026 the honest version is short. Pick something you want to exist. Build it with the model today, not after a course. When it breaks, ask why until you understand. Then build the next one. You will know more architecture in three months of that than in a year of a curriculum, because every piece of it will be attached to something you made.

For the senior engineer worried about juniors who never “learned to code,” stop trying to predict which kind you hired and watch for the one thing you can actually see. Do they read the diff and ask about it, or do they accept and run? That behavior is visible in a week, it tells you more than their coursework does, and it is the thing you can coach. If you want to be sure, hand them a drill with a date on it, and then give the tool back. Do not take it away.

Code got cheap and building did not. The judgment about what should exist is still the expensive part, and studying does not produce it. You get that judgment from building a few things that should not have existed and then being honest with yourself about why nobody used them.

The practice

Five things, this week, no course required.

1. Build one real thing. Something you want, not a tutorial. A script that does a chore you hate, a page that tracks something you care about, a bot for a group you are in. Use the model from the first line.

2. Read every diff before you run it, and ask why. “Why this way?” “What is the alternative?” “What does this cost at ten times the traffic?” The model will answer, and the answers are the course.

3. When it breaks, do not paste the error and move on. Ask what the error means, then ask what the fix costs, and then decide. The moment you understand an error before the model explains it, you have learned something that transfers.

4. Keep a list of the words you did not understand. Queue. Index. Migration. Idempotent. Race condition. Learn each one the day you hit it, from the thing you are building. A word you meet because your own code forced it on you tends to stay for good, while the same word from a glossary evaporates by Thursday.

5. Ship it to one person. A friend, a coworker, a stranger on a forum. Their first complaint is the next thing you need to learn, and it will be more specific than any syllabus.

Scale that down as far as you need to. An hour a week on a borrowed machine runs the same loop as my whole Saturday. The loop is the obligation, not the subscription or the free weekends.

Every person I have watched do that for three months has come out the other side unable to take the original question seriously, because they were already building. Worth saying plainly, though: shipping ten working things is the evidence that you understood something, and not the same as understanding it. The build is the occasion. What you are after is knowing why it worked.

Final Thoughts

The question “should I still learn to code” has always had the same answer, and Aristotle gave it before there was code to learn. You learn to build by building. The knowledge arrives from the thing you made, in the order the thing required it.

What changed is the price of the first build. It used to cost a semester or a bootcamp before you could make anything that ran. Now it costs an afternoon and a model. The syntax is free, the scaffolding is free, and the only thing the model cannot supply is the curiosity to read what it wrote and ask why.

Curiosity was always the scarce part, and it has quietly become most of the job.

FAQ

Should you still learn to code in 2026?

Not the way the question means it. Learning to code from scratch, meaning acquiring the language and its idioms before you are allowed to build, was never how anyone got good, and now the syntax costs nothing. Build something real this week with a model, read every line it writes, ask it why, and learn each concept the day the thing you are building forces you to. Three months of that produces more working understanding than a year of a curriculum.

Do you need to understand the fundamentals before using AI to write code?

No, and nobody ever did. Every generation of engineers built on abstractions they did not fully understand, from TCP to frameworks to cloud services. What you need is enough architectural understanding to know what is possible and to direct the work: what a database is for, why a request path differs from a batch job, what it costs to hold state, where the money moves. That is a few weeks of curiosity, and it arrives fastest from building something and hitting the wall that requires it.

What should a beginner learn first if AI writes the code?

Pick something you want to exist, build it with the model today, and read every diff before you run it. Keep a list of the words you did not understand and learn each one from the thing you are building, the day you hit it. When it breaks, ask what the error means and what the fix costs before you paste it back. Ship it to one person. The feedback is the next thing to learn.

What did Aristotle say about learning a skill?

In Book II of the Nicomachean Ethics, Aristotle wrote that the things we have to learn before we can do them, we learn by doing them: people become builders by building and lyre-players by playing the lyre. Skill is acquired through repeated practice under correction, not by studying the skill before attempting it. Applied to software, you learn to build by building, and the model has made the first build cheap enough that there is no reason to wait.

If you want a room full of people who build with the model every day and still read every diff, MasteryLab is where that practice happens.