AI Engineer vs. Research Scientist: Know Which Path You're On
Before diving in, it’s worth understanding the fork in the road, because it changes what you should actually study.
AI Research Scientists push the boundary of what models can do — designing new architectures, training models from scratch, and publishing novel findings. This path requires deep math, PyTorch/JAX internals, distributed training experience, and typically a PhD.
AI Engineers take existing models — built by labs like Anthropic and OpenAI — and turn them into reliable, working products: chatbots, internal tools, automated workflows. This path leans on the exact skills a backend developer already has: system design, APIs, databases, caching, and testing. A research scientist asks: “How do I make the model itself better?” An engineer asks: “How do I build a dependable system around a model that already exists?” Most AI jobs today — and the highest-paying ones outside a handful of research labs — are engineering roles. That’s the path this roadmap targets.
Stage 1: Using AI as an API (Weeks 1–3)
This is the fastest way to ship something real, and it’s where your backend skills transfer directly.
What to learn:
- How LLM APIs work: prompt → tokens → completion → response
- Prompt engineering: system prompts, few-shot examples, structured JSON output
- Function calling / tool use
- Streaming responses (SSE)
- Rate limits, retries, cost management, token counting
Why it matters: This is roughly 80% of real-world “AI engineering” work. Companies need reliable backend systems wrapped around a model API — auth, caching, retries, logging, cost control — the same way they’d wrap a payments API like Stripe.
Example project — Smart Support Ticket Router: Build a backend service that accepts support tickets via a REST API, classifies them with an LLM (billing / bug / feature request / spam), extracts structured data like priority and sentiment, and routes them into a queue. Add retry logic and token-cost logging.
Stack: FastAPI/Express/Django + Postgres + Redis + an LLM API
Stage 2: Retrieval-Augmented Generation (RAG) (Weeks 3–6)
What to learn:
- Embeddings and similarity search
- Vector databases: pgvector, Pinecone, Qdrant, Weaviate, Chroma
- Document chunking strategies
- The full RAG pipeline: ingest → chunk → embed → store → retrieve → augment → generate
- Reranking and retrieval evaluation
Why it matters: RAG is fundamentally a search and indexing problem wrapped around an LLM — your database experience applies directly. It’s also the single most requested “AI feature” in the market: chat-with-your-docs, internal knowledge bases, and support bots.
Example project — Company Knowledge Base Chatbot: Ingest a folder of PDFs or Markdown docs, chunk and embed them, store vectors in pgvector (no new database to learn), and expose an /ask endpoint that retrieves relevant context and returns a cited answer. Add a small evaluation script to measure retrieval accuracy.
Stack: FastAPI + Postgres/pgvector + LLM API
Stage 3: Agents & Tool-Using Systems (Weeks 6–10)
What to learn:
- What an “agent” is: an LLM in a loop, calling tools, observing results, deciding the next step
- Multi-step orchestration and state management
- Guardrails: action limits, human-in-the-loop approval, timeouts, loop prevention
- Frameworks like LangChain/LangGraph (learn the raw loop first)
- Model Context Protocol (MCP)
Why it matters: Agents are backend orchestration systems where an LLM makes routing decisions instead of hardcoded logic. Experience with job queues and workflow engines maps directly onto this.
Example project — Autonomous Bug Triage Agent: Build an agent that reads a new GitHub issue, searches for duplicates, drafts a suggested response, and requires human approval before posting anything. Log every decision step for debuggability.
Stack: Your backend framework + LLM function calling + GitHub API + a state-tracking table
Stage 4: Understanding Models Themselves (Weeks 10–16, Optional)
What to learn:
- Transformer architecture at a conceptual level
- Fine-tuning vs. RAG vs. prompting — when to use each
- Running open-source models locally (Ollama, vLLM)
- Evaluation and benchmarking basics
- Quantization basics
Example project — Local Model Fallback System: Route simple queries to a local open-source model and complex ones to a hosted API, optimizing for cost. Fine-tune a small model on a narrow task and compare it against the hosted version on accuracy, latency, and cost.
Stack: Ollama or vLLM + Hugging Face + your existing backend
Stage 5: Production AI Systems (Ongoing)
This is where backend engineers pull ahead, because production AI systems are mostly classic engineering problems.
What to learn:
- Observability: logging prompts/responses, tracing agent runs
- Cost control: caching, model routing, token budgets
- Safety: prompt injection defense, output sanitization, PII handling
- Testing non-deterministic systems: snapshot testing, LLM-as-judge evaluation
- Latency optimization: streaming, caching, model selection
Capstone project — Production-Grade RAG API: Take the Stage 2 project and make it production-ready: authentication, rate limiting, a semantic cache, full request tracing, an automated eval pipeline, prompt-injection defenses, and deployment with monitoring.
Suggested Timeline
| Weeks | Focus |
|---|---|
| 1–3 | LLM APIs, prompting, function calling |
| 3–6 | RAG + vector databases |
| 6–10 | Agents + orchestration |
| 10–16 | Model internals (optional) |
| Ongoing | Production hardening, observability, cost/safety |
Roughly 3–4 months to go from backend developer to an engineer who can ship real AI products — as long as you build the projects, not just read about them.
Key Resources
- Andrej Karpathy (YouTube): “Let’s build GPT,” “Intro to Large Language Models”
- Anthropic & OpenAI documentation for current API patterns and prompting guides
- LangChain/LlamaIndex docs once you understand the underlying concepts
- Hugging Face course (huggingface.co/learn) for deeper model internals
- “Designing Machine Learning Systems” by Chip Huyen for the production/systems side
The Core Mindset Shift
As a backend developer, you’re used to deterministic systems: same input, same output. AI systems are probabilistic: same input, usually similar output. The real skill isn’t making the model smarter — it’s building a reliable, observable, cost-controlled system around an unreliable, probabilistic component. That shift is what separates developers who just call an API from engineers who build real AI products.
Found this roadmap useful? Bookmark it and follow along as we build out each project stage-by-stage on Big Buzz Ideas.
