The Next Abstraction: AI Agents, Natural Language, and the Future of Code

Every major leap in computing has followed the same pattern: we stop caring about the layer below.

Binary gave way to machine code. Machine code gave way to assembly. Assembly gave way to C, which gave way to Python, TypeScript, and the rest. Each transition followed the same arc — fierce resistance from practitioners of the old layer, then gradual acceptance, then total indifference. Today, almost nobody writing Python pauses to think about the bytecode the interpreter generates, let alone the machine instructions underneath it. The abstraction won. We moved on.

I think we’re at the start of the next transition. AI coding agents and natural language are becoming the next layer of abstraction — and the implications are bigger than most people realise.

I was first introduced to this framing by Satya Nadella at GitHub Universe 2025. During a fireside chat, he traced the abstraction chain from his own career — starting with assembly, where “code as input” drove the machine directly, then compilers arriving and shifting things so that “you were thinking about code as both input and output.” He lit up reminiscing about using lex and yacc in his compiler class: “those were the most unbelievable tools… it felt so empowering to even say, oh, I can create my own language.” Then he landed the punchline for where we are now: “I’m going to use these agents here like I used compilers back in the day.”

It clicked immediately. This isn’t just a new tool. It’s the next layer.

The observation nobody’s making

The idea is gaining traction. Andrej Karpathy called English “the hottest new programming language.” Anil Dash wrote about coding agents as the new compilers. Grady Booch calls this software’s “third golden age.” The abstraction argument is well-established.

But here’s the question I haven’t seen anyone ask clearly enough: when agents get good enough that nobody checks the compiled output, what does the world actually look like?

Think about where we are with modern languages today. When was the last time you wrote Python and then inspected the bytecode it compiled to? When was the last time a Java developer read the JIT-compiled machine code their application actually runs as? You don’t. You trust the compiler. You trust the runtime. You trust the abstraction. It took decades to reach that level of trust, but we’re there.

Now imagine we reach that same point with AI agents. You describe what you want in natural language. The agent produces code. You don’t read it. You don’t need to. The abstraction is good enough.

We’re not there yet. But I think we’re closer than most people appreciate.

SpecHub: the GitHub of the next era

Today, our systems are defined in code. Repositories on GitHub are the artefacts that describe what our software does. The source code is the source of truth.

But if natural language becomes the layer we work in, then the source of truth shifts upward. Instead of repositories full of TypeScript and Python, we’d have repositories full of specifications — natural language documents that describe what the system should do, how it should behave, what constraints it should satisfy.

I’m calling this hypothetical future SpecHub. A platform where the entire application or service is defined in natural language. The code it gets “compiled” to becomes an implementation detail — something the agent handles, something you rarely inspect, something that can be regenerated from the spec at any time.

This isn’t pure speculation. GitHub is already moving in this direction with Spec Kit, a toolkit for spec-driven development where markdown specifications become the primary artefact. Birgitta Bockeler has written about the highest maturity level of this approach: “Spec-as-Source”, where specifications are the sole human-edited artifacts and code modifications happen exclusively through spec updates.

The seeds are already planted. Someone just needs to grow the forest.

The quality question: C++ agents vs Python agents

The obvious objection is code quality. If nobody’s reading the code, how do you ensure it’s good? How do you ensure it’s secure, performant, correct?

Here’s where I think the analogy to current languages is most useful.

Consider the spectrum of modern programming languages. On one end you have Python — high abstraction, rapid development, garbage collected, batteries included. On the other end you have C++ — lower abstraction, manual memory management, precise control over every byte. Both are “modern” languages. Both sit at the same level of the abstraction stack. But they make radically different tradeoffs between control and effort.

Nobody argues that Python is “better” than C++, or vice versa. They serve different purposes. You use Python when development speed matters more than runtime performance. You use C++ when you need to control exactly what the machine does. The right choice depends on what you’re building.

I predict our agent systems will follow exactly the same pattern.

Some agent systems will be the “Python” of the agentic era — fast, easy, opinionated, good enough for most use cases. You describe what you want, you get working software, you ship it. The code quality might not be artisan-crafted, but it works, it’s tested, it handles the common cases. These are your vibe coding tools.

