DEV Community: Harvey He

Six Languages Broke Our "Make AI Text Sound Human" Feature. Here's What Actually Went Wrong

Harvey He — Fri, 09 Oct 2026 03:33:39 +0000

We run a small text-rewriting tool. English feedback was decent. Then we turned on the other twelve languages and support tickets changed shape completely.

Nobody complained that "the text is still robotic". They complained about things like "why is there a space before my question mark", "my boss name is spelled wrong in Hebrew", and "this is insulting in German".

Here are the six failures worth writing down. All of them were invisible to our English test suite.

1. "Shorter is better" is an English habit

Our English pass was tuned to cut filler and shorten sentences. Applied to German it shredded perfectly natural compound nouns. Applied to Japanese it did the opposite — the rewrite came out longer than the source because our "simplify" rule kept splitting clauses that Japanese keeps joined with commas.

A 100-word English paragraph is roughly 130 words in German and about 70 characters in Chinese. There is no single length target. If your rewrite rules reference word or character counts, they are English rules wearing a neutral costume.

2. Punctuation is a fingerprint, and it differs per script

The em dash obsession that AI detectors flag is an English signal. In French, the giveaway is different — and so is the correct typography:

Language	Correct	What our tool shipped
French	`Bonjour !` (narrow NBSP before `! ? ; :`)	`Bonjour!`
German	`„Anführungszeichen"`	`"Anführungszeichen"`
Spanish	`¿Qué?` / `¡Vamos!` (opening marks)	`Qué?` / `Vamos!`
Chinese	`，。` full-width	`, .` half-width

Half-width punctuation in Chinese text is the single loudest "a foreigner or a machine wrote this" signal there is. We shipped it for a week.

3. Your "AI-tell" word list does not translate

Every language has its own overused vocabulary, and it is almost never a translation of the English list. Machine-translating "delve / tapestry / bustling" into Spanish produces words nobody overuses. Meanwhile the actual Spanish tells — en el mundo actual, es importante destacar — were not on our list at all.

You have to build the list per language from real text, not translate the English one. There is no shortcut here.

4. Formality is a required field, not a style option

English has one "you". Many languages do not:

French: tu vs vous
German: du vs Sie
Spanish: tú vs usted, and vos in Argentina
Chinese: 你 vs 您

Defaulting to the informal form is not "casual", it is rude — the German one in particular. If the input does not tell you the register, the honest move is to ask or stay formal. Guessing friendly is a bug, not a feature.

5. RTL is not "same text, right aligned"

Arabic and Hebrew need the direction handled in the layout, not just in the CSS direction property. Mixed content is where it breaks: an English product name inside an Arabic sentence, a phone number next to a parenthesis. They reorder visually, so a name that reads correctly in the database renders wrong on screen and in a quoted email.

If you cannot test with a native reader, at minimum wrap Latin runs and numbers with proper isolates and check the rendered string, not the source string.

6. Numbers, dates, and units

1,000 means one thousand in the US and one in Germany. 3/4/2026 is two different dates depending on the country. Temperature units, paper sizes, and currency placement all differ.

This is the boring one, and it is also the one that produces refund requests, because a wrong date in a contract line is not a stylistic problem.

The lint we ended up writing

We stopped trying to be clever in the rewriter and moved all of this into a per-language checker that the rewriter must pass:

CHECKS = {
    "fr": [("missing_nbsp_before_punct", lambda s: bool(
        __import__("re").search(r"[A-Za-z\u00C0-\u017F][!?;:]", s)))],
    "zh": [("halfwidth_punct", lambda s: bool(
        __import__("re").search(r"[\u4e00-\u9fff],[\u4e00-\u9fff]", s)))],
    "de": [("straight_quotes", lambda s: '"' in s)],
    "es": [("missing_opening_mark", lambda s: ("?" in s and "¿" not in s)
                                           or ("!" in s and "¡" not in s))],
}

def lint(text, lang):
    return [name for name, fn in CHECKS.get(lang, []) if fn(text)]

Then a human who actually speaks the language reads the output. Not a translator — a reader. Every language we shipped without that step came back with a ticket.

