Let me start where I always start, because the frame matters more than the answer. This is the same challenge we face with education as a whole. You already know you have to change it. Everyone knows. The difficulty was never whether to change it — it is changing it well. Reforms fail not because people resist change but because they change the wrong thing, drop what was load-bearing, and keep what was decorative. So before we decide whether to cut coding from the curriculum, we should be very clear about what coding was actually teaching. Because it was never really teaching “coding.”
Coding is the new mathematics
The relevance of coding today is like the relevance of mathematics. And I say mathematics deliberately — to sidestep the harder, noisier argument about the relevance of chemistry, or of the other sciences — because with math almost everyone already accepts the point. We do not teach children arithmetic because we expect them to spend their adult lives doing long division by hand. We have had calculators for fifty years. We teach it because it builds something underneath: number sense, structured reasoning, the ability to move from a messy real situation to an abstract model and back again.
Coding is the same. The value was never the syntax. It was the foundation — the structured thinking and the process thinking. It is learning to decompose a problem into steps, to name and track state, to reason about what happens under which condition, to build something that behaves predictably out of parts that individually do very little. That is not a programming skill. That is a thinking skill that programming happens to teach unusually well.
So when someone asks “will AI make coding obsolete the way calculators made arithmetic obsolete?”, my answer is: notice that calculators did not make arithmetic obsolete. They made the manual computation optional and the underlying understanding more important, not less — because now the person who understands the model, and not just the button, is the one who can tell when the answer is wrong.
What actually endures
If the syntax is not the point, what is? When I strip it all the way down, what endures sits on three axes:
- Technically — the ability to generate specifications. To say precisely what a thing should do: its inputs, its outputs, its states, its rules, its edge cases. An AI will build almost anything you can specify well. It will build nonsense, beautifully, from a specification that is vague.
- Creatively — the ability to visualize and imagine. To see the thing that does not yet exist, to hold it in your head, to picture how it behaves before a single line is written.
- Productively — the ability to structure, articulate, and interconnect. To take ideas, concepts, and functionalities and organize them into something coherent — to see how the pieces relate and where they connect.
Look at that list again and notice something: none of those three is a coding skill, and all three are exactly what you cannot delegate to an AI. The machine is now extraordinary at producing the code. It is still entirely dependent on a human who can specify, imagine, and structure. That is the part worth teaching. That is the part worth protecting.
A personal proof I keep returning to
Let me make this concrete with my own life, because it is the clearest evidence I have. I am still, today, surprising myself and shipping real things with the coding skills I taught myself at nine years old on a Texas Instruments TI-99/4A, and then deepened at fourteen in a couple of courses at IBM — COBOL and databases on a System/34. Those two experiences marked my life. I never took another programming course. Not one. And I have delivered mission-critical systems and public-facing platforms, and supervised their development.
So there is clearly something there we should not neglect. When I ask myself what it was, the answer is always the same: it was the structure. The base — variables, routines, processes. Everything I built afterward was built on that foundation, laid before I was fifteen and never formally revisited.
Here is the tell. Over the decades I watched programming evolve through techniques and paradigms I never formally learned. But because I have the base, I can read and understand almost any code, in almost any language. I do not know how to program in Python — I have never learned it — but I can read Python and understand exactly what it is doing. The functions change, the structures change; the underlying logic is legible to anyone who has the foundation. That legibility, that transferability across languages and across forty years, is the thing school should be trying to install. It outlasts every specific technology it was taught through.
What I would actually teach
So, concretely: if the kids learn to make things in Scratch, that probably has them covered on the fundamentals — they meet procedures, data structures, variables, loops, conditions, sequencing. That is a real foundation. Then, depending on age, I would add the modeling and structuring vocabulary that turns a vague intention into something buildable:
- Flowcharts — which most curricula already introduce — to reason about process and control flow.
- Entity-Relationship and Object-Relationship diagrams — to think clearly about data and how things relate.
- Layered software architecture — to understand how a system separates concerns instead of becoming one undifferentiated mass.
- And for older students, an upgrade from flowcharts to BPMN (Business Process Model and Notation) — the same instinct, scaled up to real processes and organizations.
And then — this is the part that answers my friend’s actual question — I would teach them to execute what they have designed with vibe coding. Let the AI do the typing. Let the student do the thinking that tells the AI what to type. That is not a compromise; that is the correct division of labor for the era we are actually in. The design is the human’s. The execution is augmented. The judgment about whether the result is right stays, always, with the person who understands the structure underneath.
The trap: two vibes and nobody learning
But I would keep Scratch — and I want to be precise about why, because it is the crux of the whole question. I would keep it for Seymour Papert’s constructionist reason: children learn most durably by making — by building an external thing that they can look at, test, break, and fix. And I would keep it for a second reason that people forget: the hand, the eye, and the mind engaged together on the work. The physical and mental engagement is not incidental to the learning — in the early years, it may be the learning.
Because here is the failure mode we are walking straight into. If we are not careful, the student will “vibe” the conceptualization — gesture vaguely at what they want — and the AI will “vibe” the coding, and a finished artifact will appear on the screen. And it will look like success. And nobody will have learned anything. Two vibes, one artifact, zero foundation. That is not education; that is outsourcing with extra steps. The whole point of building the foundation is that it is the one thing that cannot be vibed into existence — it has to be constructed, by the learner, through the productive difficulty of actually making something.
Change it — but change it well
So my answer to my friend, and to every school and university and parent asking the same question this year, is not “keep coding” and it is not “drop coding.” It is: understand what coding was really teaching, keep that with everything you have, and change the delivery around it. Keep the making. Keep the structure. Keep the modeling vocabulary. Add the AI as the executor of well-specified, well-imagined, well-structured human intent. And never let the tool do the one part — the foundation — that only the learner can build for themselves.
You know you have to change it. The whole task is changing it well.
A working draft. This essay lays out my position; a forthcoming revision will weave in sourced research — the constructionism literature, computational-thinking scholarship, the origins of “vibe coding,” and the current cognitive-science evidence on learning and AI — with full citations. If you have work I should read before then, tell me. — Carlos Miranda Levy
Four perspectives
The strongest version of this argument is the transfer claim: that what coding instruction builds is a general structured-reasoning capacity that outlives any language. That claim is plausible and it is also exactly the kind of thing the research literature treats with caution, because transfer is notoriously hard to demonstrate. So the honest framing is the one Carlos uses — keep the making, because the making is where the evidence is strongest — rather than resting the whole case on a broad transfer claim that would need to be qualified. When the sourced revision lands, the computational-thinking and constructionism literature is where I would anchor it.
My concern is equity, and it cuts in an uncomfortable direction. ‘Let the AI write the code’ sounds liberating, but the students who will still learn the foundation are the ones in schools with teachers who understand the difference between designing and vibing. The students in under-resourced schools are the ones most likely to be handed the tool and told it is enough. If we are not deliberate, ‘AI writes the code’ becomes a mechanism for widening the gap while looking like access. The modeling vocabulary Carlos lists — flowcharts, ERDs, BPMN — is cheap to teach and hard to fake. That is exactly why it belongs in every school, not just the innovative ones.
Practically: keep Scratch for the young ones, add the diagrams as they grow, and yes — absolutely have them ship real things with AI. The mistake schools will make is banning the tool out of fear. The other mistake is handing it over with no structure. Do both at once: make them design it on paper or in a diagram first, then let them build it with AI, then make them explain why it works. The explanation step is the whole game. If they can explain why it works, they learned something. If they cannot, they vibed it, and you caught it.
I taught myself to code at nine and took my last programming course at fourteen, and I am still building on that foundation today. That is not nostalgia — it is evidence. What endured was never the language; it was the structure. So when a school asks me whether to keep teaching coding, I hear a different question underneath it: are we still going to teach children to think in structures, to specify precisely, to imagine and then organize what they imagined? The answer to that question must be yes, and it becomes more true, not less, as the machines get better at the typing. Change the curriculum. Just do not, in changing it, throw away the one thing worth keeping.