Is English the new
programming language?

The oldest trend in computing just took its biggest step

Programming history is one long retreat from the machine. Assembly abstracted raw opcodes. FORTRAN and C abstracted assembly. Python abstracted memory management. SQL abstracted how in favor of what. Each step traded fine-grained control for expressiveness, and each step was denounced by the previous generation as "not real programming." Natural-language programming is the logical endpoint of that retreat: the most expressive, least controlled layer possible.

Viewed that way, "English as a programming language" isn't a gimmick — it's the next rung on a sixty-year-old ladder. And the historical pattern is consistent: the new layer doesn't eliminate the layers below it; it changes who needs to touch them, and when. C didn't kill assembly; it confined assembly to the moments that matter. The same will be true of code.

Why formal languages exist at all

But there's a crucial difference between this abstraction step and every previous one. Compilers are deterministic: the same C produces the same assembly, every time, and when it doesn't do what you meant, the defect is in your understanding, not in a probability distribution. Formal languages were invented specifically because natural language fails at precision. "Delete the user's old records" — older than what? Soft delete or hard? What happens to foreign keys? In a courtroom or a requirements document, that sentence spawns a meeting. In a programming language, it can't be written without answering the questions.

Every natural language sentence underdetermines its implementation. Human programmers historically resolved that gap in design discussions; the language then forced the resolution to be explicit. When English becomes the source code, the gap doesn't disappear — it gets resolved silently, by a model, using statistical priors about what people usually mean.

A compiler that guesses

Treat the LLM as a compiler and its properties become starkly unusual: it is non-deterministic (same prompt, different programs), version-unstable (model updates silently change "compilation"), context-sensitive (output depends on what else is in the window), and persuadable (its behavior can be altered by the content it processes). No engineering organization would accept a C compiler with those properties — yet that's the toolchain we now ship through.

The mature response isn't to reject it. It's to compensate the way engineering always compensates for unreliable components — by surrounding them with verification:

• The artifact is the contract. You can't fully trust the translation, so you verify the result: tests, types, linters, security scanning on the generated code, every time.
• Pin and regression-test your "compiler". Model versions belong in your reproducibility story the way toolchain versions do.
• Keep prompts in version control. If English is source code, it deserves source control, review, and diffing — prompts scattered in chat histories are the new untracked binaries.

When the program is prose, prose is attack surface

Here's the part the "English is the new code" celebrations skip: if natural language is executable, then natural language is injectable. We spent thirty years learning to separate code from data — parameterized queries, output encoding, CSP. Natural-language programming un-learns it in one stroke: to an LLM, instructions and content arrive in the same channel, as the same kind of token.

• Prompt injection is SQL injection for the English runtime — hostile instructions hiding in documents, web pages, commit messages, or user input that the model processes.
• The ambiguity gap is a vulnerability class. "Validate the input" becomes a regex that almost works. "Restrict access to admins" becomes a check on the client side. The prompt reads securely; the program isn't. Plausible-but-wrong is precisely what generated vulnerabilities look like.
• Provenance gets murky. When a system was built from prompts, who decided the password reset flow works that way? The prompt author? The model? A training example? Auditing needs answers natural language doesn't record.

The skill that replaces syntax isn't prompting — it's specifying

"Prompt engineering" as a bag of incantation tricks is already fading; models stopped needing the magic words. What remains, and what was always underneath it, is an old and rare skill: the ability to state a problem completely. Inputs, outputs, invariants, edge cases, failure behavior, security constraints. The people who get extraordinary results from coding agents aren't whispering to the model — they're handing it the kind of specification a good senior engineer would hand a contractor.

That's also why "everyone can program now" is only half-true. Everyone can generate software now. Programming — deciding precisely what should happen in every case that matters — turns out to be the part that was never about syntax. The syntax was just where the decisions were stored.

So, is English the new programming language?

Yes — in the sense that it's now the primary interface through which humans cause software to exist, and the leverage point where quality is decided. No — in the sense that it will never be where correctness lives. English is becoming the new source; compiled artifacts in Python, Go, and TypeScript remain the new binary — and like every binary, they need verification precisely because no human is reading them closely anymore.

The stack didn't get shorter; it got taller. And the oldest rule of the stack still holds: trust at the top must be earned by checks at the bottom.