AI engineering, drawn as systems

The roadmap is an ordered path of 9 stages. Each stage builds on the ones before it. Durations follow the 6-month standard plan; the 3-month plan compresses them and the 12-month plan expands the foundations.

1. Start Here (2 weeks, beginner): Understand the role and pick a study plan.
2. Foundations (4 weeks, beginner): TypeScript, Node.js, React, databases, APIs, and DevOps.
3. LLM Fundamentals (2 weeks, beginner): Tokens, context windows, choosing models, keys and billing.
4. LLM App Engineering (5 weeks, intermediate): Streaming, structured outputs, tool use, RAG, and caching.
5. Agents & Orchestration (5 weeks, advanced): Agent loops, multi-agent systems, MCP, durable execution.
6. Production AI (2 weeks, advanced): Evals, tracing, reliability, security, and cost.
7. AI-Assisted Development (1 week, intermediate): Build, review, test, and debug with coding agents.
8. Projects (3 weeks, advanced): Six builds, ending with a production SaaS assistant.
9. Career (2 weeks, intermediate): Portfolio, writing, and AI system design interviews.

The diagram shows a production AI web application as boxes inside two trust zones: your own infrastructure, and third-party model APIs. Solid arrows are requests, dashed arrows are asynchronous jobs and telemetry, and arrows with moving dots are streamed responses.

• User: The person using your product in a browser or mobile app.
• React UI: Renders the chat or feature UI, sends requests to your API, and renders streamed tokens as they arrive. Never holds model API keys.
• API layer: The only place that talks to model providers. Validates input, checks auth and rate limits, assembles context, calls the model, and streams the answer back over Server-Sent Events.
• Auth: Identifies the user and decides what data and tools they may access. Every model call and tool call inherits these permissions.
• Redis: Fast key-value store for per-user rate limits, response caching, and short-lived session state.
• Postgres: The system of record: users, conversations, and documents. The pgvector extension stores embeddings so the same database answers similarity searches for RAG.
• Job queue: Holds slow work (document indexing, long agent runs, batch jobs) so API requests return quickly. Jobs survive restarts and can be retried.
• Workers: Node.js processes that pull jobs from the queue: chunk documents, request embeddings, write vectors to Postgres, and run long tasks with retries.
• Observability: Collects a trace for every request and job, with prompts, token counts, latency, and cost, so you can debug bad answers and run evals on real traffic.
• Model APIs: Hosted models reached over HTTPS: an LLM for generation and tool use, and an embedding model for vector search. Stateless: every request must carry its full context.

Chat request. The UI posts the message to your API, which verifies the session, checks the rate limit in Redis, retrieves context from Postgres, calls the model, and streams tokens back to the browser over SSE.

Document indexing. An upload is acknowledged immediately and queued. A worker chunks the document, requests embeddings from the model API, and writes the vectors to pgvector.

Observability. The API and workers emit a trace for every request and job, with token counts, latency, and cost. Traces feed dashboards, alerts, and evals on real traffic.

The diagram shows five parts: the user, your app (a Node.js server), the LLM behind the Messages API, your tool code, and your database. The model never executes tools itself; your app runs the loop.

1. The user asks a question. The answer depends on live data the model has never seen, so a plain model call would guess. Your app receives the message like any other request.
2. Your app calls the model with tool definitions. Alongside the conversation, you describe each tool: a name, a description the model reads to decide when to use it, and a JSON Schema for its input.
3. The model asks you to run a tool. The model cannot execute code. It stops with stop_reason "tool_use" and returns a tool_use block naming the tool and the arguments it chose.
4. Your code executes the tool. Validate the input, check that this user may see this order, then run the function. Your data never leaves your control unless you return it.
5. Send the tool result back. The API is stateless: append the assistant turn exactly as received, then a user turn containing a tool_result that references the tool_use id, and call the model again.
6. The model writes the final answer. With the result in context, the model answers and stops with stop_reason "end_turn". If it needs more data, it returns tool_use again and the loop repeats from step 3.
7. Stream the answer to the user. Show the final text in the UI. In production, cap the loop (for example at 10 iterations), log every tool call, and treat tool results as untrusted input.

Retrieval-augmented generation has two paths that meet at the vector database.

Indexing path. Runs offline whenever documents change: load each document, split it into chunks, embed every chunk, and store the vectors with their text and metadata.

Query path. Runs on every request: embed the question, retrieve the nearest chunks, rerank them, and give the best few to the LLM, which answers with citations.

• Documents: Your source of truth: help-center articles, internal docs, tickets, PDFs. Keep each document's URL and title for citations.
• Chunk: Split documents into passages of a few hundred tokens, ideally on headings or paragraphs, with a small overlap. Attach the source, title, and section to each chunk.
• Embedding model: Turns each chunk into a vector: a list of numbers where similar meanings end up close together. Use the same embedding model for indexing and querying.
• Vector DB: Stores each chunk's text, metadata, and vector, with an index (such as HNSW) for fast nearest-neighbor search.
• Question: The user's question, for example: "How do I rotate an API key?"
• Embedding model: Embeds the question with the same model used for the documents, so the question and the chunks live in the same vector space.
• Vector search: Finds the chunks whose vectors are closest to the question's vector, usually 20 to 50 candidates. Combine with keyword search for exact terms (hybrid search).
• Reranker: A model that reads the question and each candidate together and scores relevance more precisely than vector similarity. Keep only the best few chunks.
• LLM: Receives the question plus the selected chunks, with instructions to answer only from them and cite the sources it used.
• Answer: The response shown to the user, with links to the source documents so they can verify it.

The numbers on the arrows are typical starting points, not rules: retrieve around 20 candidates, then keep the best 5 after reranking. Tune both with evals.