Platform engineering for the AI era — the shift from 1:10 to 1:1000
The old platform engineering job was to let ten product engineers ship safely. The new job is to let one product engineer, fifty AI copilots, and a thousand autonomous agents ship safely — without the cloud bill melting, without the security model collapsing, and without the error budget disappearing into probabilistic fog.
The engineering ratio is flipping
Three years ago a healthy ratio of platform engineers to product engineers was about 1:10. That was the planning assumption I used at Miro, at Flo, at every infra team I've built. The ratio worked because humans were the unit of throughput. You staffed the platform team around how many humans it had to support.
That assumption broke when LLM-assisted development crossed a threshold in 2025. One product engineer now drives a team of AI coworkers — each of which opens PRs, runs migrations, hits the API, spends tokens, and touches prod. Effective throughput has grown an order of magnitude faster than headcount. The ratio your platform team should be planning for isn't 1:10 anymore. It's 1:100 today, and — a working thesis, not a census — 1:1000 by the time this sentence feels old. The direction matters more than the digits.
If your platform team is still sized, staffed and metricked for the old ratio, you are going to be the bottleneck that prevents your company from compounding AI leverage. This is now the most important org-design question in infrastructure.
What this changes, concretely
1. Token economics replaces RPS dashboards
For fifteen years, platform teams measured the business in requests per second, p99 latency, and CPU hours. Those numbers still matter, but they are no longer the top line. The new top line is tokens in, tokens out, dollars per conversation, dollars per outcome.
Treat tokens the way you treat compute: metered, budgeted, governed. Every team gets a token budget. Every feature gets a unit-cost SLO. The FinOps practice you built to get AWS under control is now the blueprint for getting your LLM bill under control — except the variance is wider and the vendor lock-in is deeper. Start early. Ignoring this for a quarter is a $1M mistake.
2. Paved roads for the AI stack
Product teams are going to build AI features whether you help them or not. If you don't pave the road, each team will hand-roll a vector store, a prompt-ops pipeline, an eval harness, and a model router — each slightly different, each a future migration bill.
The paved road for the AI era has five rails: a vector / retrieval layer, an evals pipeline, prompt and model version control, a router that does model choice and fallback, and a shared observability layer that captures prompt/completion pairs and cost. You don't need to build them all in-house. You do need to pick one for each, wire them into the golden path, and kill the alternatives before they become a migration project in 2027.
3. Agent-safe infrastructure
The interesting security question in 2026 is not "can the attacker reach prod." It's "what is the blast radius when an agent your own team wrote executes the wrong command." Agents that can write code, touch Terraform, or hit your API are now part of the threat model.
The pattern I'm pushing at Manychat: every agent runs in a sandbox with least-privilege scoped credentials, every agent action is audit-logged with enough context to replay, and every destructive action goes through the same change-management path a human would. Shift Left stopped meaning "run Snyk in CI." It now means "bake the guardrails so deeply into the platform that an autonomous agent can't bypass them."
4. SLOs on outputs, not just uptime
A classic SRE SLO measures whether the system was up. That's a necessary measurement for an AI product and nowhere near sufficient. A retrieval service can return 200 OK and hallucinate the answer. An agent can finish its task and produce the wrong diff.
Add a parallel layer of SLOs on output quality: groundedness scores, eval pass rates, refusal rates, regression detection on prompts. Treat a drop in eval pass rate exactly the same way you treat a drop in availability — page someone, freeze deploys, investigate. Observability has to capture prompts and completions alongside traces and metrics. If your current o11y vendor can't do this, start the replacement conversation now.
5. Unit-cost dashboards the CFO can read
The FinOps practice I built at Miro saved eight figures by making cloud cost legible to every engineer on every team. The same discipline, applied to AI, is the difference between a company that scales AI profitably and one that explains a quarterly miss to the board.
Cost per conversation. Cost per active user. Cost per resolved ticket. Cost per generated document. These are the numbers your CFO is going to ask about when the AI line on the P&L starts compounding. Build the dashboard before they ask.
The meta-point
Every infrastructure shift of the last fifteen years — virtualization, cloud, containers, Kubernetes, service mesh — was a shift in how the substrate worked. The AI shift is different. It's a shift in who the users of the substrate are. The substrate is now being consumed by code that writes code.
Platform teams that internalise this will compound. Platform teams that treat AI as a feature the product team is building will spend 2027 apologising to their CFO. You get to pick which kind you are.
I write about infrastructure, FinOps and AI platforms from Amsterdam. If you're working on the same problems — or hiring — find me. We're hiring infra engineers at Manychat; open roles here.