Zuloma·EssaysWhy English can't be wrong
Essays

Why English can't be wrong

Natural language is ambiguous and tolerant of contradiction — virtues in conversation, defects in instruction. As generation gets cheap, the scarce thing is no longer producing the artifact. It's having something in the chain that can refuse it.

July 10, 2026·9 min read

In January 2023, Andrej Karpathy posted a line that got quoted into the ground: "The hottest new programming language is English."

It was a good line because it was mostly true, and it was mostly true in a way that took two years to become uncomfortable. In February 2025, Karpathy named the consequence himself. He called it vibe coding: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." The operational detail was the part worth reading twice: "I 'Accept All' always, I don't read the diffs anymore."

Merriam-Webster picked the term up in March 2025 as a slang and trending expression. Collins English Dictionary named it Word of the Year for 2025.

Sit with that for a second. A dictionary — an institution whose entire function is to fix meanings firmly enough that a usage can be checked against them — gave its highest annual honour to a practice defined by not checking the output. That is not a tech in-joke that escaped containment. It is a culture-level admission about where the work has moved.

The interesting question is not whether vibe coding is good or bad. It is what the two years between those two quotes reveal about English. English got promoted to an instruction language, and the first thing it did in the job was stop verifying its work. That is not a failure of discipline among the people using it. It is a property of the language itself.

The defect is the virtue

English can't be wrong.

Not "is rarely wrong." Can't be. There is no operation you can run on an English sentence that returns false. You can disagree with a sentence, misread it, find it useless, or discover later that the world did not match it. But the sentence itself never fails. It always parses. It has no mechanism for rejecting itself.

Consider three instructions, each of which sounds complete.

"Make it faster." Faster in what sense? Latency — the time one request takes? Throughput — the number of requests handled per second? Perceived speed — the time until something appears, which is a different thing again? Cost per unit of work? These are not shades of one idea. They trade against each other. Optimising for throughput routinely makes latency worse. A response to "make it faster" can be a technical success and a complete failure of the instruction.

"Retry failed requests." This sounds like a rule. It is a question wearing a rule's clothes. What is a failed request? A request that was rejected, or a request whose response never came back? Those are different events with the same appearance from the outside. If the original request succeeded and only the acknowledgement was lost, the retry does the work a second time. Charge the card twice. Ship the order twice. The sentence is silent on the only thing that matters, and it is silent while sounding definitive.

"Only administrators can delete accounts." Who counts as an administrator — the role, or anyone who can currently assume the role? Does the authority delegate, and if so, is the delegate an administrator for the purposes of this sentence? What happens to a session already open when someone's permissions are revoked mid-flight? Every one of those is a decision the sentence appears to have made and has not made.

None of these are sloppy sentences. They are ordinary ones. Natural language is built to work like this. Ambiguity is compression — a speaker leaves out what the listener can reconstruct, and the reconstruction is usually right. Context does the rest of the work. Contradiction is tolerated because a competent listener repairs it silently and moves on, and both parties experience this as understanding rather than as guessing.

Those are extraordinary properties in conversation. They are defects in instruction. The job of an instruction is to eliminate futures. A sentence that permits four incompatible outcomes has not instructed anything. It has gestured at a region and let the reader pick a point inside it.

This is not confined to software. "Demand will be strong next quarter" is a forecast that cannot be wrong, because strong has no threshold — which is precisely why it survives the quarter it describes. "Approve discounts on a case-by-case basis" is a policy that cannot be violated. "We'll prioritise the highest-impact work" is a plan that is compatible with every possible allocation of effort. These sentences all pass the meeting. None of them can fail, and that is what makes them worthless as constraints and popular as language.

What a formal system actually buys

A formal system begins exactly where that tolerance ends.

A function is type-correct or it isn't. A transaction satisfies its constraints or the database declines the write. A schema validates the record or rejects it. A production plan is feasible against capacity or it is not feasible, and the solver will tell you which. A test passes or it fails.

The conventional story about formal systems is that they are precise. That's true, and it's not the point. Precision is the mechanism. The product is refusal.

That is the property English does not have and cannot be given. A type system is not valuable because it describes your intent elegantly. It is valuable because there exist programs it will not accept. Take away the ability to reject and you have not weakened the system — you have deleted it. A type system that accepts everything is a comment. A capacity constraint that never binds is a note in the margin. A test that cannot fail is decoration.

