By Pavan Kumar T V · 21 June 2026

Update: this turned into a series. Part 2 takes on the best rebuttal, that code has the same one-keystroke flaw, and Part 3 asks the deeper question: why do we need a language at all?

I'd just finished a chunk of work in the terminal and told Claude Code to push to remote. Get the commits up to GitHub. I thought that's what I'd typed, hit enter, and went back to the line.

It read push to remove.

One key. T had become V. "Ship this" had become "delete this," and the agent didn't blink, because push to remove is a perfectly sensible thing to ask. It took my typo as my intent and went to work on it. It had no way not to.

I sat with that for a second, and it cracked open something I'd been uneasy about for a while. Everyone keeps saying English is the new programming language. After that one keystroke, I don't buy it. Let me walk you through where the idea falls apart, because it goes deeper than typos.

The thing nobody says about real languages

Start with what a programming language actually does for you, quietly, all day.

It fights back. Misspell a variable and the compiler stops you. Forget a bracket and the parser refuses. Hand a string to a function that wants a number and the whole build collapses before anyone sees it. Every language you've ever cursed at is a dense mesh of tripwires, and almost every careless thing you do trips one before it reaches a user.

That's not the language being annoying. That's the language doing its job. Compilers are built on a simple, brutal principle: a random mistake should produce an error, not a different working program. The space around any correct line of code is mostly broken code, and broken code gets caught.

Now look at what happened to me. My mistake didn't produce an error. It produced a different valid instruction. There was no tripwire, because in English there are almost none. The space around any correct word isn't full of errors waiting to be caught. It's full of other perfectly correct words, each meaning something else entirely. You don't trip and fall. You step cleanly onto the wrong stone and keep walking.

Why this is structural, not bad luck

Engineers have a name for the distance between two messages: how many single edits turn one into the other. Build a good system and you push the valid messages far apart, so it takes a pile of errors stacked together to turn one real message into another. That gap is what lets your phone survive a noisy signal and your drive survive a flipped bit. Distance is forgiveness, engineered in.

English does the opposite, and it does it on purpose. It packs meaning tight. The words we reach for when we boss machines around are blunt, high-consequence verbs, deploy, delete, push, drop, merge, revert, and they live in a crowded part of the language. You don't need many of them to be one letter apart for this to bite. You need one, on the wrong day. Remote and remove are a single letter apart and mean opposite things. Ship and skip are too. Each is a real word with its own life, so the typo doesn't break anything, it just quietly means something else. We built this language for two humans who share a room, watch each other's faces, and cut in with "wait, you mean delete?" the instant something sounds off. We did not build it to be fired one-way at a literal machine that executes the most probable reading and never looks up.

And here's the part that should bother you: an LLM is, at its core, a probability engine over exactly that crowded space. It doesn't pause on a near-miss and wonder which neighbor you meant. It takes the word in front of it, decides it's plausible, and runs. The slip isn't noise it strains out. To the model, the slip is the message.

Then I noticed the bigger crack

Typos are the cheap version of the problem. The expensive version is that English is loose about logic itself.

There's a whole line of research that ran straight into this, and it kept getting louder through 2025. Ask a model to reason through a hard problem out loud, think step by step, and it wanders. It quietly drops a constraint three sentences in. It writes "therefore" between two claims that don't actually connect. It sounds airtight and lands wrong. So researchers tried a different move: stop feeding the model loose prose and give it structure with edges instead.

Training with Pseudo-Code for Instruction Following (May 2025) states it directly: models "continue to struggle with following relatively simple and unambiguous instructions," especially once the instruction has any compositional structure. Their fix is to have the model re-express your English instruction as pseudo-code first, then act on the pseudo-code. From your side nothing changes, you still type English, but converting it into explicit steps and conditions raised instruction-following accuracy by up to 19% on some benchmarks. A June 2025 survey on reasoning for code makes the same point from the other side: a program doesn't describe reasoning, it embodies it, and it's judged by whether it runs, not by how plausible it sounds. The idea isn't new. It goes back to PAL and Program of Thoughts in 2022, which showed models decompose a problem fine in English and then botch the solving step, so you hand that step to a Python interpreter. Three years of work, same result: logic written as code holds up where logic written as English slides.

Sit with why that works and it stops being a quirk and starts being the whole point. You cannot write "if the user is sort of an admin" in code. You have to say what admin is, a value, a check, a hard line, and the act of writing it drags every fuzzy assumption into daylight and makes you commit. English will happily let you keep the fuzz. Say "deploy this to all the active regions" and the sentence feels complete, while underneath it hides a dozen unasked questions. Active measured how? Measured when? The one that's draining, in or out? The one that's up but failing health checks? You don't notice the gaps, because English is built to glide over them. Write the same instruction as code and every gap turns into a line you're forced to fill or a bug you're forced to stare at.

That's not a flaw in English. It's the thing English is best at: nuance, persuasion, ambiguity held open on purpose, meaning that bends to fit who's listening. The exact flexibility that makes it a glorious human language makes it a treacherous specification.

So where does that leave the slogan

Don't mishear me. I talk to my agents in English all day, and I'm not stopping.

English is the interface. It's the best on-ramp ever built for intent: for sketching the shape of what you want, pointing a direction, saying "build me a push-to-deploy flow that respects feature flags." That's a great sentence to start from.

But it's a start, not the artifact. The moment intent has to become behavior, precise, repeatable, something you can actually verify, it has to leave English and grow edges. A schema. A type. A test. A line of code that can't quietly contradict itself.

The slogan's whole appeal is that it sounds like the wall came down, like anyone who can write a sentence can now command a machine. But the wall was never the syntax. Nobody struggled with semicolons. They struggled with precision, with being pinned down to say exactly what they meant, with nowhere to hide. English pulls out the semicolons and hands you none of the precision. It just lets you feel exact while staying vague, and then passes that vagueness to a machine that will commit, fully and confidently, to whatever your fingers happened to type.

A real language would have caught my slip at the door. English had a synonym for disaster sitting one letter off, spelled almost the same, and dressed it in the face of my intent.

So talk to your machines in English. It's the best way we've ever had to tell them what we want. Just don't mistake telling them for instructing them. The instruction still has to become code, and the contract always did, and still does, live there.