Cloudflare's internal AI engineering stack
This is a strong read on how a large engineering org actually uses AI coding tools, standards, review, and platform primitives together.
Giving engineers AI coding tools without wiring those tools into the rest of the engineering system — standards, CI, review, observability — just produces plausible code that’s wrong for the repo.
Source
The AI engineering stack we built internally — on the platform we ship
By: Cloudflare
Published: Apr 20 2026
Type: Engineering article
This article matters because it shows AI engineering as an organisational system, not a model choice. Cloudflare reports 93% of its R&D organisation uses AI coding tools — 3,683 active users, 47.95 million AI requests, 241 billion tokens through AI Gateway in a single month. That level of internal adoption is harder evidence than any benchmark.
How Cloudflare wired AI into the full engineering system
The stack has three layers: platform, knowledge, and enforcement. Each layer maps to shipping Cloudflare products — the same ones customers use — which means the team feels every rough edge directly.
The platform layer starts with one command: opencode auth login. That triggers a discovery endpoint served by a Worker, which configures providers, models, MCP servers, agents, commands, and permissions without touching a config file. Cloudflare Access handles authentication via the same SSO engineers use for everything else. Every LLM request routes through AI Gateway, giving centralised provider key management, cost tracking, and zero data retention controls. No API keys exist on user machines — the proxy Worker injects them server-side.
A design decision that paid off was routing all requests through a single proxy Worker from day one, rather than having clients connect directly to AI Gateway. That choke point made it possible to add per-user attribution, model catalogue management, and permission enforcement later without touching any client configs.
Workers AI handles roughly 9% of internal inference. Their security agent alone processes over 7 billion tokens per day on Kimi K2.5 — an estimated 77% cheaper than a mid-tier proprietary model. Frontier models (OpenAI, Anthropic, Google) handle the other 91%, mainly for complex agentic coding work.
The MCP Server Portal aggregates 13 production MCP servers exposing 182+ tools across Backstage, GitLab, Jira, Sentry, Elasticsearch, Prometheus, and more — one endpoint, one OAuth flow. A practical problem emerged quickly: every tool definition consumes context window tokens. Their GitLab MCP server originally had 34 tools consuming ~15,000 tokens of context per request — 7.5% of a 200K window gone before asking a question. Code Mode solves this at the portal layer by collapsing all upstream tools into two portal-level tools (portal_codemode_search and portal_codemode_execute), so the overhead stays constant as more servers are added.
The knowledge layer has two parts. Backstage (the open-source service catalogue from Spotify) tracks 2,055 services, 228 APIs, 544 systems, 1,302 databases, 375 teams, and over 16,000 entities with dependency graphs. The Backstage MCP server gives agents structured context about ownership, dependencies, and system relationships — without this, agents can read the code in front of them but can’t see the system around it.
AGENTS.md files solve the repo-level knowledge gap. Early in the rollout, agents kept producing changes that looked plausible but violated local conventions — wrong test commands, ignored boundaries, unknown directory layouts. Each AGENTS.md is a short, structured file that tells agents the runtime, test command, directory layout, conventions, boundaries, and dependencies. Cloudflare generated these across roughly 3,900 repositories using a pipeline that pulls metadata from Backstage, analyses repo structure, maps the stack to Engineering Codex standards, then opens a merge request for human review.
The enforcement layer ties it all together. Every merge request gets an AI code review automatically. A multi-agent review coordinator classifies the MR by risk tier (trivial, lite, or full) and delegates to specialised review agents for code quality, security, codex compliance, documentation, performance, and release impact. Each agent reads the repository’s AGENTS.md, pulls Engineering Codex rules from a central repo, and posts structured MR comments with severity levels and specific codex rule citations. The reviewer maintains context across iterations — if something was flagged and then fixed, it acknowledges that rather than re-raising it.
The Engineering Codex is the standards system underneath the reviewer. A multi-stage AI distillation process outputs codex rules (“If you need X, use Y”) and an agent skill with progressive disclosure across hierarchical markdown files. Engineers can query it locally (“how should I handle errors in my Rust service?”) and the review CI cites specific rules in feedback.
The impact on velocity: the 4-week rolling average of merge requests climbed from ~5,600/week to over 8,700, with one week hitting 10,952 — nearly double the Q4 baseline.
My take
What makes this useful isn’t any single piece — service catalogues, review bots, and standards documents are all common. It’s the wiring between them. When an agent can pull context from Backstage, read AGENTS.md for the specific repo, and then get reviewed against Codex rules by the same toolchain, the first draft is close enough to ship. Without that wiring, you get fast code generation that creates review work for humans. The proxy-Worker-from-day-one decision is the kind of architectural choice that looks obvious in retrospect but requires discipline to make early, before you know you’ll need per-user attribution and model catalogue management. Teams building their own AI engineering stacks should start with the routing layer, not the model choice.
Where this is useful
- When building an internal AI coding stack for more than a handful of engineers — the single proxy Worker pattern, centralised AI Gateway, and auto-discovery endpoint are the critical infrastructure decisions.
- When agents produce code that “looks right but is wrong for the repo” — AGENTS.md files with explicit conventions, boundaries, and dependencies solve this directly.
- When AI-generated code volume overwhelms human review capacity — a multi-agent reviewer with risk tiering and codex rule citations scales review without scaling headcount.
Apply this: If your agents don’t have an AGENTS.md telling them the test command, directory layout, and repo boundaries, that’s your first fix — it costs nothing and immediately reduces wrong-convention suggestions.
What I want to remember
Remember: AI coding tools become serious when they’re wired into the real engineering system: standards, CI, traces, repositories, review, and production feedback. The model is only one part. The wiring is the product.