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

After the phases

The 12-month plan

The phases overlap, so use this table as a schedule, not a strict order. Keep one codebase and one product throughout, so that later phases improve earlier work instead of starting over.

MonthFocusWhat you have at the end
1Working with coding agentsAn agent setup with skills, hooks, and MCP servers. Several agents in parallel with worktrees and a multiplexer. A raw agent service.
2Code literacy and model basicsThe failure-injection write-up, practical tests, a reviewer agent with a measured catch rate, a published agent setup, and cost tracking.
3Model cost and retrievalA model router and a gateway decision record. Cost per task for your product. A retrieval eval set from real queries. You can now apply for AI-native product roles.
4Retrieval and MCPVector, hybrid, and tool-based search compared. MCP servers for engineering tools and for your product.
5Agent workflows and durable executionA PR reviewer on Temporal. A coding agent running in CI.
6AWS basicsInfrastructure as code, queues, a durable worker, and reviewed IAM policies.
7AWS and tracingBedrock integration, OpenTelemetry traces, and an operations dashboard that includes coding-agent usage.
8EvaluationsBenchmarks for your product and for PR reviews, with CI gates.
9Reliability and securitySLOs, budgets, replay, and a game day. A threat model, a sandbox comparison, an injection test suite, and the supply-chain case study.
10Platform and developer experienceThe first slice of Forge, an SDK and CLI, a shared agent setup, and a one-command local environment.
11Adoption and capstoneAn adoption effort through pairing, a second agent, an onboarding test, and runbooks.
12Staff documents and portfolioRFCs, decision records, a cost report, case studies, and system-design practice. You can now apply for senior and Staff platform roles.

Split each week like this

This split adds up to about 9 hours:

  • 2.5 hours directing agents to build the main system, often several at once.
  • 2 hours of study on the problem you are currently building.
  • 1.5 hours of checking: reading diffs, running evals, inspecting traces, and finding planted bugs.
  • 1 hour breaking something on purpose, such as injecting failures or probing cost and security.
  • 1 hour writing a decision record, notes, a runbook, or a case study.
  • 1 hour improving your agent setup, such as a new skill, a hook, or a context fix, and reviewing the week.

Review the whole system every quarter

At the end of months 3, 6, 9, and 12, stop adding features for one session and review the whole system. Ask four questions. Is the architecture getting easier or harder to change? Is spend predictable? Is diagnosing failures getting faster? Does the eval set reflect the failures you have actually seen? Check that the tools page is still current. Delete or simplify any abstraction that is not worth its complexity.

Adjust the pace

If a phase takes longer than planned, move on only when its exit milestone is real. Do not make up time by skipping tracing, evals, or security, because those are what separate platform engineering from prototypes. If you are ahead, go deeper on the same system with more users, stricter SLOs, another team, or a second agent. Do not start unrelated demos. If you get an AI-native job early, map the remaining phases onto that job's systems. That is better evidence than anything you build on the side.

Publish a progress note every three months

Write one page with five things: what you built, what failed, one architecture decision you changed your mind about, the most important before and after metric, and the next risk. These notes make strong interview material, because they show your judgement improving over time.