Why should we learn any more about programming? An answer.
This will be a two-part answer. The parts are:
Vibe-coded apps (ie. with no oversight by someone who understands the code) have ceilings. This can be a ceiling in lines of code, in userbase scaling (ie. running for thousands of users instead of one), and in security, just to name a few. If an app will hit any of these ceilings (ie. if it's made public), then will need to be properly engineered, not just vibe-coded.
The point above, while a pre-requisite for making sense of the following point, is not the point of this article, and has been well-covered by others. Thus, should you not be certain of this, I'd recommend some of the following; the first two will probably cover most of it.
Having cleared that up, let us on with the main point.
Having confirmed the need for (AI-assisted) software engineering (not just vibe-coding) for some use cases, let's look at the popular story about the future of software: AI agents will write almost all of the code, and humans will mostly review tickets, approve designs, and fix the awkward bits.
If that future arrives, a natural question follows: why bother improving programming languages at all? And a second, sharper one: why should humans still learn new programming structures (id est tree and table operators and transformers) — if they won't be typing most of the code?
This article argues that both still matter, and that they matter more when AI is doing the bulk of the typing.
AI does not invent a programming language for each task. It writes in the language you give it — with that language's abstractions, gaps, and sharp edges. If the language makes a common job clumsy, the AI will produce clumsy code for that job, at industrial scale.
That matters for several reasons:
So improving languages is not nostalgia for hand-written code. It is improving the medium in which both humans and AIs express programs. Better mediums produce better programs, whoever types them.
Before widespread AI coding, a weak abstraction mostly hurt the people who wrote that corner of the system. With AI, a weak abstraction gets copied into every ticket that touches the same kind of problem. The model has seen millions of examples of "how we usually do JSON in language X", and it will cheerfully reproduce the usual mess.
Conversely, when a language has a clear, learnable way to say "fetch this, parse it, select these nodes, join with that table, write the result there", an AI can emit that pipeline instead of reinventing five helper functions. The training data will eventually include those patterns — but only if the language community builds and uses them first.
Language improvement is therefore leverage. You improve one operator, one grammar, one tree model — and every agent that writes in that language inherits the improvement.
Even in an AI-heavy workflow, humans keep the hard jobs:
None of those jobs go away when the Code Monkey agent writes the fifty-line function. They get more important, because the volume of candidate code goes up.
You cannot review well what you cannot recognise. If you do not know that trees and tables have better operators than nested for loops and hand-rolled path strings, you will approve the loops. If you do not know a join belongs in the query, you will accept three nested maps that almost work.
Learning new programming structures is how you keep the ability to say "no, rewrite that with the right tool", instead of not even recognising that the tool is wrong.
Are there new programming structures? Occasionally, yes; XSLT/XPath were a new paradigm for navigating trees (tree-oriented programming), and one that's becoming more popular (ie. the jq tool does for JSON what XPath did for XML). Other times, paradigms are old, but the structures become ossified over time; an example is that table-oriented programming (dating back to the 50s) became simplified and ossified into SQL and the various spreadsheet languages, which were maybe not as good as things like dBase/xHarbour/FoxPro at handling tables, but which were good enough; The good is the enemy of the great.
Will introducing these two ideas into the same programming language as first-class syntax (called "Data-Oriented Programming") be an improvement? I think so, but only time will tell. There will also no doubt be improvements that others will discover; for example, maybe integrating Logic Programming as first-class syntax in a traditional language will be amazing. Or more likely, something of which none of us have yet thought.
The point is, there will likely be good and useful higher-level structures that will save time and improve communication.
Why should a human learn something like that in an age of AI?
If the human (or the architect agent) can specify "use a tree query pipeline", the coding agent has a crisp target. Without that vocabulary, "process this JSON" becomes whatever imperative style was most common in the training set. Teaching humans the structure is how the structure enters prompts, tickets, and reviews.
One language for many shapes of data means less to remember when you are checking AI output. You are not switching between "the JSON library idiom", "the XML library idiom", and "the filesystem walker idiom". You are checking whether the axes and operators match the data. That is a smaller, sharper skill — one checklist you can apply under time pressure, instead of re-learning five library idioms on every pull request. When review queues grow and deadlines tighten, broad vague familiarity is not enough; a focused skill you can apply reliably is what keeps bad code from shipping.
People ask for what they can imagine. If your mental toolbox stops at objects and loops, you will ask AI for objects and loops. If you know tree transformation and relational joins as first-class ideas, you will ask for those — and you will notice when the model fails to use them. Learning Data-Oriented Programming (and writing in a language that supports it) expands the set of programs you can usefully demand.
AI is excellent at remixing what already exists. It is much weaker at inventing a coherent new abstraction and proving it across formats. That work — designing operators, deciding what a tree edge means, integrating the idea into a language — remains human-led for the foreseeable future. Data-Oriented Programming for Raku is being designed because someone (me) decided tree/table handling in Raku needed to be better, not because a model spontaneously shipped a new paradigm.
If we are going to improve languages and teach better structures, it helps to start from a language that already has a lot of them. Raku's design goal is to include most of the good features of other languages — objects, functional idioms, concurrency, grammars, gradual typing, and more — organised as one coherent system rather than bolted on as libraries. That makes it a strong candidate for language learners: you can grow into new paradigms without changing languages every time (see also Raku: Your Forever Language).
It is also a useful baseline for language designers. Since it supports grammars and slangs, it allows modification of almost any part of the programming language via modules -- new operators, new syntax, and the like. This means that, when you want to try a new structure, you are not rebuilding ordinary programming from scratch first. You start from a high floor of existing capability, and the experiment is whether the new idea improves on that floor.
To summarise:
If AI writes most of the lines, the scarce resource is not keystrokes. It is judgement about structure. Programming languages and the structures they allow and teach are how we store and transmit that judgement.
AI coding does not make language design obsolete. It makes language design and human fluency in better structures into some of the main leverage points we have left in getting the largest amount of functionality into the fewest programming language tokens, reducing the time required for human review (whether reviewing AI code or the code of others), and improving productivity.