The lesson is not "AI text rewriting is hard in other languages". It is that an English-only test suite will tell you everything is fine right up until a customer quotes you.

The tool we build this into is ShipCopy, if you want to see the multilingual side in action: launchcraft.io — 10 rewrites free, no card.

Burstiness and n-grams: a 40-line Python AI-text detector, and where it breaks

Harvey He — Wed, 30 Sep 2026 10:07:22 +0000

Every writer who pastes drafts into an AI humanizer eventually asks the same thing: how do I know the text actually sounds human before I send it? I built a small detector to answer that, and the interesting part was not the code — it was watching where it confidently fooled itself.

Here is the whole thing, runnable as-is.

import re
from collections import Counter

def sentences(text):
    # split on . ! ? followed by whitespace; keeps the delimiter
    return [s.strip() for s in re.split(r'(?<=[.!?])\s+', text) if s.strip()]

def burstiness(text):
    lens = [len(s.split()) for s in sentences(text)]
    if len(lens) < 3:
        return None  # too short to mean anything
    mean = sum(lens) / len(lens)
    var = sum((x - mean) ** 2 for x in lens) / len(lens)
    return var ** 0.5 / mean  # coefficient of variation

def repeated_ngrams(text, n=3, threshold=2):
    words = re.findall(r"[a-z']+", text.lower())
    grams = [" ".join(words[i:i+n]) for i in range(len(words)-n+1)]
    return {g: c for g, c in Counter(grams).items() if c >= threshold}

def score(text):
    b = burstiness(text)
    rep = repeated_ngrams(text)
    # low burstiness + repeated phrases => suspicious
    if b is None:
        return None
    return round((1 - min(b, 1)) * 0.6 + min(len(rep), 10) / 10 * 0.4, 3)

if __name__ == "__main__":
    human = "I shipped the proxy on a Tuesday. Two days later the stream broke. Turned out the client buffered wrong. Fixed it by Friday."
    robot = "The implementation of the proxy was completed successfully. The system was designed to be robust. The architecture ensures reliability. The solution provides scalability. The approach demonstrates effectiveness."
    print("human:", score(human))   # usually higher (varied lengths)
    print("robot:", score(robot))   # usually lower (uniform, repetitive)

Run it and you will see the robot sample scores lower almost every time. Good enough to sort a pile of drafts, right? Three things broke that assumption in production.

Pitfall 1: short texts are noise. burstiness returns None under 3 sentences, and even at 3–4 sentences the coefficient of variation swings wildly. A two-sentence human reply can look more "AI" than a ten-sentence marketing page. I had to treat anything under ~40 words as "unknown" instead of scoring it.

Pitfall 2: genre beats author. Legal summaries, release notes, and API docs are supposed to be uniform. My detector flagged real human technical writing as AI because the domain is naturally low-burstiness. Burstiness alone is a genre signal, not an authorship signal.

Pitfall 3: the detector is the easiest thing to game. Swapping two sentences, splitting one long one into two, or changing "utilize" to "use" drops the repeated-ngram count to zero. That is exactly what a cheap humanizer does — it moves the score without moving the prose.

So detection helped me triage, but it never told me the text was good. The part that actually changed how the output reads was a fixed set of rewrite moves: vary sentence openings, cut the second "that", replace noun-stacks with verbs, and break the rhythm every third sentence. We baked those into a tool we use daily — ShipCopy — but the patterns work fine by hand once you have seen them fail a detector a few times.

The takeaway: a 40-line detector is a fine smoke test. It is not a judge of quality, and anyone who promises the text is human is selling the score, not the sentence.

"Your first 100 users are reading your launch post. This one mistake loses most of them."

Harvey He — Thu, 17 Sep 2026 22:04:32 +0000

I shipped a product last year and got 12 users from my launch post. Twelve. Not because the product was bad. Because the post read like the model that wrote it.

Three months later I rewrote it like a person would talk, kept the same product, same link. Got 140. Same traffic, ten times the pull.

Here's the mistake, and how to fix it without spending a day.

