Is AI the Next Programming Abstraction?

Programming has always been about abstraction.

At the bottom is hardware. Transistors switch on and off. We represent those states as binary: ones and zeros.

Almost nobody wants to program that way.

So we built abstractions on top of it.

Machine instructions gave us a vocabulary for what processors could do. Assembly language gave those instructions names. Languages such as C let programmers describe algorithms without worrying about every processor instruction. Languages such as C#, Java, Python, and TypeScript moved us farther from the hardware again.

Then we built frameworks, libraries, database abstractions, cloud platforms, and other layers on top of those languages.

At each step, we stopped describing some of how the computer should perform a task and became better able to describe what we wanted it to do.

AI is the next layer in that progression.

But there is an important reason we should not skip the layers underneath it.

From English to Code

Consider a simple requirement:

A user can change their own profile, but cannot change another user's profile.

Today, I might give that requirement to an AI coding tool.

The AI interprets the English and produces something like:

if (profile.UserId != currentUser.Id)
{
    return Forbid();
}

profile.Name = request.Name;
await repository.SaveAsync(profile);

We can think of the AI as performing a new kind of translation.

A compiler might translate:

C# → intermediate code → machine instructions

AI is doing something farther up the stack:

English → C#

Calling this "compiling English" is not technically exact, because AI does not behave like a deterministic compiler. But as a mental model, it is useful.

We describe our intent in a language comfortable for humans. AI translates that intent into a formal language that traditional tools can process.

The important part is that we still have the C# in the middle.

Why Not Go Straight to Machine Code?

Suppose an AI became good enough that it could translate:

A user can change their own profile, but cannot change another user's profile.

directly into optimized machine instructions.

In theory, that could work.

It would also remove something extremely valuable.

We would know what we asked for, and the computer would know what it was executing, but the useful representation between those two things would be gone.

Source code gives us that representation.

A programmer can examine the generated code and ask:

Does this actually check the user ID?

What happens when the current user is not authenticated?

Can an administrator edit someone else's profile?

What fields are allowed to change?

Is the operation logged?

Those questions are much harder to answer by examining machine instructions.

Source code therefore serves two purposes.

It tells the machine what to do.

It also tells humans what the machine is supposed to do.

With AI, that second purpose becomes even more important.

AI Should Work in Both Directions

We usually talk about AI coding as a one-way process:

Requirement → AI → Code

But there is another direction that may ultimately be just as valuable:

Code → AI → Explanation

Imagine giving an AI two things.

First, the written requirement:

A user can change their own profile, but cannot change another user's profile.

Second, the actual implementation.

Instead of asking the AI to write code, we ask:

Does this code actually implement this requirement?

Now AI can use its language abilities on both sides of the problem.

It can understand the written intent.

It can understand the source code.

And it can identify differences between them.

For example:

The requirement says users may modify only their own profiles. The implementation verifies that the caller is authenticated, but it does not verify that the profile belongs to the caller.

That is much more interesting than simply generating code.

It turns AI into part of the verification process.

This Changes What We Should Want From Programming Languages

It might seem that better AI makes programming languages less important.

I think the opposite is likely to happen.

If humans increasingly describe systems in English and AI increasingly writes the implementation, then source code becomes an important contract between human intent and machine behavior.

We should want that contract to be as clear as possible.

Consider null values.

A language could rely on programmers remembering that a particular value should never be null.

Or the language can let us express that directly:

string name

versus:

string? name

Now the intent is represented in the language, and tools can reason about it.

The same principle can apply to many things:

This value cannot change.

This operation requires authorization.

This function has no side effects.

This data belongs to this user.

This operation can fail in these specific ways.

This resource belongs to this security boundary.

The more of that information we can represent explicitly in code, the less humans and AI have to guess.

Good programming languages turn assumptions into syntax and conventions into semantics.

Readability Is No Longer Just for Humans

For decades, we have said that code should be readable because other programmers will eventually have to maintain it.

That remains true.

But we now have another reader.

AI.

An expressive programming language gives an AI more useful information when it analyzes a system. Clear types, explicit security boundaries, well-defined errors, immutable values, and obvious side effects all make it easier to compare implementation with intent.

That means programming-language design should not stop simply because AI can generate code.

We may need better programming languages because AI can generate code.

If AI writes ten thousand lines in seconds, typing efficiency matters much less than it once did.

Clarity matters more.

We should favor languages and language features that make important intentions explicit, machine-checkable, and difficult to accidentally violate.

The Next Abstraction

The progression of programming might be simplified like this:

Binary
   ↓
Machine instructions
   ↓
Assembly
   ↓
High-level languages
   ↓
Frameworks and libraries
   ↓
AI
   ↓
Human intent

Each layer allows us to describe a problem at a higher level.

But the layers below do not become useless just because we add another one above them.

AI should not need to produce binary directly any more than most application developers should need to write assembly.

Instead, AI can translate human intent into a formal language designed to express that intent clearly.

Then our existing tools can compile it, analyze it, test it, and execute it.

And AI can perform another important job: read that formal representation back and compare it with what the human originally asked for.

The future of programming may involve much less typing.

That does not mean we need less precise programming languages.

It may mean we need the most expressive ones we have ever designed.