The English Trap

Most people would not review their own commercial lease. They’d hire a lawyer. The lease is written in English. Every word in it is a word they know. But they understand, intuitively, that legal English is not conversational English. It is a formal system wearing English as a disguise. The words mean what precedent says they mean, not what a reasonable person would assume on first read. “Best efforts” and “reasonable efforts” sound interchangeable. They are not. The distinction has case law behind it. People get this about contracts.

They do not get this about prompts.

I’ve started calling this the English Trap.

When you type instructions to an LLM, you are not having a conversation. You are programming a computer. The interface happens to accept natural language. This is convenient and misleading in equal measure. The model will interpret your words, but it will interpret them as a probabilistic system optimizing for the most likely completion given your input. Not as a colleague who shares your context, your assumptions, and your intent.

“Summarize this document” is an instruction. It is also wildly underspecified. Summarize how? For whom? How long? What should be preserved and what can be dropped? What tone? A human colleague would ask clarifying questions. The model will not. It will make choices. Confidently. Without telling you it made them. You’ll get a summary and it’ll look fine and you will not realize that on the next run, it will make completely different choices, because you left every decision up to a system that resolves ambiguity by rolling dice.

The Helpful Model Problem

This is where the trap gets sharp. The model is aggressively helpful. It wants to complete your request. If your request is ambiguous, it fills the gaps with its best guess. If your request is contradictory, it picks one interpretation and runs with it. If your request is vague, it will generate something plausible every single time.

Plausible is not consistent. Plausible is not correct. Plausible is “this looks right if you don’t check too carefully.” And because natural language feels intuitive, people don’t check carefully. They assume the model understood them the way a human would.

A poorly defined task is a poorly defined task, regardless of whether you hand it to a person or a language model. The difference is that a person will push back. They’ll say “what do you mean by that?” The model will salute and march off a cliff with a smile. Your friendly imprecision will be eagerly seized upon by a system whose entire reward structure is oriented toward producing a response, any response, that pattern-matches as helpful.

The Ceremony Is the Point

When someone tells you to be specific, to enumerate edge cases, to restate what matters, they are not being pedantic. They are telling you to do the equivalent of hiring a lawyer for your contract.

The ceremony people resist is precisely what separates reproducible results from demo-quality results. Specifying what format you want. Saying what to do when the data is missing or the request is ambiguous. Restating the important constraints more than once.

None of this is complicated. All of it is tedious. And all of it is necessary the moment you care about the output being consistent.

The resistance is always the same. “I know how to write instructions.” You do. In English, for humans, who share your world model. You do not know how to write instructions for a probabilistic completion engine that will exploit every ambiguity you leave on the table. Those are different skills. The second one just happens to use the same words as the first.

What Precision Looks Like

This doesn’t mean writing prompts in legalese. It means being specific where it matters.

Instead of “write a professional email,” you write “compose a 3-paragraph email. First paragraph: state the issue. Second paragraph: proposed resolution with timeline. Third paragraph: next steps. Tone: direct, no pleasantries. Do not include a subject line.”

Instead of “analyze this data,” you write “extract the top 5 items by revenue. For each, return the item name, revenue figure, and percent change from last period. Format as a markdown table. If data is missing for any field, output ‘N/A’ rather than estimating.”

The second versions take longer to write. They produce the same output every time. That’s the trade. And it’s the same trade a lawyer makes when they write “shall deliver within fourteen (14) calendar days of execution” instead of “deliver it soon.”

Before You Type a Word

This gets more important when you’re using agents or longer-form workflows. Every tool, memory file, project setup, or configuration that an AI assistant offers you exists for a reason. Experts set those up. Use them.

More important than tooling is thinking. Before you start, have a complete picture of what solved looks like. Not a vague sense of direction. A destination. What does the output contain? What does it not contain? What would make you reject it?

That’s your success criteria. Agents in particular need this. An agent without a clear success condition will iterate forever, or it will stop at “plausible” and declare victory. When you tell a system what done looks like, it can actually converge on a solution rather than drift toward one that merely looks right. Vague goals produce vague results. Sharp ones don’t.

It’s Specification

The fundamental mistake is treating the LLM interaction as communication. It is not communication. It is specification. You are describing exactly what you want from a system that will take you at your word, fill in every blank you left, and hand you something that looks correct.

The English Trap is thinking that because you’re writing in English, you’re doing something you already know how to do. You’re not. You’re doing something new that happens to look like something familiar. The sooner you treat it as a skill with its own rigor, the sooner your results stop being “wildly inconsistent” and start being useful.