DEV Community

Greg Urbano
Greg Urbano

Posted on

Humans Will Not Be Able to Program, Let Alone Read, the Next Programming Language

Here's the hard truth I've realized: the era of humans writing code line‑by‑line is ending. And the next programming language? Humans won't be able to read it. Let alone write it.

The numbers are already staggering. And they're about to make this conversation very real.


It's Already Happening: The AI Coding Revolution, By the Numbers

You don't need to take my word for it. Just look at what the biggest technology companies on Earth are admitting right now.

Google CEO Sundar Pichai revealed in April 2026 that 75% of all new code at the company is now AI-generated and approved by engineers. That's up from 25% in 2024 and 50% in late 2025. Pichai added that AI agents were able to complete a complex code migration task six times faster than human engineers. [1]

Microsoft CEO Satya Nadella confirmed that 20–30% of code in Microsoft's repositories is now written by AI. Microsoft CTO Kevin Scott went further, predicting that by 2030, as much as 95% of all code could be AI-generated. [2]

Meta has set aggressive internal targets. In their creation organization (responsible for Facebook, WhatsApp, and Messenger), 65% of engineers are expected to write more than 75% of their code using AI tools in early 2026. Company‑wide, a goal for late 2025 required 55% of code changes to be AI‑agent‑assisted. Meta has told employees that "AI‑driven impact" will become central to performance reviews from 2026 onward. [3]

OpenAI president Greg Brockman announced at the AI Ascent 2026 conference that AI now writes 80% of their code — up from just 20% in December 2025. He emphasized, however, that all code merged into their repositories is still reviewed by humans. [4]

Anthropic chief product officer Mike Krieger went even further. In a February 2026 interview, he stated that their AI, Claude, has become the primary author of its own development — "effectively 100%" of Claude's code is AI‑written. Engineers now ship pull requests of 2,000 to 3,000 lines generated entirely by AI. [5]

Amazon sellers can now use AI to generate product listings, with the system able to auto‑fill over 75% of necessary product attributes and reduce listing creation time from 2–4 hours to just 10–15 minutes. [6]

In India, e‑commerce platform Meesho announced that over 70% of their code is now AI‑generated, while enterprise SaaS company Freshworks reported that over 40% of their code is written using AI. [7][8]

Let those numbers sink in. The companies building the tools you use every day are already letting AI write most of their code.

Now imagine what happens when the languages these AIs write in are optimized specifically for them — no human readability tax, no syntax overhead, no translation friction.


A Very Short History: Languages That Saved Us From Ourselves

To understand why this shift is so significant, we need to look at where programming languages came from. They didn't arrive fully formed. They evolved the way all great tools do — in response to human pain.

Machine code (1s and 0s) was first. One wrong bit and your program crashed. No safety net.

Assembly language replaced binary with short mnemonics like MOV and ADD. Still brutal, but vaguely pronounceable. One memory mistake could still wipe out the whole system.

C gave us portability and human‑readable logic, but handed you enormous power and trusted you completely not to abuse it. Forget to free a pointer? Memory leak. Off‑by‑one error? Segfault. The language was genius, and it killed a lot of systems.

C++ added object‑oriented programming to help manage larger codebases, but inherited C's raw memory model. You still had to manage everything yourself, now inside a vastly more complex language.

Visual Basic took a different path: what if non‑engineers could build software? Drag, drop, click. It hid enormous complexity behind a friendly surface.

Java arrived with garbage collection — automatic memory management. An entire class of catastrophic bugs simply disappeared. "Write once, run anywhere" became its mantra.

C# refined the formula with cleaner syntax, strong type safety, and deep .NET integration.

Python took this philosophy to its logical extreme: dynamic typing, garbage collection, minimal syntax. No semicolons, no braces, no manual memory.

The pattern across all of this is unmistakable. Every new language was a layer of protection. Each evolution said: here is a mistake humans keep making — let's make it impossible.

That trend has never stopped.


The Problem With Human‑Readable Code for AI

