Plan: 90-Day AI Ramp for Backend Engineers

You’re not switching to an ML role. You’re staying in backend engineering. But your team is increasingly building with LLMs, your product is integrating AI features, and you’re expected to have opinions about embeddings, model serving, and RAG by next quarter. This plan gets you there in 90 days while you continue shipping your current work.

Who this is for

A backend engineer (IC3–IC5) who needs to be AI-literate at their current job, not AI-specialized. Your team is adopting AI features (LLM-powered search, copilot features, generative content, embeddings for recommendations), and you need to participate meaningfully in design reviews, architecture discussions, and implementation — without becoming the team’s ML engineer.

What this plan assumes

• Baseline. You can design APIs, you understand distributed systems, you ship production code. You don’t need “intro to programming” or “what is an API.”
• Time commitment. ~60 hours over 90 days. That’s ~4.5 hrs/week — roughly one evening plus one weekend morning. Designed to fit alongside a full-time job.
• Goal. This is a plan to become AI-competent at your current job, not to transition into an AI role. The distinction matters: you need to use AI in your existing engineering work, participate in AI architecture decisions, and evaluate AI tool choices — not to train models or publish papers.
• Scope. Three domains: understanding the stack, building with AI APIs, and making informed architectural decisions.
• Out of scope. ML theory, model training, fine-tuning, research. If you want to transition roles, see the MLE transition plan or AI infra transition plan instead.

One assumption worth naming: the backend engineer who can reason about AI system architecture — where to put the model call, what to cache, how to eval, when to use retrieval vs long context — is more valuable to most product teams than an ML specialist who can’t ship production systems. This plan makes you that engineer.

The three domains

The plan

Three phases, one per month. Each phase has a concrete deliverable — not just “understand X” but “ship X” or “present X.”

Phase 1: Understand the stack (Days 1–30, ~5 hrs/week)

Build the mental model. After this phase, you can participate in AI architecture discussions without faking it.

Week 1–2: How LLMs work (conceptual)

• What a token is. How tokenization works. Why “context window” matters and what hits the limit.
• What temperature, top-p, and max_tokens do. Why deterministic output isn’t free.
• What an embedding is — a fixed-length vector that captures semantic similarity. Why cosine similarity works.
• Read The Illustrated Transformer — one afternoon, builds the right mental model of attention.

Week 3–4: How AI systems work (architectural)

• The RAG pattern: retrieve context, augment the prompt, generate an answer. When to use it, when long context is enough.
• How inference serving works at a high level: batching, KV cache, why latency is variable and depends on output length. The LLM serving walkthrough is the full version; read the first four sections.
• What tool calling / function calling is and how it works (the model generates structured output that your code dispatches).
• What eval means for AI features: why “does it work?” isn’t a valid test and what you measure instead.

Deliverable: write a one-page internal doc titled “How our AI feature works” for one AI feature at your company (or a product you use). Map the architecture: what’s the model, what’s the context, what’s the retrieval, what’s the eval. Share it with your team.

Milestone: you can explain, in a design review, why a RAG system needs a retrieval step (the model doesn’t have the data) and why long-context alone doesn’t solve it at scale (cost, latency, and the lost-in-the-middle problem).

Phase 2: Build with AI APIs (Days 31–60, ~6 hrs/week)

Ship something. Small is fine. The point is to move from conceptual to hands-on.

Week 5–6: Your first AI integration

• Pick a small, real problem at work (or a side project):
  • Semantic search over internal docs
  • A CLI tool that answers questions about your codebase
  • An API that classifies customer support tickets
  • A summarizer for long Slack threads
• Implement it using a model API (Claude, OpenAI). Use structured output. Handle errors, rate limits, timeouts. This should feel like calling any other third-party API — because it is.

Week 7–8: Add retrieval

• Add a vector search component to your project. Embed documents with an embedding model, store in a vector database (pgvector, Pinecone, Chroma — any is fine), retrieve on query.
• Implement the RAG pattern: retrieve → construct prompt → generate.
• Add basic eval: 20 test queries with expected-answer annotations. Measure retrieval recall and answer quality. This is the minimum viable eval.

Deliverable: a working prototype (deployed or demo-able) that uses retrieval + generation and has a measured eval baseline.

Milestone: you can build an AI feature end-to-end using existing APIs and infrastructure. You’ve hit at least one real problem (context length, retrieval quality, latency, cost) and resolved it.

Phase 3: Architectural judgment (Days 61–90, ~5 hrs/week)

Turn your hands-on experience into judgment you can apply to your team’s real decisions.

Week 9–10: Cost, latency, and caching

• Understand the cost model: input tokens vs output tokens, model size vs cost, caching (prompt caching) and its impact.
• Learn when to use a small model vs a large one. The decision framework: complexity of task × acceptable error rate × latency budget × cost budget. Most classification tasks don’t need the largest model.
• Understand where to cache in an AI system: response caching (deterministic queries), prefix caching (shared system prompts), embedding caching (documents don’t change often). Each saves different costs.

