There Will Be More Programmers, Not Fewer

AI won't reduce the number of programmers. It will create millions more, because running code you cannot understand is not programming. It is faith.

Part I — The Hypothesis

The Democratization Arc, and What It Actually Produced.

The prevailing narrative about AI and programming runs like this: LLMs will automate code generation, the demand for programmers will collapse, and the skills that once commanded premium salaries will be absorbed into the machine. It is a story about subtraction. Fewer specialists needed. Profession hollowed out. This essay argues the opposite, and draws the evidence from the history of writing, following the analogy to its actual conclusion.

Writing, as a technology, has democratized over roughly five thousand years. The arc moves from scribes to the printing press to the word processor to the blog. At each stage, the barriers to producing written text fell. At each stage, conventional wisdom might have predicted that "writing jobs" would be lost. At each stage, the opposite happened. More people wrote. More people read. The population of writers expanded at every level of craft.

But the expansion was not homogeneous. More writers did not mean all writers were the same. It meant the spectrum lengthened at both ends and filled in the middle.

Consider two documents from the ancient world, separated by everything except the fact that both are writing. The first is a letter written around the second century AD by a Roman marine named Apion to his father Epimachos back in Egypt.¹ Apion had survived a storm at sea, arrived safely at the port of Misenum, and wanted his father to know. The letter is functional, warm, slightly clumsy. It is the WhatsApp message of its era, a man, far from home, reaching across distance to say: I am alive. I am well. I have not forgotten you. Apion was not a literary figure. He was a soldier. He dictated his meaning to a public letter-writer, as most people did, but the meaning was entirely his. The words on the papyrus were his words, even if the hand was not.

The second document is the Aeneid. Written by Virgil over eleven years, so meticulously that he considered it unfinished at his death and asked for it to be burned, it represents the other terminus of what writing can be: structural complexity, psychological depth, and linguistic mastery that two thousand years have not exhausted. Virgil and Apion are both writers. The distance between them is not a failure of democratization. It is its fullest expression.

"Democratization never meant everyone writes the Aeneid. It meant that as more people write, the Aeneid became possible precisely because the entire spectrum is populated."

The printing press did not produce a world of identical writers, it produced pamphlets and Shakespeare. Word processors did not flatten literary culture, they produced a million forgettable memos and Umberto Eco. Blogs did not reduce writing to its lowest common denominator, they produced everything from diary entries to long-form journalism that reshaped public discourse. Each stage brought more people into the practice of writing, at their own level of engagement, without displacing the upper reaches of the craft. If anything, the upper reaches became more ambitious, because the tools became less of an obstacle.

Part II — The Parallel

Programming Is in Its Late-Scribe Era. The Press Has Just Arrived.

Programming, measured against this arc, is very young. For most of its history it has been in the scribe phase, not because programmers were mere copyists, but because the relationship between non-programmers and code reproduced the essential structure of the scribe relationship. You came with an intent. A specialist encoded it into a formal language you could not read. You verified the result indirectly, by observing whether the machine's behavior matched your specification. The code itself was opaque to you, not necessarily to the programmer, who understood it deeply, but to you.

LLMs are the press arriving. They do not eliminate the need for the craft. They lower the barrier of entry to the medium, drawing in people who previously had no access to programming at all. And if the history of writing is any guide, the result will not be fewer programmers. It will be a vastly larger population of programmers, stratified by depth of understanding, from the person who writes a simple script with LLM assistance to the computational equivalent of Virgil.

The spectrum runs from Apion to Virgil, and programming has the same range.

At the simplest end sits the Apion letter: functional, personal, simply encoded. A Roman marine writing home to his father. Real literacy, modest craft, genuine communicative intent. Its programming equivalent is the simple script, a data transformation, an automation, a personal tool. Written with LLM assistance, verified by someone who can read enough to audit. Real programming, modest craft, genuine functional intent.

In the middle sits the pamphlet writer: competent prose, clear argument, public audience. Not literary genius, but purposeful, skilled, consequential. The equivalent is the application developer, functional systems, coherent architecture, real users. LLMs as accelerant. Someone who reads, evaluates, and takes responsibility for what they ship.

At the upper end sits Virgil: structural complexity, psychological depth, linguistic mastery. The tools are not the obstacle. The vision is the thing. And programming has its equivalent, the computational Virgil, building systems of genuine complexity, elegance, and originality. Using LLMs the way a poet uses a thesaurus: acceleration, not substitution. The reasoning is still theirs.

The spectrum is the same. The population at every level will grow. That is what democratization has always meant.

The key word in the above is audit. Even at the Apion level, the simplest script, the most assisted code, the programmer cannot simply receive the LLM's output and press run. They must be able to read it well enough to take responsibility for it. This is precisely the position Apion was in: he didn't need Virgil's craft to write his letter, but he needed enough literacy to encode his meaning himself, to know whether the words on the papyrus were his words. The LLM-assisted programmer of the near future will be in the same position. Not a master. Not a passenger either.

Part III — The Mathematics

Why Human Understanding Is Irreplaceable at Every Level of the Stack.

This is not merely a historical observation. There is a structural reason why human understanding remains necessary at both ends of the spectrum, and at every point between, no matter how capable LLMs become. It comes from two of the deepest results in the history of mathematics, and it has nothing to do with the current limitations of any particular model.

