Hackathon Submission Disclosure: I created this piece of content for the purposes of entering the Google Cloud Agentic Hackathon.
It details the architecture, real-world benchmarks, and cloud infrastructure behind **langPeanut.
If you have ever tried using an LLM to localize an existing app, you probably noticed the same frustrating pattern: you feed a prompt 500 lines of React, Flutter, or Swift code, ask it to extract strings and replace them with localization hooks, and get back code that looks convincing at first glance—until you run the compiler.
Quotes get escaped incorrectly, JSX children trees get mangled, ICU plural syntax breaks, and comments silently vanish.
When we set out to build langPeanut, our goal wasn’t to build another "AI code generator." It was to solve localization as an AST boundary problem, not a text generation problem.
Here is how we built a multi-agent localization and SEO platform in Go, powered by Gemini 3.7 Flash, and deployed reliably to Google Cloud Compute Engine (GCE) with Google Cloud Pub/Sub.
1.
The "Zero-Generation" Principle The fundamental flaw with single-prompt LLM refactoring is giving the model write-access to the entire file structure.
In , the LLM is never allowed to rewrite a full source file.
Instead, we split the workflow into strict deterministic boundaries and narrow AI judgment: AST Scout (Deterministic): Uses tree-sitter grammars (Go, TypeScript, TSX, Dart, Swift, Kotlin) to pinpoint exact byte-ranges of user-facing strings at 0 token cost.
Context & Cultural Translation (Gemini 3.7 Flash): We call Gemini via the official Go GenAI SDK () only for linguistic judgment: Disambiguation: Is a button verb or an adjective?
ICU Preservation: Ensuring complex plural tags () remain syntactically identical across locales.
AST Patch Engine (Deterministic): Slices the original file by exact byte offsets and injects the localized hook ( or ).
Whitespace, comments, and un-targeted code remain 100% untouched.
On our 10-case adversarial benchmark (nested JSX expressions, Dart string interpolation, SwiftUI view modifiers), this approach achieved a 100% AST compilation pass rate with 0% formatting drift.
2.
The Three-System Architecture Rather than a single monolithic script, coordinates three specialized systems that share a single on-disk project state: System A — Localization Engine: The core 6-agent pipeline with a self-correcting 4-tier verifier and a bounded ReAct repair loop for edge-case compiler errors.
System B — Central AI Copilot (): A conversational control plane equipped with 19 registered tools.
If network access drops, it automatically falls back to a deterministic keyword router.
System C — SEO & Growth Studio (): A 5-agent pipeline (SERP Scout → Keyword Intelligence → Copy Weaver → SERP Simulator → Growth Critic) that optimizes translated copy for local search engine visibility directly against the same locale files.
3.
Production Deployment: Google Cloud Compute Engine & Pub/Sub Locally, runs as a zero-dependency CLI, TUI (Bubble Tea), or a zero-build Web Studio.
But for team workflows, we built langPeanut Cloud—a hosted GitHub App that monitors repositories, extracts strings on push, and automatically opens clean Pull Requests.
Running an automated agentic bot against arbitrary user repositories introduces two major infrastructure challenges: webhook reliability and execution sandboxing.
Challenge 1: The "Dropped Webhook" Problem (Solved by Cloud Pub/Sub) GitHub delivers push webhooks with a very short timeout and minimal retry persistence.
If a cloud server restarts during a deployment, hits a database lock, or receives a sudden burst of commits across multiple repositories, incoming webhooks can get dropped silently.
To guarantee zero dropped events, we placed Google Cloud Pub/Sub between our webhook ingestion gateway and our worker queue: When a webhook arrives, the ingestion handler validates the HMAC signature and immediately publishes the raw event to a Google Cloud Pu