ai-platform/roadmap
All pages

Start here

  1. How to use this roadmap
  2. Two kinds of role
  3. Read code, write it rarely
  4. Target profile
  5. Eight principles
  6. Work on a real product

Phases

  1. 01Direct coding agents and read their code
  2. 02Learn how models behave and what they cost
  3. 03Build retrieval that finds the right evidence
  4. 04Build tool servers with MCP
  5. 05Design agent workflows that survive failure
  6. 06Run agent workloads on AWS
  7. 07Trace every step an agent takes
  8. 08Build evals that catch regressions
  9. 09Run agents reliably in production
  10. 10Secure agents and the code they write
  11. 11Build an internal AI platform
  12. 12Get teams to adopt the platform
  13. 13Build Forge, the capstone platform
  14. Elective: Kubernetes

After the phases

  1. Staff skills
  2. 12-month plan
  3. A typical week
  4. Show your work
  5. Tools to know
  6. What to skip
  7. Final checklist

Start here

Do the work on a real product

Most learning roadmaps have you build demo projects that nobody uses. Hiring managers for both kinds of role see through that. Product postings ask whether you have "shipped a product that other people use". Staff postings ask whether you have "actually operated non-deterministic LLM workloads in production". A real product answers both questions.

Pick one AI product with real users and do the work of Phases 2 to 10 on it: model cost, retrieval, tracing, evaluations, reliability, and security. Traces of real requests, the real cost of each task, retrieval failures on real content, and a regression suite built from real complaints all prove more than the same artifacts built on sample data. The improvements also help the product.

Find a product to work on

This list goes from the strongest evidence to the weakest:

  1. A product you already own or run.
  2. Your employer's product, if you have permission to work on its AI features and to talk about the results.
  3. An open-source project with active users.
  4. A small product you ship yourself in the first two months. Good options are AI search and answers for a community or business website, an assistant for a local organisation, or a tool you would use yourself.

A product that answers questions over a set of documents is a good choice, because it touches almost every phase. The rest of the roadmap calls it "your product".

Split the work between your product and Forge

Alongside your product, you build a second project that this roadmap calls Forge. Forge is an internal platform for engineers who build software with coding agents. It gives them shared tools: a model gateway, a search engine over code and docs, MCP servers, a PR-review agent, tracing, and budgets. You can give your platform any name.

You start Forge in Phase 1 as your personal agent setup, add a part to it in most phases, and finish it as the capstone in Phase 13. The two projects prove different things. Your product proves that you can run AI for real users. Forge proves that you can build a platform other engineers use, which is what Staff platform roles look for.

The table shows which work goes into which project.

PhaseOn your productOn Forge
2. Model costCost and latency for each task, model routing, and prompt caching.One model gateway for all agents.
3. RetrievalRetrieval evals from real queries, freshness, and re-indexing.A context engine over repositories and docs.
4. Tool serversAn MCP server that gives agents access to the product's main feature.An MCP server with engineering tools.
7. TracingTraces and cost dashboards in production.A dashboard for agent operations.
8. EvaluationsAn answer-quality benchmark that every prompt or model change must pass.A benchmark for pull request (PR) reviews.
9 and 10. Reliability and securityA plan for provider outages, and prompt-injection tests that use content the product ingests.Budgets, sandboxes, and approvals.

Use Forge yourself every day, on your product and your other work, so that Forge also has a real user. If a team you work with agrees, try parts of Forge with them, such as a shared agent setup, a PR-review agent, or an MCP server. That is the closest practice you can get for the Staff role's requirement to drive adoption through pairing instead of mandates.