The mistake: you described the product, not the reader

Most launch posts open with what the thing does. "An AI tool that helps you write better copy." That sentence is true and useless. The reader's brain files it under "another AI tool" and scrolls.

The posts that converted for me did the opposite. They opened with a moment the reader already lived through:

"You spent two hours writing your Product Hunt draft and it still sounds like a press release."

That line got replies. Because someone read it and thought "yeah, that was this morning."

The fix is smaller than you think

You don't need a copywriter. You need to move one sentence.

Take your current first paragraph. If it mentions your product name or what it does, that's the problem.
Replace it with a specific thing your user does badly, in their own words. Pick the most annoying one.
Keep the rest. Don't rewrite the whole thing.

That's it. One sentence moved. The rest of your post was probably fine.

Where non-native English founders get stuck

If English isn't your first language, this is harder, not because you write badly, but because the AI draft you start from is smooth and wrong in the same way every time. It uses words like "leverage" and "seamless" that mark you as a template instantly.

The trick isn't better English. It's fewer impressive words. "Our tool helps you" beats "Our robust solution empowers." Every time.

I got tired of doing this by hand on every post, email, and reply, so I built a small thing, ShipCopy, that takes the draft and returns the human version. Paste, get it back, ten free uses, no card. It won't write your product. It just takes the robot edges off what you already wrote.

launchcraft.io

What's the launch post you're stuck on right now? Link it in the comments, I'll tell you which sentence to move.

"Streaming through an OpenAI-compatible proxy: 6 bugs that only show up in production"

Harvey He — Thu, 17 Sep 2026 03:16:10 +0000

I run a small OpenAI-compatible gateway. Non-streaming requests worked on day one. Getting streaming right took me about three weeks of bug reports from my own tools.

The annoying part: every bug below passes unit tests. They only show up with a real client, a real network, and a model that thinks for 30 seconds before saying anything.

Here's what broke, and the code that fixed it.

1. `chunk["choices"][0]` throws IndexError

If you pass stream_options: {"include_usage": true}, OpenAI sends a final chunk that carries token counts and an empty choices array:

{"choices":[],"usage":{"prompt_tokens":412,"completion_tokens":88,"total_tokens":500}}

Any code that assumes choices[0] exists dies right there, at the very end of the stream, after the user already read the full answer. Worst possible moment to 500.

async for chunk in upstream:
    if not chunk.get("choices"):
        if chunk.get("usage"):
            record_usage(user, chunk["usage"])
        continue
    delta = chunk["choices"][0].get("delta", {})

Second half of this bug: not every upstream supports include_usage. SiliconFlow honors it, some others accept the field and silently drop it. If billing depends on that final chunk, you need a fallback. I run tiktoken on the accumulated text when no usage chunk shows up, and mark the record as estimated.

2. TCP doesn't care about your event boundaries

An SSE event is data: {...}\n\n. A single read() gives you half an event, or three events glued together. If you do line.split("data: ")[1], sooner or later you hand truncated JSON to json.loads and the whole stream dies on one packet boundary.

Buffer until you see the blank line:

buf = ""
async for raw in upstream.content.iter_any():
    buf += raw.decode("utf-8", "ignore")
    while "\n\n" in buf:
        event, buf = buf.split("\n\n", 1)
        for line in event.splitlines():
            if not line.startswith("data:"):
                continue
            payload = line[5:].strip()
            if payload == "[DONE]":
                return
            yield json.loads(payload)

That buf variable is the entire trick. Two details: some upstreams send [DONE] without a trailing newline, so flush the leftover buffer on exit; and decode on a raw bytes chunk can split a multi-byte UTF-8 character in half. Use an incremental decoder or accept "ignore" and lose the occasional character in a Chinese or emoji response. I lost a few characters before switching to codecs.getincrementaldecoder("utf-8")().

3. `tool_calls` arrive in pieces and you merge by `index`, not `id`

This one cost me a weekend. When the model calls a function, arguments stream in as fragments:

