Static Docs are Dead: How I Built a Global Documentation Engine with Gemini AI and Lingo.dev

Bhupendra Lute — Mon, 23 Feb 2026 07:20:38 +0000

Documentation is the silent killer of productivity. I’ve been there: you push a groundbreaking feature, but the README still points to the v1.0 architecture. Or worse, you have a global user base, but your documentation is a monolingual island.

That’s why I built PolyDocs during Lingo.dev hackathon #2.

PolyDocs is an automated, AI-driven documentation synchronization platform. It doesn't just store files; it listens to your repository, analyzes your code using LLMs, localizes it into multiple languages, and delivers it via Pull Requests—all without you touching a single Markdown file.

In this deep dive, I’ll take you through the architecture I designed, the technical pitfalls I hit, and the specific logic that makes PolyDocs a reality.

🏗️ The Architecture: A Symphony of Services

PolyDocs isn't just a script; it’s an ecosystem. To handle the complexity of Git operations, AI generation, and real-time dashboarding, I designed a multi-layered architecture from the ground up.

The Macro View

I built the system as a TypeScript Monorepo, ensuring type safety from the API routes down to the shared dashboard types.

🧠 Deep Dive: How the Features Work

1. The Intelligent Webhook Ingestor

I didn't want a simple endpoint. I needed a defensive one. I implemented a custom parser to keep the rawBody for cryptographic signature verification, ensuring requests actually come from GitHub.

// backend/src/index.ts - Custom parser for security
app.use(
  express.json({
    verify: (req: any, res, buf) => {
      req.rawBody = buf; // Preserving signature for Octokit validation
    },
  })
);

2. The Gemini + Lingo.dev Pipeline

This is the heart of PolyDocs. I didn't want to just "translate." I wanted to re-contextualize.

The Workflow:

Context Aggregation: I pull the top 10 most relevant code files to feed the LLM.
AI Synthesis: Gemini 2.0 Flash generates a technical README based on real code intent.
Native Localization: Lingo.dev transforms that README into Spanish, French, and Japanese.

I wrote the compiler logic to ensure it stays within LLM token limits while maintaining high accuracy:

// backend/src/services/compiler.ts - Selective Context
const codeFiles = treeData.tree
  .filter((file: any) => {
    return file.path.endsWith('.ts') || file.path.endsWith('.js');
  })
  .slice(0, 10); // Intelligent context windowing

🛠️ Technical Challenges & Solutions

Building this project solo meant I had to be my own architect, dev, and ops team. Here are the biggest hurdles I overcame:

Challenge 1: The Monorepo Docker Trap 📦

In a monorepo, the backend and frontend share a root package-lock.json. Initially, my Docker builds failed because they couldn't see the root dependencies.

My Solution: I designed root-context builds using multi-stage Dockerfiles. I selectively installed workspace dependencies, which kept the final images lean but the build context complete.

# backend/Dockerfile - Workspace Aware
COPY package*.json ./
COPY backend/package*.json ./backend/
RUN npm install -w @polydocs/backend

Challenge 2: The Cross-Platform Binary War ⚔️

During development on Windows, I hit a massive roadblock: Error: Cannot find module @rollup/rollup-linux-x64-musl.
Because my lockfile was generated on Windows, the Docker container (running Alpine Linux) couldn't find its required native binaries.

The Creative Fix:
I modified the Dockerfile to explicitly force-install the Linux-specific binary, effectively overriding the lockfile's platform restriction for the production environment.

# Forcing the platform-specific dependency during build
RUN npm install -w @polydocs/frontend && \
    npm install @rollup/rollup-linux-x64-musl

🎨 Design Philosophy: Premium

I wanted PolyDocs to feel like a high-end SaaS product. I used GSAP (GreenSock) for micro-interactions to make the dashboard feel alive.

I implemented a "staggered" load for build logs and repository cards to create a premium flow:

// frontend/src/pages/Dashboard.tsx
useEffect(() => {
  if (!loading) {
    gsap.from('.stagger-item', {
      y: 20,
      opacity: 0,
      stagger: 0.05,
      ease: 'power2.out',
    });
  }
}, [loading]);

🚀 Conclusion

Documentation should never be a chore. It should be a byproduct of great engineering. By combining Gemini AI with the Lingo.dev localization engine, I've created a system that removes the manual overhead of the documentation lifecycle.

Github Repository: PlyDocs

Never Let Language Barriers Stop Your Code: Introducing PolyComment 🌐

Bhupendra Lute — Thu, 05 Feb 2026 18:01:31 +0000

Imagine this: You're 36 hours into a global 48-hour hackathon. You’ve just pulled a brilliant open-source module into your project, but there’s a catch—all the internal logic comments and documentation are in a language you don't speak fluently.

You try to use a translator, but it’s a nightmare. Copy-pasting line by line takes forever. Generic AI tools often hallucinate and "translate" actual code syntax, turning your const data = [] into something like const information = [], breaking your build instantly.

This is why we built PolyComment.

🚀 The Vision: True Global Collaboration

PolyComment is a VS Code extension that understands that code and comments are two different beasts. It’s designed to help developers localize their comments and README files instantly, using the power of lingo.dev, without ever touching a single line of executable logic.

Why PolyComment is Different

Most translation tools treat your code like a giant block of text. PolyComment treats it like a tree.

Using AST (Abstract Syntax Tree) parsing, PolyComment "sees" your code like a compiler does. It explicitly skips keywords, variables, and logic, pinpointing only the human-readable strings—like JSDoc, single-line comments, and Markdown paragraphs.

🛠 Under the Hood: The "Source Code Story"

The biggest challenge in building PolyComment was Safety. In a hackathon setting, breaking the code is the ultimate sin.

We solved this using a two-pronged approach:

1. Smart Parsing (The Brain)

We integrated the TypeScript Compiler API and the Unified/Remark ecosystem. Instead of using fragile Regex, we use a scanner that identifies ts.SyntaxKind.SingleLineCommentTrivia. This ensures that even if your comment contains code-like symbols, the parser knows it’s just a comment.

2. The Diff Preview (The Shield)

We didn't want to just "overwrite" your hard work. Every translation in PolyComment opens in a side-by-side VS Code Diff View. You can see exactly what the AI changed, verify the translation, and only then click "Apply."

📖 How to Use It (Tutorial)

Step 1: Secure Your Setup

PolyComment stores your lingo.dev API keys securely using VS Code's SecretsStorage. No plain-text keys in your settings!

Step 2: Set Your Target

Open the PolyComment sidebar and select your target language from over 10+ supported options including Japanese, Spanish, Hindi, and French.

Step 3: Magic in One Click

Either highlight a specific block of code or run the command to translate the entire file.

Step 4: Review and Verify

Review the localized comments in the Diff view. Once you're happy, hit Apply!

🌍 Moving Forward

The goal of PolyComment isn't just to translate text—it's to make the world's most innovative codebases accessible to everyone, regardless of what language they grew up speaking.

Want to try it out?
Check out our repository PolyComment on GitHub and start localizing your next big project!

Shoutouts

Special thanks to lingo.dev for providing the localization engine that makes this seamless.

DEV Community: Bhupendra Lute