In my experience, the engineers who succeed with coding agents combine two abilities. They understand the technical aspects of what they want to build, and they can articulate their ideas clearly in natural language.
The combination matters. Someone may understand a system deeply but leave too much of that understanding unspoken. Someone else may describe a product beautifully while missing a constraint that determines whether it will work. Working effectively with an agent means carrying an idea across both gaps.
I also suspect that English fluency gives non-native speakers an additional advantage. Being able to discuss a technical problem comfortably in English can make the interaction easier. Whether English itself makes the model produce better code is a separate, testable question.
These are observations about the work, not a formula for ranking people. A research paper gives us a useful way to examine them more carefully.
What the study supports
Computer Science Achievement and Writing Skills Predict Vibe Coding Proficiency, by Sverrir Thorgeirsson, Theo B. Weidmann, and Zhendong Su, appeared on arXiv on March 14, 2026, for CHI 2026. Their preregistered study involved 100 tertiary students building small GUI applications with Claude Sonnet 4, without viewing or editing source code.
CS achievement correlated with performance at r = .386; writing at r = .290. After controlling for general reasoning, CS remained statistically significant; writing did not (p = .066). A separate model combining CS and writing explained about 21% of performance variation. These are associations, not proof that training either skill causes improvement. Table 3 and Section 8.2.
The timed student tasks do not establish outcomes for professional repository work. Nor did the study compare English with other prompting languages. Its results support investigating my observations, with substantial uncertainty about their reach. Study limitations.
Understanding gives you something precise to say
Consider an illustrative request: “Build a reliable order submission flow.”
That sounds clear until we ask what reliable means. What happens if the server creates the order but the response never reaches the browser? Should the customer try again? How will the system distinguish a retry from a second order?
An engineer who recognizes that failure mode can make the requirement concrete:
If the response is lost after an order is created, retrying the same submission must return the existing order without creating another. Use a stable identifier for that submission. A genuinely new order must use a new identifier.
This example draws on the idempotency problem described in the AWS Builders’ Library: retries become safer when the API can recognize repeated intent, while recording the identifier and applying the change atomically.
The useful contribution begins before the prompt. It is recognizing the ambiguous outcome, deciding which behavior the product needs, and understanding that the decision has consequences for persistence and the API contract.
The agent may propose those details itself. I still want the engineer to be able to evaluate the proposal, notice what it leaves unresolved, and decide whether it fits the system. A plausible suggestion only helps if someone can judge its relevance.
That is what I mean by technical background. It can come from formal study, self-directed learning, or years of building and debugging. Its value is the working understanding it produces: state, dependencies, failure modes, boundaries, and ways to check correctness.
Clear expression makes that understanding usable
Knowing about idempotency does not automatically produce a useful instruction. “Make it idempotent” can still leave the scope, lifetime, and meaning of a repeated request unspecified.
For agent work, I think of clear expression as the ability to turn an intention into observable behavior. A useful description connects the situation, the desired outcome, the constraints, and the evidence that would convince us the result is correct.
In the order example, the next instruction might be:
Test a lost response after a successful creation. Retry with the same submission identifier and confirm that only one order exists. Then submit an identical order with a new identifier and confirm that it is treated as a separate order.
The distinction between same submission and identical order is small in prose and consequential in software. Writing it down forces a design decision into the open. It also gives the engineer something specific to inspect after the agent finishes.
This is why I would teach technical writing alongside agent use. Short sentences can carry sophisticated requirements. A long prompt can still be vague. The goal is to preserve the meaning that matters as the work moves from intention to implementation and back through review.
My practical framework for working with coding agents; this is a conceptual diagram, not a model validated by the study.
Where English fluency may add an advantage
I would separate two possible effects.
The first is on the engineer's ability to work. My hypothesis is that comfort with technical English reduces friction when moving among documentation, API names, error messages, and a conversation with the agent. It can make it easier to ask a follow-up question, challenge an explanation, or preserve a subtle distinction across several iterations. That would be a practical advantage even if equivalent prompts in two languages produced equally good code.
The second is on the model's output. Here, the evidence is mixed. The NAACL 2025 mHumanEval study reports that its evaluated models generally performed best with English prompts, with results in other languages varying by language and model. Multilingual capability and code specialization did not produce the same pattern of results. That gives us reason to test language choice, rather than assume it is irrelevant.
But a July 16, 2026 preprint on multilingual code generation finds that English does not consistently deliver the best functional correctness or code quality. Outcomes depend on the model and programming language. Those code-generation benchmarks also differ from sustained conversations with an agent inside a repository.
I therefore see English fluency as a potential additional advantage, whose value depends on the person, model, and task. I would not turn it into a universal English-only rule.
For a non-native speaker, I would start with the language in which the requirement can be expressed most precisely. Where useful, ask the agent to produce an English technical specification while preserving API names, examples, and constraints. Review that specification for changed meaning. If language choice seems to affect results, compare equivalent instructions on representative tasks using the same model and acceptance checks, across several runs.
The aim is to make technical understanding available to the agent. Forcing someone into less precise expression can defeat that purpose.
What I would teach and assess
If I were designing a team's development program around coding agents, I would bring technical fundamentals, explanation, and verification into the same exercise.
Give an engineer a small feature with an ambiguous requirement. Ask them to explain the intended behavior, identify a failure case, work with the agent, and show how they checked the result. Then change one requirement and observe whether they can explain what must change and what should still hold.
That exercise reveals where support is needed. A missed failure mode suggests a gap in technical understanding. A known constraint omitted from the instruction suggests a communication gap. Accepting a convincing demonstration without checking the underlying behavior suggests a verification gap. Each calls for different practice.
I would offer technical English support where it helps, while evaluating the clarity of meaning and the quality of the engineering decisions. Native-like prose would tell me much less than a precise explanation of why the retry cannot create a duplicate order.
My expectation is that coding agents will make the relationship between thinking and explaining increasingly visible. The engineers I would invest in are those who can understand what they are asking for, express it well enough to guide the work, and recognize whether the result deserves their confidence.
Sources
- Thorgeirsson, Weidmann, and Su: CHI 2026 study, first posted March 14, 2026. Main empirical reference; numerical results and limitations are linked above.
- AWS Builders’ Library: Making retries safe with idempotent APIs. Engineering basis for the illustrative order-submission example.
- Raihan, Anastasopoulos, and Zampieri: mHumanEval, NAACL 2025. Multilingual prompting benchmark and model comparisons.
- Afrin and colleagues: multilingual prompts and code quality, preprint posted July 16, 2026. Evidence against a universal English advantage.