{"delta":{"tool_calls":[{"index":0,"id":"call_a1","type":"function","function":{"name":"get_weather","arguments":""}}]}}
{"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"ci"}}]}}
{"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ty\":\"Xi"}}]}}
{"delta":{"tool_calls":[{"index":0,"function":{"arguments":"'an\"}"}}]}}

id and name appear only in the first fragment. Later fragments carry index and nothing else. Key your accumulator on id and you end up with one tool call whose id is None and a JSON string you can't parse.

Key on index:

calls = {}
for tc in delta.get("tool_calls", []):
    i = tc.get("index", 0)
    slot = calls.setdefault(i, {"id": "", "name": "", "arguments": ""})
    if tc.get("id"):
        slot["id"] = tc["id"]
    fn = tc.get("function") or {}
    if fn.get("name"):
        slot["name"] = fn["name"]
    slot["arguments"] += fn.get("arguments") or ""

Then json.loads(slot["arguments"]) once the stream ends. And note that parallel tool calls use index 0, 1, 2. If you keep a single slot you silently drop the second and third call. Coding agents hit this path constantly, which is why "the model said it edited the file but nothing changed" is usually a proxy bug, not a model bug.

4. You cannot retry after you've sent the headers

My failover logic originally retried on any error. But once you've written 200 OK and streamed 40 tokens to the client, there is no retry. The status line is already gone. You can drop the connection or emit a fake error event, and both look like a crash to the user.

So I added a first-token gate: don't commit the response until the first byte from upstream arrives.

async def open_upstream(body):
    for ep in (PRIMARY, FALLBACK):
        try:
            r = await client.post(ep, json=body, timeout=8)
            first = await asyncio.wait_for(r.content.__anext__(), timeout=8)
            return r, first          # now it's safe to send 200
        except Exception as e:
            log.warning("upstream %s died before first byte: %s", ep, e)
    raise HTTPException(502, "all upstreams down")

Before this, mid-stream failures ran around 1 in 300 requests. After, failures moved to the window before any user-visible output, which the OpenAI SDK retries on its own. Broken answers went to effectively zero.

One caveat. Reasoning models can sit quiet for 20 to 30 seconds while they think, so a flat 8-second gate kills them. I use 8s for models I know start fast and 30s for the reasoning ones. Measure yours, don't copy mine.

5. Idle connections get killed by whatever sits in front of you

Long think time with zero bytes on the wire means someone hangs up. Nginx defaults to a 60-second read timeout. Cloudflare is stricter. The user sees a truncated answer and blames your service.

Fix: send an SSE comment line every 15 seconds. It's a spec-valid no-op and the OpenAI SDK skips it.

HEARTBEAT = b": ping\n\n"

Race the upstream read against a 15s timer and write the comment when the timer wins. Also set X-Accel-Buffering: no on your own response. Without that header nginx buffers your carefully streamed chunks into one blob, and the user waits for the entire answer anyway. One header, and the stream suddenly feels fast.

6. When the client leaves, cancel the upstream

The user closes the tab halfway through. Starlette gives you await request.is_disconnected(), but while you're iterating the upstream body you never check it. The upstream keeps generating, you keep paying, and it holds a connection slot.

async for chunk in upstream_stream:
    if await request.is_disconnected():
        await upstream_stream.close()
        break
    yield chunk

I found a few hundred of these zombie reads in one day of logs, after a frontend bug spammed reconnects every second. Cheap to fix, real money at scale.

The 30-second way to see all of it yourself

Skip the SDK and look at raw bytes:

curl -N https://keheai.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-ai/DeepSeek-V3","stream":true,
       "stream_options":{"include_usage":true},
       "messages":[{"role":"user","content":"count from 1 to 5"}]}'

-N disables curl's own buffering. You'll see the chunk boundaries as they land, plus that empty-choices usage chunk at the end. Twenty seconds of this teaches more than a day of reading SDK source.

Every bug on this list lives in the gap between "OpenAI-compatible" and actually compatible. The spec is loose, the SDKs are forgiving, and failures only appear when someone's workflow depends on the stream finishing.

I built this gateway into keheai.com. It's the same ~200 lines of Python, now serving a few small teams, free tier is 330k tokens if you want to poke at it.

