Most of my career has been backend-heavy: .NET, clean architecture, CQRS, the kind of systems where correctness and uptime matter more than anything else. So it might seem like a left turn to start spending evenings on LangChain, embeddings, and RAG pipelines. It isn't — it's the same instinct applied to a newer kind of system.
Why RAG specifically
A lot of "AI engineering" content focuses on prompting. RAG is different: it's an architecture problem. You're designing how data gets chunked, embedded, indexed, retrieved, and re-ranked before it ever reaches a model — and every one of those steps has the same kind of correctness and performance tradeoffs I'm used to thinking about in a normal data pipeline.
That's the part that clicked for me. An LLM call without good retrieval is a guess. An LLM call with a well-designed retrieval layer is closer to a query against a system you understand.
How I'm approaching it
- Building small, real things instead of just reading papers: a semantic search tool over a personal knowledge base, an agent that can answer questions about a codebase using embeddings instead of grepping blindly.
- Treating evaluation as a first-class concern, the same way I'd treat test coverage on a backend service — if I can't measure whether a RAG pipeline got better, I'm not actually engineering it.
- Staying close to tools I'd realistically use in production: LangChain, OpenAI's and Anthropic's APIs, and increasingly Claude Code itself as a way to pair on this work.
Where this is going
I don't think this replaces backend engineering — I think it becomes part of it. The systems I build next will probably have a retrieval layer the same way they have a database layer today, and I'd rather be the person who understands how that layer actually works than the person who just calls an API and hopes.
