Learning Paths
Ordered routes through this site by role, so you read the pages that answer your questions in the order that makes each one land
Three curricula with their own pages, plus a fourth reading order for individual developers set out below
How These Work
A site with this many pages is a reference, and a reference read front to back teaches you very little. These paths are routes through pages that already exist. Nothing here is new material; every entry is a link to a page you could have found on your own, arranged so that each one arrives after the thing it depends on.
Each path is broken into stages, and each entry says why the page belongs at that point rather than earlier or later. Stages are the useful stopping points: you can finish one, apply it, and come back. What a path will not do is promise you an outcome. It tells you what you will be able to do at the end of each stage, and you can judge whether that is worth the reading.
Read across paths freely. A platform engineer who never opens the egress control material has a gap, and a security lead who has not read how a workspace is provisioned will write policy that cannot be implemented. The role split is about where you start, not where you stop.
A few pages appear in more than one path, and where they do it is deliberate rather than an oversight. The same page is read for a different reason depending on who is holding it: a platform engineer reads the capacity material to size a cluster, while a manager reads it to understand what drives the invoice. Where a path repeats a page it says why it is being revisited at that point.
One thing these paths will not do is tell you the answer. They order the reading; the decisions stay yours, and several of the pages here exist specifically to make a decision harder rather than easier. The productivity material on the engineering manager path is the clearest example - it comes first precisely because it is the material most likely to change what you propose, and reading it after the proposal is written is how it gets ignored.
The Four Paths
| Path | Starts From | Ends With You Able To | Format |
|---|---|---|---|
| Platform Engineer | The inner loop and why environments drift | Design, provision, observe, and recover a workspace platform | Full path |
| Security and Compliance Lead | Zero trust and identity | Write enforceable policy for humans and agents, and evidence it | Full path |
| Engineering Manager | What the productivity claims actually say | Build a defensible business case, run a pilot, and staff the result | Full path |
| IC Developer | Getting a workspace and being productive in it | Work daily in a remote environment, including alongside agents | Reading order below |
Platform Engineer
Six stages from the inner loop through devcontainers, architecture, provisioning, Kubernetes, observability, capacity, and disaster recovery. The path for whoever will own the control plane at three in the morning.
Security and Compliance Lead
Zero trust, identity for humans and for agents, secrets, egress, prompt injection, supply chain, and then the regulatory layer including the EU AI Act and the Cyber Resilience Act.
Engineering Manager
The uncomfortable cost and productivity material first, then build versus buy, vendor selection, the pilot, and the organizational work that decides whether any of it sticks.
IC Developer: a Reading Order, Not a Path Page
The developer route is short enough that a separate page would add navigation without adding content, so it lives here. It has one goal: get you working in a remote environment without needing to understand the platform underneath it. Read these in order.
Get oriented
- Getting Started - the shortest honest description of what changes for you.
- Core Concept - what a cloud development environment actually is, before the tooling.
- How It Works - enough of the mechanism that the failure modes stop being mysterious.
- Glossary - keep it open; the vocabulary is dense and inconsistent across vendors.
Set up your environment
- DevContainers - the file that defines your workspace, field by field.
- Quickstarts - a working configuration for your stack, once you know what the fields mean.
- IDE Integration - connecting the editor you already use, rather than learning a new one.
- Template Library - the artifacts to copy once you know which one you need.
Work daily
- Inner Loop - where the latency you will feel actually comes from.
- Git Worktrees - working several branches at once without a workspace each.
- Agent Experience - what changes when an agent shares the environment with you.
- Troubleshooting - read once now, so you recognize the symptom later.
Work with agents
- AI Coding Assistants - the landscape, before you commit to one workflow.
- AGENTS.md - how to tell an agent the things it cannot infer from your repository.
- Context Engineering - why the same prompt gets different results in different repositories.
- AI Code Review Bottleneck - the queue that forms downstream when generation gets cheap.
Shared Ground, Whichever Path You Take
Four pages appear in more than one path because the conversation stalls without them. If you only have an afternoon, read these.
Core Concept
Shared vocabulary. Most disagreements about CDEs turn out to be two definitions in a trench coat.
Readiness Assessment
Forty statements that surface where your organization actually is, before anyone picks a tool.
Template Library
The artifacts every path eventually points at, collected with their caveats attached.
Sources
Every figure quoted on this site, with its publisher, its date, and a link to the original.