"Your AI launch post reads like a robot. Here's the 10-minute fix."

Harvey He — Wed, 16 Sep 2026 16:06:33 +0000

You pasted your product into ChatGPT, asked for a launch post, and got something that starts with "In today's fast-paced digital landscape." Nobody reads past that line.

I've done this for every launch I ship. The model gives you smooth, correct, forgettable text. The fix isn't a better prompt. It's knowing the five habits that make AI writing sound like a person wrote it.

Here's what I actually change before anything goes live.

1. Kill the hedge words first

AI loves a certain vocabulary. These show up in almost every draft:

leverage, robust, seamless, delve, navigate, unlock, empower, supercharge, game-changer, in today's [X] landscape

They say nothing. Replace "leverage our robust API" with "our API handles it." One real verb beats three abstract nouns.

Before: "We leverage a robust, seamless pipeline to empower your team."
After: "Our pipeline does the work so your team doesn't have to."

2. Vary your sentence length

AI writes in the same rhythm: medium sentence, medium sentence, medium sentence. Human writing lurches. Short. Then a longer one that explains the short one.

Try this on any paragraph: make at least one sentence under six words. It changes how the whole thing feels.

3. One outcome, not a feature list

The draft will give you five bullet points. Pick the one thing the reader gets. The rest go in docs, not the pitch.

Bad: "Fast, secure, scalable, affordable, easy to integrate."
Good: "Ships in an afternoon, not a sprint."

4. Write like you're explaining it to a friend

Read the sentence out loud. If you'd never say it that way in a call, rewrite it. "Utilize" becomes "use." "Facilitate" becomes "help." This one habit removes most of the robot smell.

5. Specific numbers beat vague upside

"Improve your workflow" means nothing. "Cut deploy time from 40 minutes to 6" means everything.

If you don't have the number yet, say what you're measuring. Honesty reads as human.

The part that used to eat my time

Doing this by hand on every launch post, every email, every Product Hunt reply added up to real hours. So I built a small tool, ShipCopy, that takes the AI draft and returns copy that sounds like a person wrote it. Paste text in, get the human version back. Ten free uses, no card.

It won't write your product for you. It just takes the robot edges off what you already have.

If you want to try it: launchcraft.io

What's your go-to trick for de-roboting AI text? Drop it in the comments, I'm collecting them.

用 200 行 Python 搭一个 OpenAI 兼容网关（双上游自动容灾）

Harvey He — Mon, 31 Aug 2026 16:51:26 +0000

上周 DeepSeek 官方接口凌晨抖了 20 分钟，我一个跑批任务全红了。那天之后我决定不再把命系在单个供应商上。

如果你也用 OpenAI SDK 调 DeepSeek / Qwen，最省事的容灾方案不是重写代码，而是前面挡一层 OpenAI 兼容网关：换 base_url 就行，业务代码一行不动。

我是这么搭的（约 200 行 Python + FastAPI）：

统一 /v1/chat/completions 入口，把请求转给上游
配两个上游：硅基流动（主）+ DeepSeek 官方（备）
主上游超时 8 秒或返回 5xx，自动切备
每用户配额和日志落在本地 SQLite

核心切换就 20 行：

async def chat(request, user):
    for upstream in [PRIMARY, FALLBACK]:
        try:
            return await forward(upstream, request, timeout=8)
        except (TimeoutError, Upstream5xx):
            log(f"switch {upstream} -> next")
            continue
    raise HTTPException(502)

踩过的坑：

上游返回的 usage 字段名不一样，要统一成 OpenAI 格式，不然你的 tokenizer 算错
流式为 SSE，切上游时要保证已发出的 chunk 不被截断
配额别用 float 存，用整数 token 数，否则并发下会出现负额度

如果你不想自己维护这套，也可以用现成的 keheai.com —— 双上游容灾、免费 33 万 tokens 试用、自助发 key。我搭它就是为了自己用，顺手开放出来。

你想自己搭的话，上面这套够跑中小流量了。要压测脚本我也可以发。