The Halting Problem, Turing, 1936
Alan Turing proved that no general algorithm can determine, for an arbitrary program and input, whether that program will eventually halt or run forever. The proof is constructive: assume such an algorithm exists, and you can use it to build a program that defeats it, a contradiction. The result is not a limitation of current computers. It is a permanent feature of computation itself.
The consequence is precise: there is no mechanical procedure that can verify what an arbitrary piece of code will do. Not in theory. Not with more compute. Not ever. Code cannot verify itself. Something outside the formal system has to evaluate it — and that something is a mind that understands what the code is for.

Incompleteness, Gödel, 1931
Kurt Gödel proved that any sufficiently powerful formal system contains true statements that cannot be proved within that system. Extend the system, and you produce new unprovable truths. There is no closed, complete, consistent formal system capable of capturing all mathematical truth from within.
An LLM is a system that operates on tokens, symbols manipulated according to learned statistical patterns. It is, in the relevant sense, a formal system. It cannot step outside its own rules to evaluate whether what it has produced is correct. It has no semantic grounding, no sense of what the symbols are about, from which to make that judgment.

Together, these results explain something important about the entire spectrum of programming, not just its upper reaches. They are commonly invoked to explain why the most complex software will always require human genius. That is true. But they explain something about the simpler end as well.

At the lower tier
Even a simple script exists in a space of possible behaviors that no algorithm can fully enumerate. When the LLM produces a data-cleaning script, it cannot know whether that script handles malformed inputs correctly, whether it will terminate on edge cases, whether its output is semantically correct for your specific use case.
Someone has to know enough to check. Not deeply, but genuinely. Enough to read the code, recognise what it is doing, and take responsibility for running it. This is Apion's literacy: not Virgil's, but real.

At the upper tier
The most complex systems, operating systems, compilers, distributed databases, safety-critical infrastructure, involve design decisions that require holding a complete semantic model in the mind. The interactions between components, the failure modes, the invariants that must hold across all possible states.
No interpolation of plausible syntax reaches this. The computational Virgil must reason from first principles, using LLMs the way a master craftsman uses a power tool, faster, but still guided by judgment that the tool cannot supply.

The halting problem does not only limit the machine. It defines the irreducible role of the human at every level of the stack. Someone must always stand outside the code and ask: does this do what I intend? That question cannot be answered by the code itself, or by the system that generated it. It can only be answered by a mind that understands the intention, which requires, at minimum, enough programming literacy to read and evaluate what has been produced.

This is why the expansion of the programming population will not produce a world of passengers who simply prompt and run. It will produce a world of people who, through the necessity of verification, are drawn into genuine programming literacy, at whatever level their needs demand. The LLM is not the end of the requirement to understand code. It is the force that will make that requirement universal.

Part IV — The Category Error

We Confused Democratization With Automation. They Run in Opposite Directions.

We can now name the error precisely. When people say LLMs will reduce the number of programmers, they are reading the technology as automation, as a force that absorbs human skill into the machine and reduces the demand for that skill in humans. This is a coherent theory. It describes what happened to the handloom weaver, the typesetter, the travel agent.

But it is not what democratization describes. Democratization is the opposite movement: the expansion of a practice to people who previously could not access it. And the history of writing is unambiguous on what democratization actually produces. It produces more practitioners, across a wider spectrum of capability, with the upper end of the craft becoming more ambitious rather than less, because the tools stop being the obstacle.

The printing press did not reduce the number of writers. It created the modern reading public and, from that public, drew out generations of writers who would never have written in a world where access to the medium required specialist craft. Word processors did not reduce the number of writers. Blogs did not reduce the number of writers. Each inflection point looked, at the moment of arrival, like it might flatten the craft, and each one enlarged it.

"Automation subtracts human skill from a fixed process. Democratization expands the population of humans engaged with a practice. These are not the same force, and confusing them produces opposite predictions."

LLMs will do for programming what the press did for writing: draw in the Apions. People who would never have engaged with code at all, who found the blank screen and the foreign syntax too far from anything familiar, will find, with LLM assistance, that they can write a script that does what they need. They will run it. It will not quite work. They will ask the LLM to fix it, and read the changed code, and begin to understand, dimly at first, what the difference was. And in that process of iterative verification, that process of being forced to read enough to audit, they will become programmers. Modest ones. Apion-level. But genuine.

And from that enlarged base, the computational Virgil will emerge, as they always have, people for whom the expanded access to the medium is not a ceiling but a floor, who use the tools to go further than the tools alone could reach, who write systems that no LLM could have generated because the systems require the kind of reasoning that only a mind with genuine understanding can supply. The halting problem guarantees their necessity. History suggests their number will grow, not shrink, as the medium becomes more accessible.

The category error was not thinking that LLMs change programming. They do, profoundly. The error was thinking that change meant reduction, that the arrival of the press was the beginning of the end for scribes. It was the beginning of the beginning. We are at the same moment now, in programming, and we are making the same mistake in reverse: looking at a force that will massively expand human engagement with code, and seeing in it the end of the programmer.

There will be more programmers. They will not all be the same. The Apion letter and the Aeneid will both exist, and both will matter. The only question is whether we recognize what is happening in time, because code, unlike prose, does not merely represent the world. It operates on it.

¹ Letter of Apion (2nd century), It is one of the earliest surviving personal letters written by a non-elite individual in the ancient world, remarkable precisely for its ordinariness.

² Turing, A.M. (1936). "On Computable Numbers, with an Application to the Entscheidungsproblem." Proceedings of the London Mathematical Society, Series 2, 42, 230–265.

³ Gödel, K. (1931). "Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I." Monatshefte für Mathematik und Physik, 38, 173–198.