Writing Prompts in a Non-Native Language
I have noticed that when I write prompts for an Agent in Chinese, I instinctively soften what I say.
“You could start by taking a look at these files.”
“If appropriate, it would be best to run the tests as well.”
“Could we perhaps consider a different implementation here?”
These sentences sound perfectly natural in conversation between people. Rather than giving direct orders, they leave the other person room to exercise judgment and to decline. But when used to assign a task, they also weaken the actual requirements: Do the files have to be read, or not? Are the tests part of the deliverable? Does “consider” mean a change ultimately needs to be made?
In English, by contrast, I tend to write very directly:
Read these files first. Use the existing implementation pattern. Run the tests before you finish.
This is not because English is inherently more direct than Chinese. Real communication in English-speaking workplaces is often just as indirect and may even express a request as a question. On the surface, “Can you take a look when you have time?” offers a choice. In context, however, it may mean: Please deal with this, and do not make me ask again.
I can write prompts more directly in English simply because English is not my native language.
When we use our native language, we are not merely conveying meaning; we are also managing relationships automatically. Which sentence sounds like an order, which might embarrass someone, and how to disagree without sounding aggressive—these judgments have long since become part of our linguistic intuition and require no conscious thought. Before a request is even written down, politeness has already reshaped it.
In a non-native language, these reactions are less acute. With fewer expressions at my disposal, I have to begin with the most basic structure: what to do, what to do it to, how far to take it, and what must not be done.
Limited language proficiency, paradoxically, temporarily strips away some of these social considerations.
This does not mean that a native language is unsuitable for writing prompts, or that we should deliberately be rude to an Agent. What is useful is the slight distance created by a non-native language. It lets us step outside our familiar ways of speaking for a moment and see again whether a task description actually contains an action, boundaries, and conditions for completion.
When speaking to people, indirectness serves a clear purpose.
Adults generally treat one another as autonomous; we cannot regard someone else as an object waiting to be disciplined into obedience. A mature refusal usually does not consist of tossing out a single “No,” but explains the practical constraints and, when necessary, offers an alternative. A manager making a request may also phrase it as a question, preserving the other person’s dignity and room to respond.
This kind of communication does not hide the real intent. It attends to two things at once: boundaries must be clear, and the relationship must not be damaged. The words can be gentle, but the conclusion cannot be ambiguous.
A prompt, however, addresses a different kind of relationship.
An Agent will not be offended by “Read these files first,” nor does it need a “Would you mind” to reassure it that it is still being treated as an equal. What it needs is to know which points are requirements and which are merely references; what must be completed and what is left to its judgment; and under what circumstances it should stop and ask a person.
If we carry over the indirect language used between people without also spelling out the real intent behind it, politeness turns into ambiguity.
For example:
If convenient, you could also check the mobile version.
The speaker may mean that “the mobile version must be verified,” but habit keeps them from wording it like an order. The Agent, however, may read it as a low-priority option. A clearer version would be:
Before finishing, check both desktop and mobile. Handle ordinary details according to the existing design; if this requires changing the interaction model, come back and ask me.
This still gives the Agent autonomy, but puts that autonomy in the right place. Whether to check mobile is not a choice; how to handle ordinary details is.
This is also the difference between being direct and being harsh.
Being harsh means providing no context or boundaries and simply issuing a string of commands—or, when the result falls short of expectations, substituting sarcasm and rhetorical questions for feedback. Being direct means stating the objective, constraints, and acceptance criteria clearly, then letting the person doing the work choose a path within those boundaries.
A good prompt does not make “command and obedience” more forceful. It makes the boundaries of “autonomy and negotiation” clearer.
But I soon ran into another problem.
Making a boundary clear this time does not mean it will still be in effect next time. With a different task, or even a different session, the same boundaries may have to be explained all over again: run the tests before finishing, include mobile in the acceptance checks, and do not change unrelated files while fixing one problem.
I could keep refining my prompts, adding every correction to the next task description. This does help, but each task becomes longer to write, and I become a courier carrying boundaries from one task to another. The moment I forget to bring one along, a problem that had already been solved may reappear.
Eventually I realized that I had been revising sentences without changing how the boundaries were stored or put into effect.
What a non-native language helped me solve was a problem of expression: it forced requirements hidden in tone and shared understanding to become visible for the first time. But if a requirement has to be explained repeatedly across different tasks, the question is no longer whether I was direct enough on this occasion. The problem is that a boundary meant to remain in effect over time has been placed somewhere that can serve only the current task.
What is needed then is not a longer prompt, but a Harness.
A Harness is the system layer surrounding the model. It provides the necessary context again, loads rules, makes tools available, preserves state, and checks the results. A model does not automatically inherit a correction in its next invocation simply because I corrected it last time. A conversation appears continuous because the surrounding system gives the relevant material to the model again.
Boundaries should therefore be placed in different locations according to their lifespan and strength.
Goals and local constraints that matter only to the current task still belong in the prompt. Project boundaries that apply across tasks can go in AGENTS.md. Methods used repeatedly can be turned into a Skill. Acceptance criteria that can be observed and executed should be entrusted to tests. Permissions that truly must not be exceeded should be enforced by the system, rather than by expecting the model always to remember a sentence saying, “Do not do this.”
None of this makes output absolutely stable. Even with the same context, a model may still produce different results because of uncertainty in its reasoning, conflicts between instructions, or the burden of the context. The purpose of a Harness is not to eliminate variation. It is to keep important background present, subject checkable results to checks, and ensure that risks we cannot accept do not depend solely on the model making the correct judgment every time.
This also changed how I understood the idea of “writing prompts in a non-native language.”
A non-native language is not a Harness. It does not preserve state, load rules, or verify results. It is only a lightweight exercise in making boundaries explicit: when familiar tones and interpersonal assumptions temporarily stop working, I have to state clearly which results must be delivered, which judgments can be delegated, and which situations require coming back to ask.
Nor should we turn around and place blind faith in non-native languages.
A limited vocabulary can make sentences direct, but it can also make judgments crude. If all we can write is “This is wrong,” we may have avoided the circumlocution we would use in Chinese, but we still have not explained what is wrong. A non-native language can also create a false sense of objectivity: a sentence that looks concise and firm does not mean that the objective itself has been thought through.
A more reliable approach is to use a non-native language as a check, not as a rule.
When a prompt in Chinese grows long and fills up with phrases like “you could,” “it would be best,” “if convenient,” and “perhaps,” try translating it mentally into the simplest foreign language you know. Once removed from your familiar tone, it often becomes easier to see the few things you actually mean to say:
- Which result must be delivered;
- Which points are only reference information;
- Which judgments can be left to the Agent;
- Which situations must be decided by a person.
Once those are clear, there is nothing wrong with rewriting the prompt in Chinese.
If a boundary matters only to this task, state it clearly. If it will still matter next time, let the system preserve it. If it truly must not be crossed, do not keep expecting the model to remember it from a sentence alone.
I thought I was practicing writing prompts in another language. Later I realized that what I was really practicing was turning implicit judgments into explicit contracts.
A non-native language lets me see the boundaries. A Harness is what makes them persist.