The Great Abstraction: Why Programming Languages Are the Next Layer to Disappear
I’ve been doing this for over twenty years. DevOps, platform engineering, infrastructure — whatever we’re calling it this decade. And there’s a pattern I keep seeing that nobody talks about.
Every layer of the technology stack eventually gets abstracted away. And when it does, the people who built their careers on that layer panic. Every single time.
I think we’re about to watch it happen again. This time, it’s programming languages.
The Pattern
Let me walk through this, because I lived through most of it.
Bare Metal → Virtualization
I did catch the tail end of this one. Early in my career, infrastructure meant knowing your hardware intimately. What kind of RAID array. How many spindles. How to rack a server and cable it properly. You had a relationship with your hardware — sometimes literally naming your servers.
Then VMware showed up. Suddenly one physical box could run ten virtual ones. The hardware still mattered, but you didn’t have to think about it the same way. You thought about virtual machines instead.
The bare metal people said virtual machines would never perform as well. They were right — for a while. Then hypervisors got better. And eventually, for 99% of workloads, it just didn’t matter.
Operating Systems → Containers
This one I watched play out in real time, and it’s the one that hits closest to home.
I spent years learning the intricacies of specific operating systems. Linux kernel tuning. Package management across distros — the differences between RHEL and Ubuntu and SUSE weren’t trivial. Filesystem choices, init systems, networking stacks. Each OS had its quirks and you needed to know them.
Then Docker happened.
Suddenly, your application ran in a container that abstracted away the host OS. It didn’t matter if you were running on Ubuntu or Amazon Linux or whatever — the container was the same everywhere. Kubernetes took it further and abstracted away individual machines entirely. You stopped thinking about servers and started thinking about workloads.
The OS experts said containers added unnecessary complexity. They said you’d still need to understand the underlying system. They were right — sort of. You still need people who understand what’s under the hood. But the number of engineers who need deep OS expertise went from “most of the team” to “one or two specialists.”
I know this because I was one of those OS experts. My deep knowledge of Linux internals went from being my primary value to being background context that occasionally mattered.
Infrastructure → Cloud
Same pattern, different layer. We used to manage data centers. Then AWS and GCP said “don’t worry about it, we’ll handle the servers.” Then Terraform said “don’t worry about clicking buttons, just describe what you want.” Then managed services said “don’t worry about databases or message queues, just use ours.”
Each abstraction removed a layer of knowledge that used to be essential.
The Part Nobody Wants to Hear
Here’s my theory: programming languages are the next layer to get abstracted away.
Not tomorrow. Not completely. But the pattern is undeniable, and we’re already seeing the early signs.
Think about what a programming language really is. It’s an abstraction layer between human intent and machine execution. You learn Python’s syntax. You memorize Go’s concurrency patterns. You internalize Rust’s ownership model. All of that knowledge exists to translate what you want the computer to do into something it can understand.
What if you could just… describe what you want?
That’s what’s happening right now with AI code generation. I’m not talking about autocomplete. I’m talking about describing a feature — what it should do, how it should behave, what the edge cases are — and having an AI write the implementation. In whatever language makes sense for the context.
I’ve been doing this daily for the past six months. Using Claude Code, I describe what I want built, and it writes Python, TypeScript, Go, Rust — whatever the project calls for. I review the output for correctness and architecture, not for syntax. I’m thinking about what the system should do, not how to express it in a particular language.
The language is becoming an implementation detail. Just like assembly. Just like the operating system.
”But You Still Need to Understand the Code”
Yeah, I hear you. This is the same thing the assembly programmers said about C. The same thing the OS experts said about containers. The same thing the data center engineers said about cloud.
They were all correct. And they were all eventually irrelevant.
You still need people who understand what’s happening at lower layers. When the abstraction leaks — and it always leaks — someone needs to dig in. But that’s a specialist role, not a prerequisite for every engineer.
I still understand Linux internals. That knowledge helps me debug weird container networking issues maybe twice a year. It’s valuable context. It’s no longer the job.
Programming languages will follow the same path. Understanding Python’s memory model or Go’s goroutine scheduler will become specialized knowledge, valuable for edge cases but not required for most engineering work.
What Actually Matters
If languages get abstracted away, what’s left? The same thing that was always underneath the syntax:
Understanding systems. How data flows. Where state lives. What happens when things fail. How to decompose a problem into the right pieces. How to think about performance, security, and reliability at an architectural level.
Understanding the domain. What the business actually needs. What users care about. What “correct” means for this particular problem.
Understanding tradeoffs. Why you’d pick a queue over a direct call. When eventual consistency is fine and when it’s not. Where to draw service boundaries.
None of that is language-specific. It never was. The language was always just the vehicle for expressing those ideas. We just got really attached to the vehicle.
I’m Not Saying Learn Nothing
Look, I’m not saying stop learning. I’m saying the type of knowledge that matters is shifting. It’s been shifting for 50 years and it’s not going to stop.
When I started in this field, knowing how to configure a RAID array was a valuable skill. It still is — for about 200 people. The rest of us moved up a layer.
When I was deep in Linux administration, knowing how to tune vm.swappiness and optimize ext4 mount options was critical. Now most engineers will never touch a host OS directly.
The engineers who thrived through each of these transitions weren’t the ones who clung to their layer. They were the ones who understood that the underlying thinking — systems design, reliability, architecture — transfers up. The syntax is disposable. The judgment isn’t.
Where I Think This Goes
In five years, I think most engineers will work primarily in natural language — describing what they want, reviewing what they get, iterating on the design. The AI handles the translation to code, just like a compiler handles the translation to machine instructions.
Programming languages won’t disappear. Assembly didn’t disappear. Linux administration didn’t disappear. But they’ll become a layer that most people don’t need to touch directly.
And honestly? I think that’s fine. Every time we’ve moved up a layer of abstraction, we’ve been able to solve bigger problems. We stopped thinking about registers and started thinking about algorithms. We stopped thinking about servers and started thinking about systems. We’ll stop thinking about syntax and start thinking about… whatever comes next.
I’ve watched this happen three times in my career. I’m not going to pretend the fourth time will be different.
I’m Dave — co-founder of App Vitals, where we help engineering teams move faster with AI. After 20+ years in DevOps and platform engineering, I now spend my days helping teams navigate this exact transition. I also have a personal AI assistant named Sully running on a Raspberry Pi in my house, which feels relevant to this post.