Every era of programming has been an argument about the same thing. How much of the work should the human do, and how much should we hand to the machine? Each time we have answered “give more to the machine,” someone has objected that the machine cannot be trusted with it, that real programmers work closer to the metal, and that the new convenience is a toy. And each time, within a decade, the convenience has become the floor that the next generation of programmers stands on without a second thought.

This is a story about that floor rising. It runs from a woman feeding subroutines to a UNIVAC on tape in 1952 to a teenager in 2026 building a working web application by describing it to a language model in English. The technologies could not look more different. The motive behind them is identical.

Hopper and the first compiler

Grace Hopper had already spent years hand-coding machine instructions when she started asking why. She had programmed the Harvard Mark I during the war, and she understood something that many of her contemporaries did not. A great deal of programming was not creative work at all. It was the same handful of mathematical subroutines, copied out by hand again and again, with all the transcription errors that hand-copying invites.

So in 1951 and 1952 she built the A-0 system for the UNIVAC I, which is generally remembered as the first compiler (Computer History Museum). By modern standards A-0 was closer to a linker than a compiler. A programmer wrote a list of symbolic call numbers, and A-0 found the matching subroutines on tape, pulled them together, and produced a running program (A-0 System). The mechanism is less important than the idea. For the first time, a programmer could describe part of what they wanted and let the machine work out part of the how.

The reaction was not gratitude. Hopper later recalled the resistance in plain terms. “I had a running compiler and nobody would touch it,” she said. “They carefully told me computers could only do arithmetic; they could not do programs.” Convincing people to trust automatic programming, she said, “was a selling job” (Grace Hopper). Her diagnosis of the objection has outlived the objection itself. The most dangerous phrase in the language, she liked to say, is “we’ve always done it this way.”

Hopper’s real target was bigger than subroutines. She wanted people who were not mathematicians to be able to use a computer, and she believed the way to get there was to let them write in something closer to their own language. That conviction led through FLOW-MATIC to COBOL, a language built so that business logic could be read in near-English sentences by the managers who depended on it (COBOL). The goal was never cleverness. The goal was access.

FORTRAN and the proof that abstraction could be fast

If Hopper supplied the motive, John Backus and his team at IBM supplied the proof that the motive was practical. Beginning in 1954 they built FORTRAN, short for Formula Translation, and released it for the IBM 704 in 1957 (Fortran). FORTRAN let scientists and engineers write algebraic formulas, loops, and conditionals in a notation close to the mathematics they already knew, and it left the compiler to turn that notation into machine code.

The objection this time was about speed, and it was a serious one. Machines were expensive and slow, and hand-written assembly was tight. Why would anyone accept the overhead of a translator standing between them and the hardware? Backus understood that the whole idea would die if the generated code was slow, so his team built what is often called the first serious optimizing compiler, and it produced code that ran nearly as fast as hand-written assembly (Fortran). That was the hinge. Once abstraction was demonstrably cheap, the argument for staying close to the metal lost most of its force. Backus received the ACM Turing Award in 1977, in part for this work (A.M. Turing Award).

The productivity gain was enormous and a little disorienting. Programmers who once wrote every instruction now wrote a small fraction of them and let the compiler generate the rest. The human had been promoted from transcriber to author.

The software crisis and the discipline of structure

Raising the level of abstraction let people build bigger systems, and bigger systems brought a new kind of trouble. By the late 1960s the field had a name for it. At the 1968 NATO conference in Garmisch, attendees spoke openly of a “software crisis,” of projects that ran late, ran over budget, and could not be made reliable, and they proposed the deliberately aspirational term “software engineering” as the cure (NATO Software Engineering Conferences).

That same year Edsger Dijkstra published his famous letter in Communications of the ACM arguing that the unrestricted goto statement made programs impossible to reason about (Go To Statement Considered Harmful, PDF). The letter is remembered for what it attacked, but its lasting contribution was what it defended. Dijkstra was arguing for structure, for building programs out of a small set of well-behaved constructs whose behavior you could understand locally and then compose into larger wholes. This was abstraction of a subtler kind. Not abstraction away from the hardware, but abstraction of control itself into shapes a human mind could hold. Dijkstra received the Turing Award in 1972 (A.M. Turing Award).

The pattern is worth naming, because it repeats. A rise in abstraction enables larger systems. Larger systems expose a new complexity. And the response to that complexity is another, higher form of abstraction.

Objects, portability, and the virtual machine

The next several decades were variations on the theme, each one packaging complexity behind a cleaner interface.

