If AI writes all the code, someone still has to read it.

Grant the premise

In his July 2026 interview with The Economist, Elon Musk put it about as bluntly as it can be put:

"For software engineering, we already have a situation where AI is better than at least 90% of humans at writing software. And it really is getting to the point where it'll be better than 99%. And then it'll get to the point where there's just no way to compete. It'll get to what I call Stockfish level." — Elon Musk, interview with The Economist, 23 July 2026¹

Grant all of it. Assume he is right, and early. Assume that within a few years no human writes production code by hand for any reason other than pleasure.

That changes who types. It does not change who has to ask for the thing, judge whether the thing is right, and answer for it when it is not.

The two jobs that never left

The ask. A model produces what you requested, and only approximately that. The difference between a system that works and one that quietly does the wrong thing is almost always in the request: an unstated constraint, a case nobody named, a word that meant one thing to you and another to the model. Writing a good ask requires knowing what is being built well enough to describe its edges. That is a literacy problem, not a typing problem.

The judgment. Something has to decide whether the output is acceptable — correct, safe, maintainable, honest about its own limits. If the same class of system that wrote the code is also the only thing evaluating it, there is no independent check anywhere in the loop. A human who cannot read the output cannot supply one.

Machines got better at producing code. Nothing got better at deciding whether the code deserves to run.

Literacy is not typing

Coding literacy used to mean you could write the loop. It now means something both broader and more useful:

• Vocabulary. You know what a dependency, an environment variable, a migration, a build, a test, an API key, and a diff actually are — so you can say what you want precisely, and understand what came back.
• Capabilities. You know roughly what software can and cannot do, so you neither ask for the impossible nor settle for far less than what is available.
• Process. You know that software is written, reviewed, tested, deployed, and broken — in that order, repeatedly — and that "it ran once on my screen" is not the same as "it works."
• Possibility. You know enough of the shape of the field to recognise that the thing in your head is buildable, and to say so out loud. Most software that should exist never gets requested.

None of that requires you to write the loop. All of it requires you to be able to read one.

The alternative is a screen you cannot audit

Here is the failure mode worth naming now, while it is still avoidable. If nobody reads the code, we do not get software — we get renders. Interactive pictures of a system, produced by a process no one on the receiving end can open.

Every question that actually matters then becomes unanswerable in principle:

• Where did this number come from?
• What does this do with my data, and where does it send it?
• Why did it stop working this morning?
• What is it doing when nobody is asking it anything?

Someone who cannot read the software they commissioned is not empowered by it. They are a customer of something no one on their side of the transaction can open — and that is a worse position than not having it, because it comes with the confidence of ownership.

So the studio ships an editor and a console

Not because you have to write it. Because you have to be able to open it, run it, and watch it fail.

This is also why the studio does not hide the machinery behind a single "make it for me" button. A button like that optimises for the first five minutes and costs you every minute after. The version that respects your time is the one that lets you look.

The same argument as the pipeline

The companion piece to this one argues that education is a mechanism — lecture, seminar, group project, essay, test — and that AI belongs in the harness around it rather than in any of its chairs. Coding literacy is the same argument aimed at one subject.

The test stage of that pipeline was never about whether you could produce the artifact. It was about whether you understood it well enough to defend it alone. Handing a student a program they cannot read is handing them a finished essay: it clears the assignment and skips the development the assignment existed to produce.

Tokens are energy, not intelligence. So is generated code. The intelligence is still the person who can tell whether it is any good.

AI writing all the code does not make software literacy obsolete. It makes it the only part of the job left, which is a strange way of saying it has never mattered more.