When Natural Language Becomes a Programming Language

A developer who goes by the handle “Whale” wrote a post on Brunch (a Korean publishing platform) that really resonated with me. To the question “So are all the developers about to disappear?” his answer is that the very definition of “development” is changing.
What makes the piece interesting is that it places the arrival of AI coding tools within the history of how programming languages have evolved.

An LLM Is a Compiler for Natural Language

Programming languages have steadily moved closer to human speech. From machine code, which could only express switching circuits on and off, to assembly, which handles operations at the register level, to C, which manipulates the CPU and memory directly, to high-level languages that express abstract logic—each step brought us one notch nearer to the way people actually talk.
And now, with the arrival of LLMs, that abstraction has taken another leap. Natural language itself—Korean or English—has become a programming language. Just as C has a C compiler and Java has a Java compiler, natural language now has a compiler of its own: the LLM. Tools like Claude Code, Codex, and Kiro are, in effect, IDEs for natural language.
The reason this analogy is so apt is that it also explains the limits of LLMs.

What Makes It Fundamentally Different from a Conventional Compiler

A conventional compiler produces the same output for the same input. If the result differs, that’s a bug—either the code is wrong or the compiler is wrong. The target of debugging is clear.
An LLM does not always produce the same output for the same input, because probability is in the mix. It’s even ambiguous whether that counts as a bug. So to get the result you want reliably, you have to convey your intent with real precision—leaving no room for doubt.
As the author puts it, “programmers around the world are, right now, in the middle of settling on coding conventions for natural language.” Everyone is exploring which way of phrasing instructions makes an LLM produce the most deterministic—that is, predictable—code.

A Hidden Opportunity for Korean Developers

Here is where a long-standing handicap for Korean developers finally lifts.
Programming languages were built by borrowing English words and English grammar. For a native English speaker, a thought turns into code almost directly. The sentence “if the calculation is correct, add ten points to the total score” becomes code with barely any change.

For a native Korean speaker, there’s an extra step: converting the thought “if the calculation is correct, add ten points to the total” into English. You have to find the right English words and second-guess your grammar. Just naming a variable burns energy.

With LLMs, that barrier is gone. You can think in Korean and give instructions in Korean. There’s surely a translation layer somewhere underneath, but from the developer’s point of view, for the first time they can code in their mother tongue.

The Essence Doesn’t Change

This is where the author makes his sharpest point.
To code in natural language, you ultimately have to be clear about what you want. You define a very detailed spec in writing, check the requirements for contradictions, and break the work into small units to build one at a time.
“Wait—doesn’t this feel familiar? Isn’t this just… coding?”
Exactly. Grasping the intent behind a plan precisely and capturing it in code. Talking with planners and designers to pin down what they actually want. Breaking functions into small pieces so the intent is clear from reading the code alone. This is what a good developer has been doing every single day. The layer of abstraction has risen to the level of natural language, but the essence is unchanged.

The same goes for the flood of AI coding features arriving now. MCP connects other services through a common standard; Skills imports a well-built function library; an Agent separates the roles of each piece of logic; Multi-Agent is asynchronous parallel processing; and Orchestration is about keeping the main thread from getting bogged down.
To a developer, these are all familiar concepts. The only difference is that they’re written in natural language.

The Barrier to Entry Drops, and Good Developers Grow Scarcer

Every time the level of abstraction in programming languages has risen, the same pattern has repeated. When the hurdle of syntax falls, the number of users explodes and the number of services surges. But not all of those users became good programmers, and not all of those services became good services.
Two things have always mattered: the ability to find the real problem worth solving within a business domain, and the ability to work through that problem logically. This didn’t change in the age of machine code, or C, or Python, and it won’t change in the age of natural-language coding.
The irony is that the fewer people write code directly, the rarer it becomes to find someone who can do real debugging at the system level—the kind that natural-language debugging alone can’t solve. The barrier to entry has dropped, but finding a good developer will, if anything, get harder.

What “Just Make It Happen” Really Means

The end of the post is funny and painful at once.

“Come to think of it, the higher-ups were already doing natural-language programming all along. Say the word—‘Make it happen!’—and human intelligence figures out the context on its own, infers and fills in the ambiguous parts, and spits out a result. Sure, it hallucinates now and then, and when it blows past its context window it forgets what you said earlier.”

Give vague instructions and you get vague results—whether you’re talking to an LLM or to a person. The one difference is that with an LLM, you could maybe “make people pay more for being vague.”
In the end, the heart of it is the same even in the age of natural-language coding: the person who defines the problem precisely wins, and the person who gives sloppy instructions gets sloppy results. The tool has changed; the nature of the work has not.