When Japanese Prompts Drag Down Antigravity Quality — A Multilingual Operator's Hybrid Workaround

Measurements: same task, Japanese vs English

I work on a handful of personal iOS/Android apps as an indie developer (wallpaper-style products among them), and across two recent weeks I tracked a set of similar maintenance tasks. To keep conditions roughly comparable, I issued the same refactor request in Japanese-only and English-only prompts against the same Antigravity project, recording whether the initial proposal was accepted as-is, how many follow-up corrections I needed, and how many turns it took to land green tests.

Sample size is 24 tasks, so treat this as field experience rather than statistics.

• Initial-proposal acceptance rate: ~58% (JA) vs ~81% (EN)
• Average follow-up corrections before acceptance: 3.1 (JA) vs 1.4 (EN)
• Average turns to passing tests: 4.6 (JA) vs 2.3 (EN)
• Input-token count for equivalent intent: Japanese ~18% higher (Japanese is more verbose for equivalent specificity)

The follow-up correction count is the most painful axis. With Japanese prompts, the first proposal often lands "in the right direction but wrong in the details", so I end up appending "rewrite this part, drop that part" two or three times. English prompts hit acceptable on the first shot far more often, cutting total round-trips in half.

The gap widens when library-specific assumptions matter (specific RxJava operator choices, threading models in CoreData, etc.). It shrinks — and sometimes reverses — for natural-language work like UI copy suggestions, spec summaries, or test name brainstorming, where Japanese prompts read more naturally.

A hybrid strategy: which layer stays Japanese, which leans English

Going all-English isn't an approach I recommend. I'll cover the trap later. First, here's the practical hybrid setup I use, in three layers.

1. User-facing chat replies: Japanese, always. The agent talks to me in Japanese.
2. Code-generation instructions (system-prompt-equivalent): pinned to English.
3. Code comments / READMEs / i18n copy: code comments in English, README and user docs in Japanese.

The agents.md (or AGENTS.md, .cursorrules) I keep at project roots looks roughly like this:

# Project Agent Rules
 
## Language Policy
 
- User-facing chat responses: Japanese (formal です/ます register)
- Internal planning, tool calls, and code-generation reasoning: English
- Code comments: English unless a Japanese comment already exists in the file
- README, CHANGELOG, and user docs: Japanese
- Commit messages: English imperative ("Add", "Fix", "Refactor")
- Variable names: English; do not romanize Japanese words
 
## When the user writes in Japanese:
1. Acknowledge briefly in Japanese
2. Switch to English internally for code planning
3. Present code with English comments
4. Summarize the result in Japanese at the end
 
## When generating diffs:
- Always show the full file path and a Japanese reason for the change
- Keep changes minimal; explain in English why each change is necessary

The point is to push the agent's internal code-construction reasoning toward English while keeping the visible chat surface in Japanese. With this setup, the 4.6-turn average from above drops to roughly 2.7 in my logs. Not quite parity with all-English prompts, but close enough that I no longer feel like I'm fighting the model.

A translation-layer architecture: lightweight model in front of Antigravity

A more aggressive setup is to wrap Antigravity behind a translation layer using a small model. This is particularly useful if you are calling Antigravity from a local or server-side script rather than typing into the IDE directly.

# pseudo-flow: convert Japanese intent into precise English instruction
# before handing it to the coding agent
from typing import Literal
 
def to_agent_prompt(user_intent_ja: str, mode: Literal["plan", "diff", "review"]) -> str:
    """Translate Japanese developer intent into a structured English instruction.
    A small model (Gemma 4 9B / Phi class) handles this layer at low cost.
    """
    system = (
        "You are a translator that converts Japanese developer intent into "
        "precise English instructions for a coding agent. Preserve identifiers. "
        "Output only the English instruction, no preamble."
    )
    style_hint = {
        "plan":   "Produce a numbered plan with file paths.",
        "diff":   "Produce a unified diff with file paths. Minimal change.",
        "review": "Produce a checklist of risks and required tests.",
    }[mode]
    return f"{system}\n{style_hint}\nJP_INTENT: {user_intent_ja}"
 
# usage
intent = "Replace RxJava Single with Coroutines and centralize error handling upstream"
english_instruction = call_lightweight_model(to_agent_prompt(intent, "diff"))
# feed english_instruction into the Antigravity session

Three benefits. First, Antigravity's input is pinned to English, stabilizing output. Second, "translation" is a simple enough task that a small model handles it well, keeping cost and latency low. Third, the translated English instructions become reusable assets — you can replay the same task against a different agent later.

The pitfall is that the translation step turns into a black box. For the first few days I ran this flow without surfacing the intermediate English, and the lightweight model was quietly drifting from my intent, which slowly poisoned final outputs. I now log the intermediate English instruction and inspect it whenever a final response feels off.

Running Gemma 4 locally — the reality for Japanese output

A note on the local side. Antigravity can connect Gemma 4 as a local model, which is attractive when the code involves sensitive material. For Japanese output quality specifically, the gap to frontier cloud models is still non-trivial.

On my Apple Silicon machine, Gemma 4 against English prompts produces usable code; against Japanese prompts, the quality drops one more notch compared to a cloud frontier model. I attribute this to the same training-data ratio issue, which becomes more visible as model size shrinks.

What I actually do for local runs:

• Keep the system prompt in English (same hybrid policy as above)
• Use a separate small model for final Japanese-language polishing
• Route privacy-sensitive code paths to local Gemma 4, and route generic refactors to cloud Antigravity

The real value of local Gemma 4 is operational, not quality: nothing leaves the machine. Inside my own indie portfolio, billing-related code and device-identifier paths go to the local model, while general refactoring goes through the cloud agent. I draw that line purely by how sensitive the data is, not by response quality.

How I split things in practice — including Japanese-language blog ops

I use Antigravity not only for the Lab-series tech blogs but also for maintaining the post-automation scripts of a couple of Japanese-language blogs in a different genre. The balance of "what stays Japanese" differs by project.

On the tech-blog side (Antigravity Lab included), I prioritize code-generation precision, so agent instructions lean toward English via the hybrid setup above. On the Japanese-language blog side, where the naturalness of the text matters most, I keep body-generation prompts in Japanese and reserve the English-leaning setup for the code maintenance side of things (cron scripts, formatters, etc.).

That split only works because agents.md lives per project. Setting a global language pin would force me to compromise on one axis, and I'd end up dropping the careful "code in English, copy in Japanese" balance entirely.

Three traps to watch for when going all-English

Three places where all-English prompts actively hurt.

User-visible copy. UI error strings, release notes, label suggestions — these tend to feel flat when generated from an English system prompt. Generate the Japanese with a Japanese prompt, then translate to English in a separate step if needed.

Japanese-specific business context. End-of-month invoice formats, Wareki date handling, polite-form email templates. The core intent thins out when you force these into English.

The cost on your own thinking. Writing English prompts well requires English-side precision from you. Early on, I was paying double — my English wasn't crisp enough, and the agent's English-leaning interpretation drifted from my intent. The whole point of an agent is to lower the cost of expressing intent, so forcing yourself into an uncomfortable language is counterproductive. Either drop a translation layer in front, or use the hybrid setup so your visible chat stays Japanese.

What to do next

The smallest next step is to drop a one-file agents.md at your project root with the hybrid policy from this article, and run it for half a day. Once you've felt the difference in code-generation precision, adjust the rules to match your own project.

Thanks for reading. I hope the response quality of your projects becomes a little more reliable.