Coding Agents as a Continuation of the Normal Technological Development of Code-Writing Tools: CHART OF THE DAY
From 500,000 Coders to 2.5 Million Devs: What Actually Changed? The programmer’s comparative advantage used to lie in being able to hold complex state in their head and to speak the dialects of...
From perhaps 2000 calculator-tabulator Wirers in 1935 to 80,000 Coders in 1965 to 500,000 in 1995 to 2.5 Million Devs today: What actually changed in how they spent their time on the job? The programmer’s comparative advantage used to lie in being able to hold complex state in their head and to speak the dialects of both the compiler and the database optimizer. The software developer’s comparative advantage is fuzzier—a finger in many pies, but the ability to buckle down and write or boss the writing of code running very close to the bare silicon whenever it becomes essential to do more than add switches to a wizard…
More attention needs to be paid to how 500,000 computer programmers in 1995 in the United States became 2.25 million software developers and 250,000 computer programmers come 2025. Everyone wants to talk about whether AI will replace software engineers; almost nobody asks how the job already changed under their feet.
Today we have:
Arvind Narayanan & Sayash Kapoor: Why AI Hasn’t Replaced Software Engineers, & Won’t <https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers>: ‘Coding agents as normal technology…. Knowledge work, including software development, as… “decide-execute-deliver”…. AI compresses the “execute”… but the other two layers resist automation in a way that will not be overcome by capability improvements alone…. The stories of AI-driven mass layoffs in software seem to be classic “AI washing”…. Among the 270 jobs in the 1950 U.S. census, only one job was automated away — elevator operator. But many others were rendered obsolete by new technology, like the job of telegraph operator….
Writing code isn’t, and never was, the bottleneck…. Three things… [are] real bottlenecks:
(1) deciding and specifying what to build,
(2) verifying and being accountable for what is delivered, and
(3) the deep human understanding—of the codebase, the business, and the environment—required to carry out both of these….
As more and more of the execution layer gets delegated to AI, the software engineer’s role in the future becomes analogous to that of a crane operator. AI agents will do most of the cognitive heavy lifting; supervising the agent and keeping it in control becomes most of the human’s job…. The sandwich getting squished is a new trend and it is not uniquely due to AI…. This pattern—where humans remain heavily involved at both ends of the decide-execute-deliver sandwich, even as AI increasingly automates the middle layer, seems to be broadly applicable to most knowledge work, though it is farthest along in software.…
Some people predict that demand for software engineering skills will fall… [as] the work will be done by people who are not software engineers…. Maybe. But… there have always been [such] claims… FORTRAN, COBOL, and SQL were all accompanied by such prominent hopes…. It never happened. The barrier… is having enough skilled judgment to make good decisions while maintaining accountability…
Well, I cannot find much I think is really superb on how what the 2.5 million do is different from what the 500,000 did. So here is my take:
First: headcount has multiplied by roughly five, even as tools for writing software have become vastly more productive There have been massive improvements in languages, frameworks, cloud infrastructure, open-source libraries, and now AI coding assistants. In 1995, a “computer programmer” was, to a remarkable extent, a translator between a relatively well-specified business need and a relatively unforgiving, low-level environment. The programmer’s day was spent managing memory, juggling file handles, worrying about whether the database would lock, working around idiosyncrasies of vendor toolchains, and producing line-of-business applications or systems software that ran either on a departmental server in a closet or on a desktop. The interfaces to the rest of the firm were narrow: a requirements document, a meeting with a business analyst, perhaps some end-user testing before deployment.
Once the system went live, change was expensive. Releases were infrequent, rollback was painful, and “works on my machine” was still a meaningful defense. The stack was shallow but harsh. Many programmers were working in C, C++, Visual Basic, early Java, or proprietary 4GLs. They managed their own build systems, their own deployments, their own monitoring—if there was any monitoring beyond log files. The programmer’s comparative advantage lay in being able to hold complex state in their head and to speak the dialects of both the compiler and the database optimizer.
A modern software developer sits in a thicket of abstractions: managed runtimes, serverless platforms, container orchestration systems, high-level frameworks, third-party APIs for payments, identity, mapping, messaging. There is vastly more reuse. The developer’s daily work is about choosing and composing modules, gluing services together, and then living with the operational consequences. The 1995 programmer primarily wrestled with the constraints of immature tools and low-level environments to translate fairly well-specified needs into functioning software, with limited ongoing responsibility. The 2025 software developer orchestrates powerful tools and services in a noisy high-stakes environment.
In 2025, the line between building and running a system is very blurry. A contemporary software developer is expected to own code from design through deployment to on-call pager duty. That means incident response, observability, performance tuning under real-world load, and—importantly—making tradeoffs between reliability, speed of delivery, and cost. In effect the job has metastasized from “write the program” to “own this slice of the socio-technical system”. Plus: A huge amount of what would once have been called “programming” has migrated outward into the hands of people who would not have been classified as programmers at all.
If AI is going to be “normal technology”, it will take what used to be an artisanal, hand-coded “execute” step and turn it into something that can be semi-automated. In 1995, if you wanted a function written, you, the programmer, wrote it. In 2025, you often describe it in natural language and have an assistant generate a first draft, which you then review, test, modify, and integrate. That is less like soldering circuits (or perhaps lifting that bale) and more like sending a pattern out for photolithography (or operating a crane): the machine does the heavy lifting, but you are responsible for what goes wrong.
Verifying what you have built is also harder. The intellectual community around the job is profoundly different. And there is the political economy of the occupation. In 1995, “computer programmer” was important but not yet central to the story of American capitalism. Today, software developers sit on the commanding heights.
If reading this gets you Value Above Replacement, then become a free subscriber to this newsletter. And forward it! And if your VAR from this newsletter is in the three digits or more each year, please become a paid subscriber! I am trying to make you readers—and myself—smarter. Please tell me if I succeed, or how I fail…
I've been a bank mainframe programmer since 1983 and lived through the shrinking ranks of rowers and burgeoning army of coxswains. The excerpt ends on the word "accountability" and while reading it I was reminded of Dan Davies' "The Unaccountability Machine". Toward the end, he describes an interview with Steve Jobs about the decline of IBM as they perfected "process" and lost sight of what they were trying to achieve. No problem is too simple to not abstract into insolubility. If late 90's process guides are used to train the LLMs, software development will have been confounded and given over to the bitter flames.
I've been a bank mainframe programmer since 1983 and lived through the shrinking ranks of rowers and burgeoning army of coxswains. The excerpt ends on the word "accountability" and while reading it I was reminded of Dan Davies' "The Unaccountability Machine". Toward the end, he describes an interview with Steve Jobs about the decline of IBM as they perfected "process" and lost sight of what they were trying to achieve. No problem is too simple to not abstract into insolubility. If late 90's process guides are used to train the LLMs, software development will have been confounded and given over to the bitter flames.