I write prompts in English even when I want the output in another language.
That might sound like a cultural statement. It isn’t. It’s a tooling decision.
English is the control language of the current AI stack. It’s how the models were trained, how the docs are written, how tool interfaces are designed, and how most prompt recipes are shared. If I want tight control, low friction, and fewer surprises, English gets me there faster than any other option.
This is a personal, pragmatic choice—not a universal rule. But it’s one I keep returning to because it buys me speed, clarity, and reliability.
English Is the Control Layer, Not the Content
When I prompt, I separate control from content.
- Control is: constraints, format, tone, steps, edge cases.
- Content is: the final text, often in another language.
English is the best control layer I’ve found because most models “think” in English-adjacent space. That’s where the strongest gradients live: “be concise,” “use bullets,” “avoid jargon,” “write like a memo.” These aren’t magical phrases, but they’re extremely well represented in training data.
So I treat English like the interface language of a machine. I’m not composing a poem; I’m issuing instructions. And I want those instructions to be as close as possible to the model’s native control vocabulary.
Speed Matters More Than Eloquence
Prompting is iterative. The faster I can type and refine, the more I can explore before the context goes stale.
English helps me move fast in a few very practical ways:
- I can type in all lowercase without feeling “incorrect.”
- I don’t need to switch input methods.
- I don’t worry about special punctuation or spacing rules.
There’s also a small but real ergonomics win: in many chat UIs, Enter sends the message. When I’m using an input method editor (IME), Enter often confirms a character conversion—and I’ve accidentally sent half-finished prompts more times than I want to admit. English keeps the whole loop smooth: type, send, revise, repeat.
That speed advantage compounds. A prompt that takes 20 seconds instead of 40 doesn’t just save time—it encourages me to try twice as many variations.
Ambiguity Is a Model Problem, Not a Grammar Problem
Every language is ambiguous. English isn’t uniquely clear.
But for LLMs, ambiguity is shaped by training density. English has an overwhelming amount of prompt-like training data: product specs, instructions, issue templates, engineering docs, procedural checklists. That means English instructions tend to be more predictable in how the model responds.
When I write in another language, I sometimes feel like I’m translating not just words but instructional conventions. The model might still understand, but the mapping is fuzzier. The risk isn’t that the language is ambiguous; it’s that the model’s learned associations are thinner.
So I use English to reduce interpretation variance. The output might still surprise me, but at least the control signal is consistent.
Tooling Speaks English (and So Do My Prompts)
The modern prompt stack is full of structured objects:
- JSON and YAML schemas
- function names and arguments
- code blocks
- Markdown for formatting
This is all English-coded territory. Even when I’m prompting for non-English output, the scaffolding is in English: “Output as JSON,” “Use these keys,” “Follow this schema.”
That scaffolding matters more than the prose itself. If the schema is clear, I can get the model to deliver something precise in any language.
So I keep the instructions in English and treat language output as a parameter, not the default. That keeps the prompt composable with tools, parsers, and downstream workflows.
It also makes debugging less painful. When a response breaks, I can pinpoint the gap: “field X is missing,” “this paragraph is too long,” “the tone is too formal.” Those are the phrases most tutorials, prompt libraries, and evaluation rubrics already use. If I need to share a prompt with someone else, English is usually the most portable layer—it’s the closest thing we have to a shared protocol.
English Reduces Token Waste
This is a small, tactical point, but it adds up.
Most model tokenizers are optimized for English. That means English often compresses into fewer tokens and fewer weird splits. When I write in English, I can fit more instruction into the same context window, and I pay less in inference cost.
It’s not always dramatic, but it’s consistent enough that I notice. If a prompt is long, I’d rather spend the context on more constraints or examples than on tokenization overhead.
The Ecosystem’s Best Recipes Are in English
Prompting patterns evolve in public. The best techniques get written up, shared, copied, and forked. Right now, that ecosystem is overwhelmingly English.
When I prompt in English, I can lift ideas directly:
- role + task + constraints
- “show your reasoning” (when appropriate)
- “avoid these pitfalls” checklists
- output format contracts
When I prompt in another language, I’m often translating patterns rather than using them. It’s slower, and I lose fidelity. English keeps me aligned with the most battle-tested recipes.
What I Do When the Output Isn’t English
I still want the final output in the target language. I just keep the control layer in English.
Here’s the pattern I use most:
- Instruction in English (task, constraints, structure)
- Output language explicitly specified
- Examples in the target language (if tone matters)
Example:
You are a bilingual editor. Rewrite the following in Japanese.
Constraints: short sentences, friendly tone, no honorifics.
Output language: Japanese only.
Text:
...This pattern is stable, repeatable, and easy to compose with other tools. The English instructs the model how to work; the output language tells it what to return.
When I Don’t Use English
There are real exceptions.
- If I’m exploring a cultural nuance, I think in that language.
- If the input is already in another language and I want to preserve voice, I keep it there.
- If English slows me down (because I’m tired, or the terms are more precise in another language), I switch.
But even in those cases, I often keep a thin English wrapper for the model: “Keep the original tone,” “Don’t translate names,” “Use the same punctuation style.”
A Small Prompting Checklist That Works in English
When I want consistent results, I fall back to a lightweight checklist:
- Role: who the model is (editor, analyst, designer)
- Task: what to produce
- Constraints: length, tone, format, forbidden items
- Context: sources, examples, or data
- Output format: schema or bullets
- Language: explicit, even if obvious
It looks simple, but in English it maps cleanly onto how the models were trained. That’s the whole point: predictable behavior with minimal friction.
Closing Thought
English isn’t “better.” It’s just the current control interface for AI.
If I want speed and precision, I use the interface language—even when the content speaks something else.