LLM gender bias hides in how you write, not who you are

LLM gender bias turns out not to live where most of us have been looking for it. A paper posted to arXiv on 13 August 2026, It's How You Ask: Gender-Associated Linguistic Bias in LLMs by Katherine Van Koevering and Anjalie Field, reports something more awkward than a name-swap test: putting a woman's name in the prompt changed nothing, but writing in a hedged, polite register produced large and consistent differences in what the model gave back.

I want to argue that this finding is much bigger than gender, and that if you ship anything with an LLM behind it, it is now your bug to fix.

---

🔍 What the paper actually measured

The authors tested prompts across four models and three document types, varying the linguistic register rather than the stated identity of the user. The features they looked at are the ones sociolinguists have long associated with women's speech in English:

• Hedges — "I think maybe", "sort of", "just wondering if"
• Tag questions — "…that would work, wouldn't it?"
• Collective reference — "we should", "our team needs", instead of "write me"

Prompts carrying those features got responses that were shorter, less sophisticated, and less formal, and the effect held after controlling for prompt complexity. So this is not the model correctly reading a vaguer request and giving a vaguer answer.

Signal in the prompt	Effect on the response
Explicit gender cue (a name)	No effect reported
Hedges, tag questions, collective reference	Large, consistent effect
Prompt complexity (controlled for)	Not the explanation

Key takeaway: The models are not discriminating on identity. They are discriminating on style — and style correlates with identity, which produces the same outcome while passing every name-swap fairness test you were running.

---

🌐 Why Sri Lankan English sits directly in the blast radius

Here is the part that made me stop and rewrite my own prompt templates.

The register the paper flags as penalised is, more or less, the default polite register of Sri Lankan professional English. Think about how a typical email from a Colombo office actually opens:

I was just wondering if you could kindly help me with a small thing.
We were hoping to maybe put together a short proposal, if that's okay?

That is three hedges, one collective reference, and a softener, in two sentences. Nobody wrote it that way because they were unsure. They wrote it that way because in Sri Lankan English, going straight to "Write a proposal." reads as rude.

The paper's own framing is that these features are culturally embedded and outside conscious control. That is the sharp end of it. If the workaround is "just write more assertively", then the workaround is asking people to code-switch out of their own dialect to get the same service everyone else gets by default. For a student in Kandy writing a scholarship statement, or a freelancer pitching an overseas client, that is a real and invisible tax.

I have not seen data on non-native or South Asian English registers specifically, and the paper does not claim to have tested that. So treat this as my inference, not their finding. But the mechanism generalises cleanly: if politeness markers depress output quality, every high-politeness English variety is exposed.

---

⚡ Why "just add a system prompt" won't fix it

The instinct for most of us building on top of an API is to patch this at the instruction layer: append "treat all requests with equal rigour regardless of phrasing."

The paper closes that door. It reports that these linguistic features are encoded in early transformer layers and entangled with other features. In plain terms:

1. The register signal is picked up early, well before whatever your system prompt is trying to steer.
2. It is entangled — you cannot cleanly isolate and suppress "hedginess" without dragging along whatever else those representations carry.
3. So mitigation has to happen either in training, or outside the model entirely, in your application layer.

Option three is the only one available to a small team in Sri Lanka. Which is fine, because option three is also the cheapest.

---

🛠️ What to actually build if you ship an LLM feature

Concretely, a prompt normalisation step between your user's text and the model:

Layer	What it does	Cost
Normaliser	Rewrites the user's raw input into a flat, direct instruction before it hits the model	One cheap small-model call, or pure regex for common hedges
Eval pair	Runs the same request in hedged and direct form, compares outputs	Runs in CI, not per-request
Length floor	Flags responses well below the median for that request type	Free

A regex-only normaliser gets you a surprising distance. Stripping a fixed list of openers ("I was just wondering if", "would it be possible to", "sorry to bother you but") costs nothing per request and is fully auditable, which matters more than elegance when you are debugging why one user's output looks thin.

If you want to sanity-check your own phrasing before wiring anything up, our AI Prompt Formatter turns rough or over-softened notes into a direct instruction, and the Word Counter is enough to measure the response-length gap between two phrasings of the same request. That is the whole test, and it costs you nothing.

Run this once today: take one real prompt from your app. Write it twice — once hedged, once blunt. Send both. Count the words in each reply. If the gap is large, you have shipped the bug.

---

💡 What this means for you

• If you use LLMs for work: you are probably leaving quality on the table through politeness alone. Be blunt with the model and polite with the human. They are different audiences.
• If you build on an API: name-swap fairness tests are no longer sufficient evidence that your product treats users equally. Add register to your eval set.
• If you teach or mentor: telling students to "prompt better" is fair advice, but be honest that you are teaching a dialect, not a skill.

The uncomfortable version of this result is that the fairness checks the industry standardised on were testing the variable that turned out not to matter. Names are easy to test, so we tested names. Register is hard to test, so we mostly didn't.

The useful version is that the fix is within reach of a two-person team with a free-tier API key and an afternoon. Normalise the input, measure the output, ship it. You do not need to wait for a model provider to solve this for you.