Meet the Builder: How I went from intern to shipping a production RAG assistant

Contents

• Who I am
• How I got here
• What I build every day
• The bug I'm proudest of fixing
• Why the Gen AI Academy fits how I build

- Where I want to take this next

Who I am

I'm Ganesh Dhakali, a Gen AI full-stack developer based in Bengaluru. I build AI-powered products — the part of the stack where a large language model stops being a demo and becomes something real users depend on.

My north star as an engineer is simple: the data is the moat, the AI is the interface. A model is only as good as the context you can put in front of it, and getting that context right — retrieval, grounding, latency, scale — is the work I actually enjoy.

How I got here

I started as an intern and converted to a full-time engineer on the strength of one thing: shipping an AI feature end to end, from an empty database to a streaming response in a user's browser. I didn't come from a research background or a big-tech pipeline. I learned by building the whole thing myself — backend, frontend, the data plumbing in between — and debugging it in production when it broke.

That "figure it out and ship it" path is the one I want to keep walking. I like owning a feature from architecture to deployment, and I like problems where the answer isn't in a tutorial.

What I build every day

I build RAG-powered conversational assistants — systems that let people ask plain-language questions and get grounded answers drawn from a real knowledge base, not made-up ones.

Under the hood, this is the kind of system I love working on:

• A retrieval-augmented generation pipeline orchestrated as a multi-node graph — session validation, intent classification, retrieval, context assembly, streamed response, persistence.
• Vector search over pgvector, with an embedding pipeline that turns a large knowledge base into something a model can actually reason over.
• An LLM layer I deliberately kept swappable — one that runs a local model in development and a hosted frontier model in production, switched by a single config value, so the model stays a replaceable part rather than something welded into the code.
• Real-time token streaming to the frontend, so answers feel alive instead of arriving in one lump. I care about doing this the disciplined way: secure APIs, proper auth, clean Git flow, separate QA and production environments, and logging the model's calls so I can actually see what it's doing.

The bug I'm proudest of fixing

Here's the war story I tell people, because it captures why I like this work.

After a bulk load of embeddings, my vector search started returning zero results — no error, no exception, no stack trace. Everything looked fine. I traced it down to the vector index having been built on an empty table, which left its internal clusters meaningless, so every similarity query silently matched nothing.

The fix was small once I understood it — rebuild the index after every bulk load — but finding it meant reasoning about how the database actually organizes vectors, not just how the API is supposed to behave. That's the layer I like living in: close enough to the metal to know why something breaks, not just that it did.

Why the Gen AI Academy fits how I build

When I looked at the Google Cloud Gen AI Academy APAC, it didn't feel like a course — it felt like a map of exactly where my own work is heading.

• Agents. I already orchestrate my pipeline as a graph of steps. Thinking about those steps as first-class, deployable agents is the natural next evolution of how I build — and it's a direction I want to go deeper on.
• Model Context Protocol (MCP). Right now every data source in my systems is a bespoke integration I hand-wrote. MCP is the standard I'd been wanting: expose a tool or a data source once, and let any agent use it through a common interface. For a product that keeps adding new kinds of data, that's the clean way to scale — and it's exactly the kind of infrastructure problem I want to work on.
• AI-ready databases. My whole retrieval layer lives on Postgres and pgvector, so a production-grade, vector-native database tier isn't a new concept for me — it's the tier my current stack grows into. Treating embeddings as a real database workload rather than a bolted-on extension is how I already think. That's what drew me in: this isn't a program that would teach me a topic from scratch. It lines up, point for point, with the systems I already build and the ones I want to build next.

Where I want to take this next

I want to keep building production AI, not prototypes — systems that real people use, that scale from a small knowledge base to a large one, that stay maintainable when the model or the data source changes underneath them.

Concretely, the directions I'm most excited about are the ones this program is built around: agent-based architectures, MCP-driven integrations, and databases that treat vectors as a first-class citizen. I came into this able to ship a RAG assistant on my own. What I'm after now is the vocabulary, the tooling, and the scale patterns to build the next one right.

If that's the kind of work you do too, I'd love to compare notes.

— Ganesh Dhakali · linkedin