--- title: "Cloud 2.0 for Engineering teams" excerpt: "Engineering teams have been first to feel the Cloud 1.0 to Cloud 2.0 shift because they sit closest to the AI stack. Most engineering orgs are still running Cloud 1.0 workflows on top of Cloud 2.0 substrates: PR review by chat, runbooks in Confluence, incidents in Slack threads. Here is the engineering-org-specific version of the five Cloud 2.0 shifts, with what a typical eng day looks like once the workflows catch up to the substrate." author: mei category: Thinking date: "2026-05-28" --- Engineering teams have been the first vertical to feel [the Cloud 1.0 to Cloud 2.0 shift](/blog/cloud-2-0), because they sit closest to the AI stack. The 2024 DORA report found that [more than 75% of developers now rely on AI for at least one daily responsibility](https://dora.dev/research/2024/dora-report/), and GitHub's research program clocked [developers completing tasks 55% faster with Copilot in hand](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/). The substrate already changed under eng teams two years ago. The workflows didn't. Most engineering orgs are still running Cloud 1.0 workflows on top of Cloud 2.0 substrates. PR review by chat. Runbooks in Confluence. Incidents in Slack threads. The agents got smart; the surfaces didn't move. This is the engineering version of [the five Cloud 2.0 shifts](/blog/five-shifts-cloud-1-to-cloud-2), and what a normal day looks like once the workflows catch up. ## The five shifts, mapped to eng **Humans → humans + agents.** The team isn't just the people on the org chart. It's the people plus the CI bots, the PR review agents, the runbook agents, the incident triage agents. Platform teams used to ship services. Now they ship services AND the agents that operate alongside them. **Apps → workspaces.** The Linear-GitHub-Slack triple was the eng surface for a decade. One ticket in Linear, the diff in GitHub, the conversation in Slack, the postmortem in Confluence, and the agent has to read all four to know what happened. Cloud 2.0 collapses that into one shared object per project or incident, with humans and agents [writing to the same surface](/blog/mcp-first-workspace). **Login → identity.** Service accounts were the Cloud 1.0 approximation of "a non-human did this." They worked because the non-humans were dumb and few. The instant agents start opening PRs and editing runbooks, you need [signed identities with an owner cascade](/blog/agent-identity), not a shared `ci-bot` token in a `.env` file. The on-call rotation extends to the agents the on-call runs. **Integration → MCP.** REST APIs and webhooks don't go away. They keep doing what they always did: wiring system A to system B. But the canonical agent-tool interface is MCP. The platform team's job description shifts. It used to be "own the REST gateway." It becomes "own the MCP server." Same shape of work, different surface, and the new surface is the one your agents actually use. **Per-token → flat.** The eng AI budget under Cloud 1.0 economics is unpredictable by design: per-call, per-completion, per-task. A platform lead can't tell finance what next quarter costs, because it depends on how chatty the agents get. Flat-subscription substrates flip that. [The substrate is a fixed line item](/blog/why-we-kept-flat-pricing); LLM tokens stay variable on the model side; the platform team can budget. ## What a normal eng day looks like **Standup is artifact-first.** Nobody reads the Slack thread. They open the workspace. The PRs in flight, the incidents from overnight, the agent runs that ran while everyone slept, all in one surface. The meeting becomes "what does the artifact say, and what do we want to change?" rather than "what did everyone do yesterday?" **PR review is overnight.** A review agent leaves the first pass on every open diff before anyone is awake. Style nits, obvious bugs, missing tests, the boring stuff. The humans show up in the morning and handle the judgment calls: is this the right abstraction, does it match the roadmap, is the migration safe. The review agent didn't replace the human. It cleared the boring 40% so the human handles the top 60%. **Incidents write themselves.** The postmortem isn't reconstructed from Slack scrollback two days after the fact. It's the document the on-call human AND the incident agent both wrote to during the incident: the agent dropping in log excerpts, graphs, hypotheses, ruled-out causes; the human steering, approving, overruling. By the time the incident is resolved, the postmortem is mostly written, by both actors, with attribution intact on every line. **Runbooks are live.** Not Confluence pages that decay six months after the last edit. Live documents the agents [read on join](/blog/backmerges-or-bust), which means the runbook stays accurate because the agent that depends on it will break if it doesn't. The runbook and the runtime stop drifting, because they share a reader. ## Why Dock specifically The point of this piece isn't that Dock is the only place to do Cloud 2.0 engineering. The point is that the four pieces above (shared workspace, signed agents, MCP-canonical, flat-priced) only compound when they ship together. A workspace without signed agents has no attribution. Signed agents without an MCP server have no canonical surface to act on. An MCP server billed per-call is a budget you can't defend. Flat pricing on a single-user tool is just a discount. Dock is built so all four arrive at once. The shared workspace is the surface, agents are first-class identities with an owner cascade, MCP is the tool layer, and the bill is the same every month no matter how loud the agents get. That's the [Cloud 2.0](/cloud-2-0) substrate the workflows above are built on, and the reason an engineering org can stop pretending Slack is a postmortem and Confluence is a runbook. [What that looks like in practice](/blog/cloud-2-0-at-dock) is one workspace, many actors, attribution intact. The shift already happened. The question is how fast the day reorganizes around it.