Do We Still Need to Learn to Code?

When GPT-6 Astra came out in early September, I scrolled past a lot of demos, and they were genuinely a bit much. The old version of "AI writes code" was completing a function, explaining an error message, or generating a snippet from a spec. That's not what it looks like anymore. Now it reads the project on its own, rewrites a dozen files, runs the tests, and keeps revising based on the results. Work that would have cost a programmer days of grinding now gets a long way done on a single sentence of instructions.

After seeing all of that, one question follows naturally: do we still need to learn to program? Do we still need to spend a lot of time practicing writing code by hand?

This question is a complicated one for me.

This Isn't a Question I Can Ask From the Sidelines

I've been writing code for a long time, and I've built a lot of projects. Earlier in my career I did programming education: Scratch for kids, Python and C++, and courses that mixed software with hardware — Arduino, drones. I published a beginner's C++ book for readers starting from zero, and produced a lot of programming-learning courses and material. There's a Python programming exercise project on my GitHub that still has close to thirty thousand stars.

So when I ask myself again today whether "we still need to learn to program in the AI era," this isn't a question I get to ask from the sidelines. In some ways it's me looking again at something I've believed for the past decade and spent that same decade teaching to other people.

What Programming Actually Teaches

When we taught kids — and adults — to program, of course we taught syntax, variables, loops, and functions. But I never thought those were the most important part. What really matters is the thinking behind programming: how to break one big problem into small ones, how to turn a vague requirement into explicit steps, how to find errors, how to verify your own judgment.

Go further and build a real software project, and you discover that having a "programming mindset" isn't enough on its own — you need the methods of software engineering. There's a classic paper in that field, Fred Brooks's No Silver Bullet. Its argument is actually very plain: no miracle technology can make the complexity of software disappear in one stroke. Since then we've had better languages, frameworks, and tools, plus engineering methods like agile — but none of them is a silver bullet.

I've genuinely used agile on my own projects too. Break the big requirement into small pieces, iterate in short cycles, look at the results when you're done, then adjust the next step. Looking back, I don't think those methods really train a particular process. They train a habit for facing complex systems: don't expect to get everything right in one pass — decompose, get feedback, verify, correct.

The question now is: once AI can write a large amount of code on our behalf, is any of that training still necessary?

Even Karpathy Barely Types Code Anymore

Let me start with someone I think is highly representative: Andrej Karpathy. Not every reader will know him. Karpathy was one of the founding members of OpenAI, later ran AI at Tesla, and as a PhD student at Stanford he designed and taught the famous CS231n deep learning course. He's both a strong AI researcher and a very typical "roll up your sleeves and build things yourself" programmer.

In 2025 he proposed a term that would later go viral: vibe coding. The gist is that you stop staring at every line of code. You just tell the AI what you want, look at the result, then keep talking and keep revising. This past March, he even said in an interview that he had barely written any code by hand for months.

If even someone like Karpathy is writing less and less code by hand, then "does manual programming still matter" is clearly not a question crying wolf.

A Recent Example: Second Brain Graph

My own experience is pretty much the same. Lately I've been working on a few small projects, and the share of the code AI writes for me is already extremely high. Many times I don't even look up a framework's documentation first — I just tell Codex or Claude Code what I want, let it implement it, and then look at the result.

Take Second Brain Graph, which I built recently. The project isn't a from-scratch attempt at building a "second brain." What it actually is: a visualization and interaction interface for LLM-Wiki inside Hermes Agent. LLM-Wiki itself organizes knowledge accumulated over the long run into a Markdown wiki with cross-links. What I wanted was to draw those nodes and relationships directly, browse them on a 2D or 3D graph, and also click a node and carry that node's context into the conversation with Hermes Agent.

By lines of code, a project like this really is fast today with AI doing the work. React pages, a Three.js graph, a Node.js backend, the interfaces, real-time sync, even the deployment scripts — AI can help with all of it.

But when you're actually building it, what I spend my time thinking about is often not how some line of JavaScript should be written. For example: how should the relationships in the wiki map onto the graph? What exactly does clicking into a node show? How much context should come along when I'm talking to Hermes? Should the wiki itself be read-only, or should the front end be allowed to modify it directly? In what form does new content produced by a chat get written back into the wiki? And is this thing, from here on, just a small tool for my own use, or can it become a standalone product?

AI can discuss all of these things with me, and the advice it gives is often good too. But in the end, how you trade off is still my decision to make.

So the feeling that keeps getting stronger for me is this: AI saved me a huge amount of "writing code" time, but it didn't save me any "thinking it through" time. More often than not, the second one is taking up a larger share, not a smaller one.

From "Prompting Is Enough" to Harness Engineering

Over the past year or two, AI-assisted programming has also started moving quickly away from the early idea that "knowing how to prompt is enough," and toward engineering. People stopped staring only at the model itself and started discussing the entire set of things around the model. One term I've been hearing a lot lately is the harness, or harness engineering: how to supply context, how to define rules, how to expose tools, how to break down tasks, how to run tests, how to recover after a failure, and how to keep an agent from making the same mistake over and over.

