DEV Community: Rahul

I Built a Real-Time Multilingual Dubbing Platform and Used TestSprite MCP to Test It

Rahul — Fri, 17 Apr 2026 19:54:14 +0000

What if you could speak, and everyone listening heard you in their own language, with no noticeable delay?

That question turned into PolyDub.

What It Does

Three modes:

Live Broadcast: one speaker, listeners worldwide, each hearing a dubbed stream in their language
Multilingual Rooms: everyone speaks their own language, everyone hears everyone else in theirs
VOD Dubbing: upload a video, download a dubbed MP4 with SRT subtitles

The real-time pipeline:

Mic -> WebSocket -> Deepgram Nova-2 (STT) -> Google Translate (~300ms) -> Deepgram Aura-2 (TTS) -> Speaker

Perceived latency is around 1.2 to 1.5 seconds. Fast enough for a real conversation.

A Few Decisions Worth Explaining

Why Google Translate instead of Lingo.dev for real-time? Lingo.dev is LLM-based, which means 5 to 8 seconds of latency. Fine for batch work, not for live speech. Google's gtx endpoint runs at 250 to 350ms warm. Lingo.dev is still in the project, compiling UI strings at build time across 15 locales.

Why Deepgram Aura-2? Aura v1 only shipped English voices regardless of the language param. Aura-2 ships genuinely native-accent voices: Japanese prosody, Spanish regional variation, German intonation. Using an English voice mispronouncing another language defeats the entire product.

Why a per-listener TTS queue? In a room with multiple speakers, audio chunks from different people arrive at the same socket in parallel. Without serialization they interleave into noise. A per-socket promise chain fixes this, and the queue depth is capped at 1 so stale utterances get dropped rather than building an 8-second backlog.

Screenshots

Broadcast mode: pick source and target languages, hit Start, share the listener link.

Rooms: each participant sets their own language and voice. The server handles translation per-person.

VOD: upload a video, pick a language, get a dubbed MP4 and SRT file back.

Testing With TestSprite MCP

The project was built under hackathon pressure. Third-party APIs can fail in specific ways. Frontend validation is easy to break quietly. Writing full test coverage by hand would have eaten most of the remaining build time.

TestSprite MCP plugs into Claude Code as an MCP server. It reads the codebase, generates a test plan, and writes runnable test code. I ran it twice: once for a baseline, and again after a round of fixes.

Backend tests generated (5/5 passing):

Test	What it checks
TC001	`POST /api/dub` with valid file returns `{ srt, mp3 }`
TC002	`POST /api/dub` with missing params returns 400
TC003	`POST /api/dub` with broken third-party API returns 500
TC004	`POST /api/mux` with valid inputs returns `video/mp4` stream
TC005	`POST /api/mux` with missing inputs returns 400

The generated code is more thorough than what you'd write in a hurry. TC001 builds a minimal valid WAV file inline, validates the base64 response actually decodes, and checks the SRT string is non-empty:

mp3_bytes = base64.b64decode(json_data["mp3"], validate=True)
assert len(mp3_bytes) > 0
assert "srt" in json_data and len(json_data["srt"].strip()) > 0

Frontend tests generated (12 cases): broadcast start and validation, room create/join/leave/rejoin, language and voice change in-session, VOD upload validation, and landing-to-mode navigation flows.

What the first run caught:

/api/dub was returning a plain string in some error paths instead of a consistent JSON shape. TC003 found it.
The room ID field was letting through malformed IDs before hitting the server. TC009 found it.

Fixed both, reran, all clean. The dashboard keeps a full run history so you can diff before and after. That is the actual useful part: not a single passing run, but a record of what broke, what changed, and whether the fix held.

Running It

git clone https://github.com/your-username/polydub
cd polydub
pnpm install
cp .env.example .env
# set DEEPGRAM_API_KEY and LINGO_API_KEY in .env

pnpm dev     # terminal 1: Next.js on :3000
pnpm server  # terminal 2: WebSocket server on :8080

Github: https://github.com/crypticsaiyan/PolyDub

AutoFinance: Your AI Financial Command Center, right inside the terminal!

Rahul — Mon, 16 Feb 2026 06:22:07 +0000

This is a submission for the GitHub Copilot CLI Challenge

Why Leave the Terminal?

As developers, we live in the terminal. So why do we keep switching to 20 different browser tabs just to check market volatility, technical indicators, or portfolio drift?

I wanted to see if I could build a professional-grade financial research desk that lives exactly where I do. The result is AutoFinance: a heavy-duty orchestration of 13 specialized MCP (Model Context Protocol) servers that turn your command line into a high-speed financial command center.

Demo

The 13-Server Engine Room