The economics inverted, and nobody moved

For most of the history of knowledge work, the artifact was the expensive part. Writing the code, building the model, drafting the document, producing the plan — that was where the hours went. Checking was comparatively cheap, and mostly implicit: producing the thing forced you to think it through. Slowness was doing verification work off the books. You couldn't write the paragraph without having decided what you meant.

That coupling is gone. Generation is now close to free, and the artifact arrives in seconds.

The checking did not get cheaper. It is the one part of the pipeline whose cost is unchanged — so as everything around it collapsed in price, its share of the total went to nearly all of it. The scarce thing is no longer the ability to produce the artifact. It is the existence of something willing and able to say no to it.

And here the two properties collide. An instruction that cannot be wrong cannot be checked. An instruction that cannot be checked cannot be trusted at volume.

Volume is the word doing the work. One generated draft is fine; a person reads it, and their judgment is the check. A thousand generated drafts cannot be read, and the human check silently stops happening — not by decision, but by arithmetic. This is the honest content of "I don't read the diffs anymore." It isn't laziness. It is what happens to any manual verification step when the thing being verified starts arriving faster than a person can absorb it. The check doesn't get overruled. It gets outrun.

The complication, stated honestly

The obvious reading of all this is "be precise, always, from the start." That reading is wrong, and it is wrong in an expensive way.

Ambiguity is genuinely useful early. Vague intent is how work starts. "Something's wrong with how customers renew" is not a specification and could not be one — nobody knows enough yet to write it. That sentence's vagueness is what lets four people with different expertise stand in front of it and each see a different tractable problem. Premature precision kills that. A specification written before anyone understands the thing does not capture the problem; it forecloses on it. Formalising too early converts an open question into a wrong answer with good posture.

So the claim is not that formality should come first. It's that the vague thing has to eventually land somewhere that can reject it. Exploration is a phase, not a destination. The sentence gets to stay soft while it is still finding its shape, and then it has to meet something with the power to refuse it — a schema, a type, a constraint, a feasibility check, a test, a number with a threshold attached.

The failure mode of this particular moment is that people skip that landing, because the output already looks finished. Fluency used to be weak evidence of care. It cost something to produce a clean, confident, well-structured artifact, and that cost was mostly thinking. It costs nothing now. The surface signals a reader spent decades learning to read as competence have been decoupled from competence entirely, and human pattern-matching has not caught up.

Where the leverage went

If generation is free and refusal is scarce, then leverage sits with whatever holds the constraints.

Not with the prompt. The prompt is English; it will accept anything. Not with the model, whose fluency is precisely the reason its output slides past the check. The leverage is in the schema that rejects the malformed record, the type that will not compile, the constraint the solver cannot satisfy and says so, the test that fails, the acceptance threshold defined before the result arrived rather than after.

That work is unglamorous and it is where the value moved. Anyone can now produce a plan. The scarce skill is stating in advance what would make it infeasible. Anyone can produce a forecast. The scarce skill is naming the number that makes it wrong, before it is convenient to know. Anyone can generate the code. The scarce skill is building the thing that won't accept it.

Karpathy's 2023 line was right. English is the hottest new programming language, and 2025 canonised what that costs. English will accept anything you tell it. So will the model. Somewhere downstream, something has to be capable of saying no — and if nothing in the chain can, then nothing was verified. It was only produced.


Sources

  • Karpathy, A. (2023). "The hottest new programming language is English." X/Twitter, 24 January 2023.
  • Karpathy, A. (2025). Post coining "vibe coding." X/Twitter, February 2025.
  • Merriam-Webster. (2025). "Vibe coding," Slang & Trending listing. March 2025. merriam-webster.com
  • Collins English Dictionary. (2025). Word of the Year 2025: "vibe coding." Announced 6 November 2025. collinsdictionary.com
  • BBC News. (2025). "Vibe coding" named word of the year by Collins Dictionary. 6 November 2025. bbc.com
  • The Independent. (2025). What does vibe coding mean? The AI term crowned Collins word of the year. 6 November 2025. independent.co.uk
Share
← All EssaysZuloma Home
The Dispatch · Sundays

One letter. Every Sunday.

A single, considered email. One essay, one idea, one book worth your attention. No tracking, no clickbait, no “10 best” anything.

Free · Unsubscribe in one click