Simula, designed in Norway in the 1960s, introduced the class and the object and is generally credited as the origin of object-oriented programming (Simula). Alan Kay and his colleagues at Xerox PARC pushed the idea to its pure form in Smalltalk, where everything was an object communicating by messages, and Kay’s larger ambition was again about access, about making computing comprehensible to people, including children (Smalltalk). Objects let programmers bundle data with the behavior that acted on it and hide the internals behind a public face, so that a large system could be reasoned about one component at a time.

Dennis Ritchie’s C, developed alongside Unix, abstracted in a different direction. It let an operating system be written once and moved to new hardware with far less effort than assembly required, which is a large part of why Unix spread so widely (C). The program was no longer welded to one machine’s instruction set.

Java carried that idea to its logical end. Source code compiled not to any real processor but to bytecode, executed by a Java Virtual Machine, so that the same compiled program could run anywhere a JVM existed. The physical computer had itself become an abstraction, a detail hidden beneath a portable illusion.

The cloud dissolves the machine entirely

By the 2010s the machine had not just been abstracted. It was disappearing from view. Cloud computing turned servers into something you requested by the minute instead of bought and racked. Then serverless computing went further, letting a developer deploy a single function and never think about the server it ran on at all, with the provider allocating and scaling the underlying resources automatically (Serverless computing).

The word “serverless” is a small monument to how far the floor had risen. There were of course still servers. There had always still been hardware, under the bytecode, under the C, under the FORTRAN, under the call numbers on Hopper’s tape. The point of every layer was to let the person above it stop thinking about the layer below. Serverless simply named that goal out loud.

English as the newest high-level language

Which brings us to the present, and to the newest and strangest layer yet.

In June 2021, GitHub released Copilot, an “AI pair programmer” built on OpenAI’s Codex model, which suggested whole lines and functions from inside the editor and could turn a comment written in plain English into working code (GitHub). When ChatGPT arrived the following year, the interaction moved from inline suggestion to full conversation, and people began generating entire programs by describing what they wanted and refining it in dialogue.

The objections are, almost word for word, the ones Hopper heard in 1952. The output cannot be trusted. Real programmers understand their code. This is a toy for people who never learned to do it properly. And the honest answer is that the skepticism is not baseless. GitHub’s own research found that developers accept only around thirty percent of Copilot’s suggestions, which means most of what these systems propose is still reviewed, changed, or thrown away by a human who knows better (GitHub research). The human is still the editor. What has changed is that the first draft now comes from the machine.

In early 2025 Andrej Karpathy gave the new mode a name. “Vibe coding,” he called it, a style where “you fully give in to the vibes” and “forget that the code even exists,” describing what you want and letting the model write and fix it (Vibe coding). Two years earlier he had put the underlying claim more provocatively. “The hottest new programming language,” he wrote, “is English.” He did not mean English literally, and he did not mean that formal languages were finished. He meant that natural language had become a viable way to specify behavior to a machine that would translate intent into instructions.

Read that sentence again with Hopper in mind. Translate intent into instructions. That is exactly what A-0 did with call numbers on a tape in 1952. It is what FORTRAN did with algebraic formulas in 1957. The mechanism is now a neural network trained on a corpus of human code rather than a table of subroutines, and the gap it crosses is far wider, but the job is the same job it has always been.

The floor keeps rising

There is a genuine difference this time, and it deserves to be stated plainly rather than waved away. Every previous layer was deterministic. A FORTRAN compiler given the same input produced the same output, and if it was wrong, it was wrong the same way every time, which is a thing a person can learn and account for. A language model is probabilistic. It can be confidently, fluently wrong, and it can be wrong differently on Tuesday than it was on Monday. That is a real change in the character of the tool, and it is why the human editor matters more here, not less.

But the shape of the story is old and familiar. Someone raises the level of abstraction so that more people can build more things with less ceremony. The people who mastered the older, lower level object that the new level hides too much and understands too little. The new level turns out to be useful anyway, its rough edges get sanded down over a few years, and it becomes the unremarkable ground that the next generation stands on. Then someone proposes to raise the floor again.

Grace Hopper spent her career fighting the sentence “we’ve always done it this way.” Seventy years later, the tools she would recognize least are the ones carrying her argument forward. The whole history of programming has been a long climb toward letting humans say what they want and letting the machine work out the rest. We are simply higher up the slope than we have ever been, and the view from here, as always, makes some people dizzy and makes others want to keep climbing.

References