To power these agents, I stood up 13 microservices using the Model Context Protocol. Each server handles a specific domain:

Port	Server	Responsibility
9001	Market	Real-time data via Yahoo Finance & Binance
9002	Risk	Automated trade validation and position sizing
9005	Technical	Crunches RSI, MACD, and Bollinger Bands
9006	Fundamental	P/E ratios, ROE, and growth metrics
9008	News	Local sentiment analysis on market headlines
9012	Simulation	Monte Carlo scenarios for stress testing

Key Features

📈 Real-Time Market Data: Connects directly to Yahoo Finance and Binance (via WebSockets) to stream live prices. No staleness—just raw, real-time data.
📡 Multi-Channel Global Notifications: Never miss a beat. The system pushes critical alerts to where you actually live:
- Slack & Discord: Get trade confirmations, price spikes, and agent debates in your channels.
- SMS & WhatsApp: Urgent margin calls or crash alerts sent directly to your phone.
- Email: Daily portfolio summaries and audit reports.
🛡️ Automated Risk Guardrails: The Risk Server enforces strict position limits (max 5%) and stop-losses automatically. It rejects any trade that violates your pre-set safety policy.
💬 Natural Language Interface: Deep copilot CLI integration lets you "chat" with your portfolio. "Hey, sell half my Bitcoin if RSI > 80."
📊 Comprehensive Analysis:
- Technical: Real-time RSI, MACD, and Bollinger Bands.
- Fundamental: P/E ratios, ROE, and growth metrics.
- Sentiment: Scans news headlines to gauge the current market mood.

How GitHub Copilot CLI Saved My Sanity

It helped me build this project in less than 36 hours!!

AutoFinance/
├── .github/                       # COPILOT BRAIN 🧠
│   ├── copilot-instructions.md    # The "Bible" (Context & Rules)
│   ├── mcp-config.json            # Local MCP Server Config
│   ├── agents/                    # Specialized Personas
│   │   ├── mcp-server-developer.md
│   │   ├── financial-analyst.md
│   │   ├── cli-dashboard-dev.md
│   │   └── test-engineer.md
│   ├── skills/                    # Reusable Knowledge
│   │   ├── financial-data-validation/
│   │   ├── mcp-server-debugging/
│   │   └── technical-analysis-impl/
│   ├── instructions/              # Path-Specific Context
│   │   ├── mcp-servers.md
│   │   └── tests.md
│   └── hooks/                     # Automation Scripts
│       └── hooks.json             # Pre/Post-execution logic
├── mcp-servers/                   # THE 13 MICROSERVICES
│   ├── market/                    # Yahoo Finance Integration
│   ├── technical/                 # RSI/MACD/Bollinger Logic
│   ├── sentiment/                 # NewsAPI + LLM Analyzer
│   ├── risk/                      # Compliance & Limits Engine
│   └── ... (10 others)
└── cli/                           # The Textual Dashboard UI

(I specifically organized .github/ to leverage Copilot's ability to read configuration files. This ensures every suggestion respects the project's architecture.)

Building a system with 13 microservices is not easy. Honestly, if I had to manually manage the boilerplate for every server, I’d still be writing imports.

Here is how Copilot CLI helped me:

1. The @mcp-server-developer Persona

I defined custom instructions so Copilot knew exactly how I wanted my MCP servers structured. When I needed the Volatility Server, I didn't write code; I just talked to my terminal:

copilot --agent=mcp-server-developer "Create a volatility server on port 9010 using our standard SSE transport."
It generated the Pydantic models and error handling that matched the rest of my stack perfectly.

2. Local MCP Integration

I configured Copilot CLI to actually talk to my running AutoFinance servers. By mapping my local tools in ~/.copilot/mcp-config.json, I could ask the CLI real-time questions:

Me: "What's the current RSI for NVDA?"
Copilot: "The current RSI for NVDA is 72.4 (Overbought). Recommendation: Wait for a pullback."
It bridged the gap between a coding assistant and a production console.

3. Living Documentation

Using .github/copilot-instructions.md, I gave Copilot the knowledge of the project—things like port ranges and "no hardcoded API keys" policy. This meant I never had to correct it on the small stuff. It just knew the architecture.

Screenshots

Landing UI

Dashboard

Setup in 30 Seconds

git clone https://github.com/crypticsaiyan/AutoFinance.git
pip install -r mcp-servers/requirements.txt
pip install -r cli/requirements.txt
./start_sse_servers.sh  # Fire up the 13-server swarm
python cli/main.py      # Launch the Command Center
# see the repo for more advanced setup

I really enjoyed and learnt a lot making this project (plus burnt a lot of credits too :P)

made by: crypticsaiyan
GitHub Repository: crypticsaiyan/AutoFinance