DEV Community: Gaurav Thorat

I wrote a song about vibe coding (and built the whole music video with AI agents)

Gaurav Thorat — Tue, 01 Sep 2026 02:53:46 +0000

I used to write code. Now I write prompts. Then I review the code I didn't write. Then I fix the bugs the AI created.

At some point this year that stopped being a complaint and started being... a chorus. So I made it one - a full 6-minute song about being a developer in 2026:

It has verses about vibe coding, the AI subscription stack ("my wallet says please stop, my brain says one more tool"), and the day I gave my coding agent one tiny task and it opened seventeen pull requests.

The part you'll actually find interesting: the video is agent-built too

I decided the production itself should prove the song's point. Almost the entire music video was produced by an AI agent (Claude Code) working autonomously while I was out:

The song — generated from my lyric sheet (fun discovery: the generator silently dropped my spoken outro and invented a reprise instead; nobody reads the spec, not even the music AI).
The shot map — the agent transcribed the finished track with Whisper, cross-checked section boundaries against an RMS energy profile, and turned it into a 60-segment edit decision list with real timecodes.
The character clips — 16 scenes from an image-to-video model, kept consistent with a 4-image reference kit (full-body sheet, smiling portrait, deadpan portrait, set reference). Every one was approved on the first take, which never happens.
The screen gags — the fake PR list with 17 open PRs, the "you're almost out of tokens" modal, the receipt wall — all rendered programmatically (PIL frames piped to ffmpeg) because you can't screen-record a browser while you're not home.
The assembly — a Python EDL driving ffmpeg: per-segment cuts, concat, the song muxed as the timeline master.

Total human contribution to the edit: reviewing takes, catching alignment bugs, and one deeply 2026 code review comment: "the receipts are crooked."

Things I learned that transfer to real work

Reference kits beat prompts for consistency. Sixteen video generations with the same face only worked because every prompt attached the same four reference images. Same lesson as agent context engineering: don't describe, attach.
Transcribe your media before editing it. Whisper timestamps turned a vibes-based edit into a deterministic script. The whole cut is reproducible from one Python file.
Fonts lie. PIL's glyph probe said Helvetica had ✓ and ✗. It rendered tofu boxes. Trust rendered pixels, not APIs — which is basically the song's thesis, applied to typography.

The question the song ends on

The tests are green. I don't know how it works. But hey — the tests are green.

Which verse is your life right now? For me it's the subscriptions one. My credit card knows all the Pro plans by heart.

(Full song: https://youtu.be/TLDh-_AiZVk — and if you want the production pipeline details, the tools are a few hundred lines of Python + ffmpeg; happy to write that up if there's interest.)

Why Your React Frontend Crashes When an LLM Streams Malformed JSON

Gaurav Thorat — Tue, 09 Jun 2026 09:50:02 +0000

A production-minded walkthrough with a live Next.js demo — JSON.parse() vs partial-json + Zod for real-time AI dashboards.

canonical: https://gauravthorat-portfolio.vercel.app/blog/react-llm-stream-json-parser

Why 99% of RAG Apps Crash in Production (Naive vs Scaled Node.js)

Gaurav Thorat — Fri, 29 May 2026 14:01:10 +0000

Disclosure: I am a frontend developer transitioning into AI engineering, sharing real experiments and learnings from building production-style RAG systems.

Your RAG pipeline works perfectly on Friday. Then Monday hits. 1,000 users query at once. Suddenly everything breaks: 502 errors, ECONNRESET, OpenAI 429 rate limits, Pinecone timeouts. The demo wasn't wrong—it just wasn't built for production concurrency.

Video: https://youtu.be/-2aS3Yl5-5M

Code: https://github.com/gauravthorath/rag-scale-demo

Full article: https://gauravthorat-portfolio.vercel.app/blog/rag-production-architecture

The Monday morning problem

Locally: chunk docs → embed → upsert to Pinecone → query → LLM. Simple.

Under load: socket exhaustion, connection pool saturation, API 429s, token costs exploding.

Naive RAG (what most people build first)

for (let i = 0; i < SAMPLE_CHUNKS.length; i++) {
  const values = await embedOne(openai, embedModel, SAMPLE_CHUNKS[i]);
  vectors.push({ id: `demo-naive-${i}`, values, metadata: { text } });
}

const pinecone = new Pinecone({ apiKey: pineconeKey });
for (const v of vectors) {
  await index.namespace(DEMO_NAMESPACE).upsert([v]);
}

Why it breaks at scale:

One embedding call per chunk
One upsert per vector
No batching, no connection reuse, no retries
New client instances repeatedly

3 chunks × 1,000 users × retries = thousands of outbound API calls. Sockets and rate limits run out fast.

Production pattern

Same RAG logic. Better infrastructure.

Singleton Pinecone client:

let client: Pinecone | undefined;
let indexCache = new Map<string, Index>();

export const getPineconeIndex = (indexName?: string): Index => {
  const name = indexName ?? getEnv().PINECONE_INDEX_NAME;
  let idx = indexCache.get(name);
  if (!idx) {
    idx = getPineconeClient().index(name);
    indexCache.set(name, idx);
  }
  return idx;
};

Embedding batching:

const res = await openai.embeddings.create({
  model: model,
  input: inputs,
});

64 texts → 1 API call instead of 64. Big win on latency, cost, and rate limits.

In-process batching only. For multiple servers, add Redis caching and a task queue.

Naive vs production

Naive	Production
New Pinecone client per call	Singleton client
One embedding per chunk	Batched embeddings
One upsert per vector	Bulk upsert
Raw env vars	Zod validation
No retries	Backoff + retry
No metrics	Tracing + metrics

Before real scale

Exponential backoff + jitter on OpenAI and Pinecone
Top-K + reranking (don't dump every chunk into the prompt)
Distributed rate limiting across instances
Metrics: embed latency, retrieval quality, token usage
Stable vector IDs for safe retries

Try it

git clone https://github.com/gauravthorath/rag-scale-demo
cd rag-scale-demo
cp .env.example .env
npm install
npm run naive
npm run production

Use separate Pinecone namespaces so runs don't overwrite each other.

Final thoughts

Most RAG tutorials stop at "it answers my PDF." Production is about surviving concurrency, retries, rate limits, and cost pressure.

Questions or repo fixes? Drop a comment. I reply here and on YouTube.

Originally published on my portfolio: https://gauravthorat-portfolio.vercel.app/blog/rag-production-architecture