A perspective, in brief.
There was a time when programming a computer meant physically touching the computer. Not touching a keyboard. Touching the computer . Wires had to be connected. Switches had to be set. On machines such as ENIAC, configuring a new problem could mean physically connecting cables and setting switches, sometimes taking days.
Then we found a better way.
We started representing instructions as machine code. 0s and 1s. The machine still understood exactly the same thing, but humans had moved one level away from the physical hardware. And that, I think, is where one of the most important patterns in the history of computing began. We kept moving away from how the machine works , and kept moving closer to what the human wants .
Then even 0s and 1s became too much work.
Imagine having to tell a processor exactly what to do, instruction after instruction, in the language the machine understands. We did that. Then we invented assembly language. Instead of remembering sequences of binary instructions, programmers could use symbolic instructions such as:
MOV ADD JMP
The computer still didn't understand MOV. Another layer translated it. And suddenly, humans didn't need to think exactly like processors anymore.
That was abstraction.
Then came higher-level programming languages. FORTRAN. COBOL. C. And later C++, Java, Python, JavaScript and hundreds of others. Now something remarkable had happened. A programmer could write something reasonably close to human logic and let another piece of software translate that into something the machine could actually execute. Think about how radical that must have sounded at the time. Grace Hopper, one of the pioneers of compilers, recalled the resistance very simply:
“I had a running compiler, and nobody would touch it.”
The idea that a computer could help write or translate programs was itself difficult for people to accept. Today, of course, nobody says, "Using a compiler is cheating." We call it programming .
And then programmers started hiding code from other programmers.
Functions. Subroutines. Libraries. Packages. Frameworks. APIs. Databases. Cloud platforms.
Every one of these introduced another layer between the person building something and the underlying machinery making it happen. If I call a sorting function today, I don't need to write a sorting algorithm. If I call a payment API, I don't need to understand every system processing that transaction. If I deploy something on the cloud, I might never know which physical server eventually executes my code. And this is where abstraction becomes really interesting. Because abstraction does not remove complexity. It moves complexity somewhere else.
Someone still has to understand operating systems. Someone still writes database engines. Someone still designs processors. Someone still works on compilers. But everyone building above that layer suddenly becomes dramatically more productive because they don't have to solve those problems again.
With every step, it was from less "How" to more "What".
History was obviously messier than this neat ladder. Many of these developments overlapped rather than arriving neatly one after another. But the direction is difficult to miss. And every new level probably felt a little like cheating. This is the part I find fascinating. You don't know machine code? Cheating.
You use a compiler? Cheating.
You didn't write that algorithm yourself? Cheating.
You imported a library? Cheating.
You used Bootstrap instead of writing the CSS? Cheating.
You searched Stack Overflow for an error somebody had already solved? Cheating.
Somewhere along the way, yesterday's cheating quietly becomes today's standard practice. And then a new abstraction appears. And the debate starts again. Which brings us to AI-assisted programming. Today I can describe something in natural language:
Create a login flow with Google authentication, role-based access, password recovery and an admin dashboard.
And an AI coding system can generate a substantial portion of the implementation. A few years ago, that sentence was a product requirement. Today, increasingly, it can also become an instruction to the development environment itself. That is a significant change. But is it really an unnatural one? I am beginning to think it isn't.
The code did not disappear. Another translation layer appeared above it. And that distinction matters. Jensen Huang (President and CEO of NVIDIA) described this idea rather dramatically:
“The programming language is human: everybody in the world is now a programmer.”
His argument is that computing technology is moving towards understanding instructions from ordinary humans rather than requiring every human to learn the machine's language. Whether everybody becomes a programmer is debatable. But the direction is difficult to ignore. Programming is moving closer to intent. And this does not mean that understanding programming becomes irrelevant. Quite possibly, the opposite happens. Steve Jobs once said that people should learn programming because:
“It teaches you how to think.”
That distinction becomes even more important in an AI-assisted world. There is a massive difference between knowing how to type code and knowing how to build software . Architecture still matters. Data models still matter. Security still matters. Performance still matters. Edge cases still matter. And above all, judgement still matters .
AI may dramatically reduce the effort required for implementation. But somebody still needs to decide what should be built, why it should behave in a particular way, what constraints it must respect, whether the generated solution makes sense, and whether the outcome is actually correct. The skill doesn't disappear. The skill moves up the abstraction stack.
And perhaps this is why AI-assisted coding feels so uncomfortable to some people. Because abstraction changes what we reward. The person who could once remember every command had an advantage. Then the person who understood the programming language had an advantage. Then the person who understood systems and architecture had an advantage. Now the person who can clearly define a problem, provide the right context, break it into components, guide an AI system and critically evaluate what comes back may have an advantage . That can feel unfair to someone who spent years mastering the layer immediately below it. But this has happened before. Many times.
There is another implication which I find even more interesting. If this really is an abstraction journey, then AI-assisted programming cannot be the destination. Because natural language itself is still an instruction. We are still telling the machine what to do. We have simply changed the language. Today:
I write the code.
is becoming:
I describe the code I want.
But perhaps the next abstraction is:
I describe the outcome I want.
And perhaps the level after that is:
I describe the problem.
The system figures out the rest.
Switches became bits. Bits became assembly. Assembly became high-level languages. Languages became functions, libraries, APIs and frameworks. And now increasingly, human language can become software. Every generation has moved us slightly further away from the mechanics of computation and slightly closer to human intent. Every transition created sceptics. Every transition changed what it meant to be technically skilled. And every transition, at least for a while, probably looked suspiciously like taking a shortcut. Maybe AI-assisted programming really is cheating. Just like compilers were. Just like libraries were. Just like every great abstraction before it. And if natural language is only the next level of abstraction...
what comes after language?
Prasanjit Saha is a Digital Product Leader and Applied AI practitioner with 16+ years of experience across product, digital transformation and technology-led businesses. He writes about Product Management, AI and the changing relationship between humans and technology. More at prasanjitsaha.com .
Key themes
- Abstraction moves complexity; it does not eliminate it.
- AI changes implementation effort, while architecture, constraints and evaluation remain essential.
- The next unit of technical leverage is clear intent and critical judgement.