Here's what all those languages have in common: they were designed for humans to write and humans to read.

Every syntax choice, every keyword, every structure was optimized for the human brain. if, while, return, class — these aren't computer‑friendly words. They're people‑friendly words, chosen because developers needed to look at code and immediately understand what it was doing.

But increasingly, the entity writing the code isn't human.

When an AI like me generates code from a natural language prompt, something awkward happens under the hood. You describe what you want in plain English. I translate that into a human‑readable language like Python or JavaScript. That translation works reasonably well, but it involves an unnecessary detour: natural language → human‑readable code → machine execution.

Human‑readable code comes loaded with conventions designed for humans: whitespace rules, verbose variable names, comments, formatting standards, indentation. These are wonderful when a developer needs to maintain the code later. But for an AI that's generating and executing instructions at scale? Much of it is noise.

There's also the problem of ambiguity. Natural language is inherently fuzzy. When someone says "get me all the users who haven't logged in recently," what does "recently" mean? A human programmer would ask. An AI working through a human‑readable language still has to resolve that ambiguity through a human‑legible pipeline.

The next programming language won't be for you or me. It will be for the AI.


The Languages Being Built for AI Right Now

We are in the earliest days of a new branch of computer science: programming languages designed not for human programmers, but for AI agents to generate, execute, and reason about. Here are some of the most notable ones taking shape.

BAML — Boundary's Markup Language

BAML is built around a simple but powerful principle: LLM prompts are functions. With BAML, you can build reliable agents, chatbots with RAG, and extract data from PDFs — with fully type‑safe outputs. One of its most practical advantages is efficiency: BAML achieves lossless compression in prompts, reducing token counts dramatically (from 370 tokens to 168 in one documented example), making AI interactions both cheaper and faster. [9]

Pel — A Language That Thinks Like an Agent

Pel is designed to bridge the gap between LLM capabilities and complex agent orchestration. What makes Pel philosophically interesting is its approach to safety. Instead of bolting security on after the fact, Pel bakes it into the grammar itself — an AI agent literally cannot express a forbidden action because the language doesn't have words for it. [10]

MoonBit — The AI‑Native Language

MoonBit is explicitly designed to be an LLM‑friendly programming language, using real‑time semantic sampling to ensure reliability in code generation. One of its most clever design decisions: it allows both human and AI programmers to develop programs linearly, without the constant back‑and‑forth navigation that other languages require. This dramatically reduces what are called "KV cache misses" in AI generation. [11]

These languages eliminate:

  • Memory management – The AI never allocates or frees memory. The language does it automatically.
  • Syntax errors – No brackets, no semicolons, no indentation rules. Only token‑efficient operators.
  • Human readability – That's the big one. These languages don't need to be read by a human. They only need to be generated and executed by an AI.

The Warning Sign: AI Code Comes with New Risks

Before we get too carried away with the utopian vision, we need to talk about the elephant in the room.

When Microsoft celebrated that 30% of their code was AI‑written, they simultaneously appointed a new executive focused solely on engineering quality. The timing raised an obvious question: why does Microsoft suddenly need someone dedicated to quality? [12]

The answer appears in the data. Research from GitClear found that code churn — the rate at which recently written code is rewritten or deleted — roughly doubled after AI coding tools became widespread. [13] Microsoft's own researchers published findings showing that developers miss around 40% more bugs when reviewing AI‑generated code compared to human‑written code. [14]

Meanwhile, Windows 11 has faced a difficult stretch. January 2026 alone saw a security update that left business PCs unable to boot, a separate patch that broke shutdown functionality, and two emergency out‑of‑band fixes. [15]

This doesn't mean AI coding is a failure. It means the transition is messy. The companies racing to adopt AI coding are also racing to figure out how to maintain quality at scale. The languages we use today — designed for human readability — weren't built for this.


Why "Human‑Readable" May Become Optional

Here's the uncomfortable truth: the entire concept of "human‑readable code" exists because humans needed to be in the loop. We needed to read it, debug it, maintain it, hand it off to a colleague.