Other agent systems will be the “C++” of the agentic era — more control, more precision, more ability to constrain and direct the output. You might specify architectural patterns, performance budgets, security requirements, coding standards. The agent respects these constraints the way a C++ compiler respects your memory layout decisions. It takes more effort, but you get more control.

Addy Osmani has written about “the 80% problem” — agents rapidly handle 80% of the work, but the remaining 20% requires deep architectural knowledge. The C++/Python spectrum of agents is how I think this gets solved. Different agents for different levels of that 20%.

The next inflection point

Every abstraction layer had a turning point — the moment it went from “interesting experiment” to “this is how we build now.” For high-level languages, it was when compilers got good enough that hand-written assembly couldn’t consistently beat them. For managed languages, it was when garbage collectors got efficient enough that manual memory management stopped being worth the tradeoff for most applications.

For AI agents, I think the inflection point will be when someone cracks the first “C++ agent” — an agent system that gives you genuine, fine-grained control over architectural decisions, performance characteristics, and code quality, while still operating at the natural language layer. Right now, most agent tools are closer to the “Python” end of the spectrum: fast, convenient, but opinionated and sometimes sloppy. The moment an agent system achieves the control and precision that serious engineering demands, that’s when the transition accelerates for real.

We’ll know we’ve arrived when a team ships a production system entirely from specs, and nobody on the team has read a single line of the generated code — not because they’re lazy, but because the abstraction is trustworthy enough that they don’t need to. Just like you don’t read the bytecode your Python compiles to.

In my work as a consultant, I’m already hearing this from large enterprises. Teams experimenting with spec-first workflows, exploring what it looks like to define services entirely through structured requirements and let agents handle the implementation. It’s early — more proof-of-concept than production — but the appetite is real, and the experiments are happening now.

The Dijkstra objection

In 1978, Edsger Dijkstra wrote “On the Foolishness of Natural Language Programming”, arguing that natural language is too ambiguous and imprecise for programming. Formal languages were invented because natural language failed us in technical contexts.

It’s a fair criticism — for the world of 1978. Dijkstra was thinking about one-shot translation: write a natural language specification, translate it to code, hope it’s correct. That process is indeed foolish.

But as Marc Brooker pointed out, that’s not what’s happening with agents. The conversational, iterative loop of modern agent coding is fundamentally different. You describe intent, the agent produces code, you test it, you refine your description, the agent adjusts. It’s a feedback loop, not a one-shot translation. And feedback loops converge in ways that one-shot translations never could.

Besides, almost all software is already specified in natural language — in requirements documents, Jira tickets, Slack messages, design docs. The agent just closes the gap between that natural language and the running code. The gap was always there. The agent just makes it smaller.

What we might lose

I’d be dishonest if I didn’t mention the risks. The biggest one, to me, is skills atrophy. If junior developers never write real code — never debug a memory leak, never trace a stack overflow, never optimise a hot loop — where do the future senior engineers come from? Who builds the agents themselves?

Every abstraction layer has this risk. Most programmers today couldn’t write efficient assembly if their life depended on it. And yet, software engineering didn’t collapse — it evolved. The skills that matter shifted from “can you manage registers” to “can you design systems.” The same shift will happen again. The skills that matter will shift from “can you write code” to “can you specify systems precisely enough that an agent builds them correctly.”

Whether that’s a loss or a gain depends on what you think programming is really about. I think it’s about solving problems. The code was always just the medium.

Where we are now

We’re in the early days of this transition. Current agents are impressive but inconsistent. They work well for greenfield projects and common patterns, less well for complex existing codebases and novel architectures. The trust isn’t there yet — most developers still read every line of agent-generated code.

But the trajectory is clear. The abstraction is rising. The gap between intent and implementation is closing. And if history is any guide, within a decade, a new generation of developers will find it quaintly amusing that we used to write code by hand — the same way we find it quaintly amusing that anyone used to write software in machine code.

The question isn’t whether this transition will happen. It’s whether we’ll build the right tools — the C++ agents, the SpecHubs, the trust mechanisms — to make it happen well.

---

Note: This article was written with the assistance of AI — though every idea expressed is fundamentally my own. Every sentence has been manually reviewed and adjusted. I fully own the responsibility of all statements made in this post.