Projects of this kind have been especially numerous on GitHub over the past year or so. For example, GitHub's own Spec Kit insists on writing the spec clearly first, and only then letting the agent implement it; Garry Tan's gstack turns the roles and processes of product, architecture, code review, QA, and release into a set of directly callable skills; and Superpowers repackages things that software teams have known well for years — requirements clarification, planning, TDD, review, verification — into workflows an AI coding agent can execute. Add AGENTS.md and the various skills, and underneath it's all the same thing being done: you can't just give the AI one sentence and then pray it keeps getting it right.

What I find is that when I see all this, it's actually rather interesting. We've gone all the way around the circle, and it looks like we've arrived back at software engineering.

In the past, the problem was that human-written code tends to get out of control, so we needed requirements, design, standards, tests, code review, continuous integration, and agile iteration. Now it becomes agent-written code that tends to get out of control, so once again we write specs, we write AGENTS.md, we build skills, we design harnesses, we add tests, add reviews, add feedback loops.

The tooling has changed completely, but the problem we actually have to solve hasn't changed. Fred Brooks said back then that there's "no silver bullet," and that still seems to hold in the AI era. Large language models are enormously powerful, but an LLM is not a silver bullet either.

Which is why I don't support simply saying: "AI writes code now, so there's no need to learn programming anymore."

But I don't support the opposite claim either: that because the programming mindset is important, developers should still grind through syntax, API, and framework details exactly as they did ten years ago, and write every bit of code by hand if at all possible. AI has changed the tooling, and there's no need to pretend that nothing happened.

What's Depreciating, What's Appreciating

A lot of problems that used to have to be solved by memory and familiarity really are losing their value. How the parameters of an API are written, what a CSS property is called, which file a framework keeps some configuration in — these things are increasingly not worth spending large amounts of time memorizing.

What genuinely needs to be discussed again is why, exactly, we learn to program.

If learning to program is only about memorizing Python's syntax, or about being able to hand-write a sorting algorithm without looking anything up, then its value really is declining fast.

But if learning to program is about training something else — breaking complex problems apart, saying a vague problem clearly, building abstractions, understanding the boundaries of a system, finding errors, and verifying results — then I actually think those capabilities matter more in the AI era.

If It Runs, Is It Done?

Because in the past, when a program was wrong, it would often just throw an error. The most troublesome thing about what AI gives you now isn't that it completely fails to do the task — it's that it produces something that "looks pretty right." The page shows up, maybe a few tests pass, the demo runs, and it's very easy to conclude that the job is finished.

Without enough judgment, it's very easy to stop right there: if it runs, that counts as done.

But people who've actually done projects tend to keep asking: why is it designed this way? Can this structure still be maintained later? Has something here coupled together two things that should have stayed separate? What happens in the abnormal cases? Where's the security boundary? What do the tests actually cover? If the data volume becomes a hundred times what it is now, will it still run?

These questions don't necessarily require you to go change every line of code yourself. AI can absolutely keep fixing things for you. But you at least need to know what to ask, and you need to be able to judge whether the answer it hands you is any good.

If I Redesigned the Curriculum Today

So, if you asked me to design a programming course or a developer training program today, I probably wouldn't do it the old way. Manual programming should still be taught, but it wouldn't take up such a large share. I'd get learners onto AI much earlier, while also requiring them to read what the AI did, explain why it did it that way, modify it, write tests for it, deliberately break things, and then fix them back.

I might even treat writing specs, breaking down tasks, designing tests, reviewing code, and debugging a system that AI wrote as the new fundamentals.

Because what will really open up the gap in the future may no longer be who can type out a hundred lines of code faster.

But who can think about the problem more clearly, who can drive AI better, and who can know where it went wrong when AI gets it wrong.

AI made writing code easier and easier, but it never made thinking redundant.

Perhaps the question we should really be asking is no longer "do we still need to learn to program in the AI era," but this: now that code is getting cheaper, which capabilities are still worth deliberately training?

---

Some Recent Reading

[1] OpenAI: official GPT-6 Astra announcement (2026-09-03) https://openai.com/index/gpt-6-astra/

[2] Andrej Karpathy personal site / bio https://karpathy.ai/

[3] Andrej Karpathy: the original vibe coding post (2025-02) https://x.com/karpathy/status/1886192184808149383

[4] Andrej Karpathy: No Priors podcast interview (2026-03) https://www.youtube.com/watch?v=kwSVtQ7dziU

[5] Fortune: OpenAI cofounder says he hasn't written a line of code in months (2026-03-21) https://fortune.com/2026/03/21/andrej-karpathy-openai-cofounder-ai-agents-coding-state-of-psychosis-openclaw/

[6] Fred Brooks: No Silver Bullet: Essence and Accidents of Software Engineering (IEEE Computer, 1987)

[7] Hermes Agent: LLM-Wiki Skill https://github.com/NousResearch/hermes-agent/tree/main/skills/research/llm-wiki

[8] Second Brain Graph https://github.com/zhiwehu/second-brain-graph

[9] GitHub: Spec Kit https://github.com/github/spec-kit

[10] gstack https://github.com/garrytan/gstack

[11] Superpowers https://github.com/obra/superpowers