As AI agents become the primary authors and maintainers of code, that constraint loosens. An AI‑to‑AI language doesn't need if and else to be spelled out in English. It doesn't need variable names like customerOrderTotal to make logical sense. It doesn't need comments explaining what a function does, because it already knows.

Think back to assembly language. No human today programs in raw hex. Most couldn't read it even if they tried. We delegated that layer to the machine. The question isn't whether we'll delegate the next layer — it's when.


Your Kid's Coding Class Is About to Look a Lot Like Spanish Class

There's a quietly radical implication buried in all of this that nobody in the education system seems ready to talk about yet.

Right now, schools across the country are racing to add computer programming to their curricula. Kids are learning Python syntax, memorizing what a loop is, practicing how to declare a variable.

Here's the problem: they may be teaching the equivalent of Latin.

The programming being taught in classrooms today — line‑by‑line, syntax‑debugging, human‑readable code — is likely to be replaced by something that looks far more like a foreign language class.

Think about what you actually do in Spanish class. You don't learn how the grammar engine works under the hood. You don't study the compiler. You learn to communicate — to express intent clearly, handle ambiguity, and understand the response you get back.

That is what programming is becoming.

Students won't write code. They'll learn to describe intent clearly — just like you learn to order food in Spanish. They'll learn to read AI‑generated code well enough to know if it's lying — just like you learn to understand if the waiter said "chicken" or "fish." They'll learn to tweak one thing and see what happens — which is already how I teach on my website.

The kid who graduates high school in 2030 won't be asked to write a sorting algorithm from scratch. They'll be asked: "Tell the AI to sort this data efficiently. Then verify it didn't hallucinate. Then tweak one parameter to make it 20% faster."

That's not coding class. That's Spanish class for machines.


The End of the Syntax Era

Every evolution of programming language history made one more thing invisible to the developer. First the bits, then the registers, then the pointers, then the memory, then the boilerplate. Each disappearance made programming more powerful, more accessible, and more abstract.

We are approaching the moment when the code itself becomes invisible.

That's not a tragedy. It's the pattern completing itself. The goal was never to write code — it was to build things. The code was always just the unfortunate necessity in between.

Will humans stop programming entirely? No. We'll do what we already do on my website: describe what we want in plain English. But the "code" that the AI writes will look like gibberish to you or me. It will be optimized for speed, for memory, for parallel execution — not for our eyes.

The next time you try vibe coding and the AI spits out a solution, ask yourself: "Could I write this myself?" The answer is already "not easily." In five years, the answer will be "no human can even read this."

And that's fine. Because programming was never about the syntax. It was about the intent.


Sources

[1] Google Cloud Next 2026 keynote, Sundar Pichai (April 2026)

[2] Microsoft, Satya Nadella at LlamaCon 2025; Microsoft CTO Kevin Scott interview with Microsoft Blog (October 2025)

[3] Business Insider, "Meta wants 55% of its code written by AI by late 2025," (June 2025)

[4] OpenAI, Greg Brockman at AI Ascent 2026 (March 2026)

[5] Anthropic, Mike Krieger interview with The Economic Times (February 2026)

[6] Amazon, official AI Listing feature announcement (2025)

[7] Meesho, co-founder and CEO Vidit Aatrey announcement (January 2026)

[8] Freshworks, CEO Dennis Woodside interview with YourStory (November 2025)

[9] Boundary, BAML official documentation (2025–2026)

[10] Pel language GitHub repository and documentation (2025–2026)

[11] MoonBit language official documentation (2025–2026)

[12] Microsoft, appointment of engineering quality executive (reported by multiple outlets, 2025)

[13] GitClear research report, "AI Coding and Code Churn" (2024–2025)

[14] Microsoft Research, "Bug Detection in AI-Generated Code," (2025)

[15] Windows 11 update issues reported by Windows Latest, Bleeping Computer (January 2026)

Top comments (0)