Week 11–12: Making AI architecture decisions

• Read the What’s Durable vs What’s Hype framework — sort what to keep learning from what to ignore.
• For one real AI feature at your company (or a planned one): write a design decision doc that covers model choice, retrieval strategy, eval plan, cost estimate, and the failure modes you’d monitor.
• Present it in a design review or discuss with your tech lead.

Deliverable: a design decision doc for a real (or proposed) AI feature that demonstrates architectural judgment — not just “use Claude” but why this model, what retrieval, how to eval, what to monitor.

Milestone: your tech lead or manager would trust you to own the architecture of an AI-powered feature. Not the ML — the system around the ML.

Milestones by phase

Resources

Understanding the stack

• The Illustrated Transformer — one afternoon, builds the attention mental model.
• calm.rocks: Designing a RAG System — the full architectural walkthrough.
• Anthropic’s prompt engineering guide — practical, well-structured, free.
• Skip: full ML courses (too deep for this goal), “intro to AI” content (too shallow), transformer papers (the illustrated version is enough).

Building with AI APIs

• Anthropic SDK docs — why this: well-documented, streaming support, tool use built in.
• pgvector — why this: if you’re already on Postgres, adding vector search is one extension install away. No new infra.
• LangChain — why this (with caveats): useful for prototyping RAG quickly, but don’t couple tightly to it. Learn the pattern, not the framework. See the durable-vs-hype framework on why.
• Skip: building your own embedding model, building your own vector database, anything that says “from scratch” when an API exists.

Architectural judgment

• calm.rocks: What’s Durable vs What’s Hype — the sorting framework for ongoing learning.
• calm.rocks: AI/ML System Design — What’s Different — helpful even if you’re not interviewing; the three-layer mental model applies to real design work.
• Skip: AI strategy/positioning content aimed at executives. You’re an engineer; your judgment comes from building, not from reading strategy memos.

What to cut if time is short

If you have 30 days instead of 90:

• Phase 1: compress to 1 week. Read the Illustrated Transformer + the RAG walkthrough. Skip the rest.
• Phase 2: build the simplest possible thing (a single API call with structured output, no retrieval). 2 weeks.
• Phase 3: skip the design doc. Replace with one 30-minute conversation with your tech lead about an AI architecture decision.
• You’ll have surface-level competence and one hands-on reference point. Enough to not be lost in meetings.

Never cut:

• Building something (even tiny). Reading without building produces no muscle memory and no stories.
• Understanding what eval means. “It seems to work” is the phrase that gets AI features killed in production. Know why measurement matters, even if your first eval is only 20 test cases.

Cut without guilt:

• ML theory. You don’t need it for this goal.
• Multiple prototypes. One is enough.
• Deep cost optimization (learn on the job when you’re spending real money).
• Anything about training or fine-tuning.

Common failure modes

Reading without building. The single most common failure. You read 10 blog posts about RAG and feel informed but can’t implement it. The Phase 2 deliverable exists to break this pattern. Ship something ugly. Improve it later.

Going too deep too early. Spending week 1 reading the attention- is-all-you-need paper in full, implementing a transformer from scratch, or setting up a local LLM. None of this helps you participate in next week’s design review. Start from the API level and go deeper only when a specific question demands it.

Confusing “using AI tools” with “understanding AI systems.” Using Cursor or Claude Code to write code faster is valuable but doesn’t build architectural judgment about AI systems. This plan is about the latter — understanding how AI features are built, not just using AI as a dev tool.

Trying to become the team’s ML expert. You’re not transitioning roles. You’re building enough understanding to be a competent systems engineer on AI features. The ML decisions (which model, which fine-tuning approach, which embedding model) can stay with the ML specialists or be outsourced to the model provider. Your value is the system around the model.

Treating all AI as LLMs. Your team may be using classical ML (gradient boosting for ranking, logistic regression for fraud scoring) alongside LLMs. The 90-day plan focuses on LLM-era tools because that’s where the demand is shifting, but don’t over-rotate — understanding that different problems call for different model types (including no model at all) is part of architectural judgment.

After the 90 days

You’re not done learning — you’re done ramping. From here:

• Keep the durable-vs-hype framework as your filter for what to study next.
• When your team ships the next AI feature, volunteer to own a piece of the system (the serving layer, the eval pipeline, the retrieval component). Apply the project alignment framework to pick which piece grows your career signal.
• If you find that you want to go deeper into AI roles, the MLE transition plan or AI infra plan is the next step.

Related

• Framework: What’s Durable vs What’s Hype — the ongoing sorting framework after this 90-day ramp.
• Plan: Transitioning to Machine Learning Engineer — if you decide to make the full career switch.
• Plan: Transitioning to AI Infrastructure Engineer — the systems-focused AI career path.
• Walkthrough: Designing a RAG System — the canonical AI architecture pattern in full depth.