Cloudflare Enforces Engineering Standards Across SDLC Using Codex and AI Agents

Cloudflare Enforces Engineering Standards Across SDLC Using Codex and AI Agents Cloudflare introduced the Cloudflare Codex, a governed repository of engineering RFCs that AI agents use to evaluate code, technical specifications, and incident reports directly within developer workflows. The Cloudflare Codex organizes technical standards into domain-specific RFCs using RFC 2119 SHOULD and MUST keywords, progressing from approved to enforced status. To prevent LLM context-window exhaustion, an automated agent extracts requirements into structured JSON with stable slug identifiers for progressive disclosure. An AI code reviewer flagged roughly 230,000 standard violations and blocked nearly 16,000 merge requests based on enforced MUST requirements. Specialized agents running on Cloudflare Workers and D1 have evaluated nearly 600 design specifications and over 200 incident reports. Codex Architecture and Governance Before the Codex, Cloudflare's technical standards were scattered across documentation, repositories, and chat channels, causing cross-team drift. The Codex centralizes this knowledge under domain owners who oversee specific topics like security, reliability, and programming languages. Standards are authored as RFC proposals with front matter metadata and RFC 2119 keywords. While approved RFCs allow agents to issue advisory recommendations, requirements become merge-blocking only after advancing to an enforced lifecycle state. LLM Optimization and Context Management Because feeding more than 60 full RFCs to a large language model strains context limits, Cloudflare deployed an extraction agent that condenses SHOULD and MUST statements into structured JSON. Each statement receives a stable slug identifier to ensure continuity across system updates, exception management, and tracking. The schema incorporates lazy discovery and progressive disclosure, serving full RFC bodies only when an agent requires broader context. Active Review Agents and Workflows Codex powers three specialized review agents across the development lifecycle. The AI code reviewer evaluates merge requests, blocking integrations when enforced MUST requirements are violated. The spec reviewer runs on Cloudflare Workers, D1, and AI Gateway to audit architecture documents prior to implementation, having completed over 3,200 runs across nearly 600 unique specs. The incident report reviewer audits postmortems for complete timelines, root causes, and action items, serving as a mandatory gate for high-severity incidents. Future Expansions Cloudflare plans to reduce feedback latency by pairing its AI code reviewer with targeted linters and a CLI tool. The company also intends to enable agents to autonomously propose fixes for review and expand Codex governance beyond engineering to teams in product, security, compliance, and trust and safety.

Cloudflare推出Codex规范库与AI代理体系，自动化执行工程与设计标准 为解决工程规范分散和执行不一致的问题，Cloudflare构建了统一的工程标准库Cloudflare Codex，并通过AI代码审查、设计规格审查及事故复盘审查代理，在多个开发环节实现规范的自动化检查与执行。 Codex采用RFC格式并依托SHOULD与MUST关键字定义规范，利用专用代理将其压缩为带固定标识符的结构化JSON，以解决大语言模型上下文限制问题。 AI代码审查代理在4个月内标记了近23万次工程规范偏离，并依据生效标准中的强制（MUST）条款阻断了约1.6万次代码合并。 设计规格审查代理与事故报告审查代理依托Cloudflare Worker、D1和AI Gateway等内部平台构建，已分别评估近600份技术设计规格与200多份事故报告。 Codex标准库的治理与结构化提取 在引入Codex之前，Cloudflare的工程规范散落在文档、代码库、即时通讯记录及员工个人经验中，导致检索耗时且不同项目间逐渐出现规范偏离。为解决此问题，Codex按前端、控制面、安全性、可靠性及特定编程语言等领域进行划分并指派负责人。标准以RFC形式提案并评审，采用RFC 2119的SHOULD和MUST关键词。规范包含approved（已批准，仅告警不阻断）与enforced（已生效，强制阻断）两个生命周期阶段。为避免60多个RFC超出模型上下文窗口，系统通过专用代理将条款提取为紧凑且带有固定slug标识符的JSON结构，以便于追踪和精准过滤。 三大场景下的AI代理审查实践 Codex目前已驱动三类AI审查代理。在代码审查方面，AI审查器根据条款等级决定处理方式，已标记近23万次违规并阻断约1.6万次合并。在技术设计层面，基于Worker、D1和AI Gateway构建的规格审查代理会在实施前扫描设计文档，自2026年5月初以来已完成对近600份规格的3200多次审查，其中绝大多数问题为严重（65%）或轻微（29%）级别。在运维复盘方面，事故报告审查代理已评估200余份报告，核查时间线、成因与后续改进动作，并已成为高严重性事故复盘的强制准入环节。 扩展至软件全生命周期与跨部门领域 Cloudflare计划将Codex模型贯穿至整个软件开发生命周期（SDLC），并在未来逐步让代理在工程人员审核批准的前提下自主提出修复方案。此外，Codex的覆盖范围正从工程技术向产品、安全、合规以及信任与安全等其他业务团队延伸，使AI代理能够在更广泛的业务视角下评估工作成果。

Over the past four months, our [AI code reviewer](https://blog.cloudflare.com/ai-code-review/) has flagged nearly a quarter of a million deviations from Cloudflare engineering standards (what we’ll call “violations” in this post) and blocked 16,000 merges. Our spec reviewer agent has evaluated close to 600 technical designs against the same standards before implementation began. Both systems draw from the Cloudflare Codex, a shared source of engineering guidance built for people and agents. This post explains why we built the Codex, how it supports the engineering lifecycle, and what we plan to do next. Before the Codex (which we briefly introduced in [a previous post](https://blog.cloudflare.com/internal-ai-engineering-stack/) about our AI engineering stack), developer guidance at Cloudflare lived in many places: formal documentation, repository files, chat threads, and the accumulated knowledge of individual engineers. Engineers often spent too much time searching for guidance instead of working on the problem they were trying to solve. Even after finding an answer, they could not always tell whether it was current, authoritative, or applicable to their situation. As Cloudflare grew, that model became increasingly difficult to sustain. No engineer could read every standard, and reviewers could not reliably check every requirement. Institutional knowledge became harder to recover when people moved between teams, and guidance that was not consistently surfaced or enforced led to drift between projects. We rebuilt this body of knowledge as the Cloudflare Codex: a governed set of engineering standards that agents can retrieve and apply at the point of work. The same guidance can now inform code review, technical design review, incident report review, and many other use cases, while engineers focus their time and judgment on the resulting findings. A dedicated Codex governance model divides the Codex into distinct domains covering the engineering areas we care about. These include architectural matters (for example, frontend and control plane), cross-cutting concerns (security and reliability), specific languages (TypeScript and Rust), and several other areas. Each domain is led by an owner who is responsible for the content, consistency, and overall quality of the documents they oversee. Codex standards use a Request for Comments (RFC) format. Requirements use the SHOULD and MUST keywords defined by [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). We also expect a front matter header to hold metadata such as the domain and RFC status. Any Cloudflare employee with a key interest and domain competency can propose an RFC through a merge request that follows the prescribed structure. The proposal then passes through several rounds of feedback from an increasingly broad group of reviewers. Once the domain owner gives final approval, the RFC becomes part of the Codex and is published to an [Astro](https://astro.build/)-powered internal site. Approved RFCs can be consumed by Codex clients and agents, which may then start to flag Codex violations in code, configuration, or documentation immediately. However, they block based on Codex statements only after an RFC moves from the *approved* to the *enforced* lifecycle state. This separate promotion step gives teams time to absorb new requirements and accommodates cases where enforcement needs additional work. The following diagram illustrates the steps in the Codex workflow: A naive process could stop here and feed the entire Codex to a large language model (LLM) as is. Given the increasing number of RFCs we have already (60+ and counting), however, the corpus volume would put a lot of stress on the context window and impact LLM results negatively. To help guide models to the most relevant RFCs, we invoke a purpose-built agent to automatically extract and compact the SHOULD and MUST statements into a dedicated JSON structure and enrich it with metadata that supports lazy discovery and progressive disclosure. The following abridged excerpt shows the result for our control plane services RFC: Each statement receives a stable slug identifier that remains unchanged during the extraction process even when its RFC is updated. The identifier lets us track the same statement across different systems over time, which is essential for monitoring, analysis, and exception handling. Initially, we extracted the statements into another, more concise Markdown file rather than JSON. Over time, we moved to a richer structured format so that agents could filter the content they needed more accurately. We plan to include additional metadata for even tighter scoping, such as indicators for the software development life cycle (SDLC) stage a statement applies to (e.g., design, implementation, runtime). Several systems already use the Codex in day-to-day engineering work. Three agents show how the Codex works in practice: our AI code reviewer, spec reviewer, and incident report reviewer. Our AI code reviewer agent, covered in [a separate blog post](https://blog.cloudflare.com/ai-code-review/), evaluates merge requests across several dimensions, including Codex compliance. For each review, the agent retrieves the RFCs and parses the Codex statements. It loads full RFC bodies only when the model or coordinator needs additional context. In most cases, the statements provide enough information to explain a reported violation. The distinction between SHOULD and MUST, together with an RFC’s status, determines how the reviewer responds. Findings from approved RFCs are non-blocking recommendations. Once an RFC is enforced, an unsatisfied MUST requirement causes the reviewer to withhold approval or block a merge request, depending on the severity. Since the Codex’s inception earlier this year, the AI code reviewer has flagged close to 230,000 violations. Among these, almost 16,000 caused approval to be withheld (i.e., they referred to MUST statements on enforced RFCs). A single AI code reviewer run usually takes a couple of minutes to complete due to the coordinator framework and sub-agent execution. Although the wait is very often worth the money (or tokens), engineers were calling out the delay and extra round trip involved in remediating the findings. We looked into how we could improve the experience and came up with two additional options: We believe the linters would be useful to almost every developer and codebase, while the CLI remains an optional alternative for engineers who prefer it. Engineers at Cloudflare regularly write design documents and technical specifications (or *specs* in short) before implementation. A significant subset of the Codex pertains to design, architecture, and other themes relevant to technical reviews. To catch architectural mistakes before implementation begins, we built the *spec reviewer*, an agent that discovers specs and evaluates them against relevant Codex requirements. The spec reviewer operates on the Developer Platform: it runs as a Cloudflare Worker, stores its results and state in D1, routes model requests through AI Gateway, and kicks off scanning for new specs via a Cron Trigger. It starts by filtering the Codex by domains and sections relevant to specs (for example, language features and implementation-focused RFCs are disregarded). Several guiding prompts instruct the model on how to run the assessment and frame the results. The findings get rated based on severity (influenced by SHOULD and MUST keywords) and include general quality and architectural advice. On completion of a review run, a note is left on the spec document linking to a custom dashboard where review details can be inspected. Since the beginning of May 2026, almost 600 unique open specs have been reviewed. Including reruns triggered on demand or by spec changes, we tracked over 3,200 review invocations to this date. The vast majority of findings had a “major” (65%) or “minor” (29%) severity, with “critical” findings being the minority (6%). The following image gives an impression of what the spec reviewer UI looks like: We plan to integrate the spec reviewer more tightly by posting comments directly on the spec documents, embedding human-agent conversations that can influence the review assessment, and flagging high-impact proposals for additional human review. The *incident report reviewer* applies the same approach to incident reports (also known as postmortems). In addition to checking that each report is complete, it evaluates whether the report clearly explains what happened, identifies contributing factors, documents the resolution, and proposes meaningful follow-up actions. These expectations are defined in a dedicated Codex RFC. The incident report reviewer uses the same Developer Platform building blocks as the spec reviewer. This shared architecture is becoming a common pattern for our Codex agents. Since May 2026, the reviewer has assessed more than 200 incident reports and identified gaps such as missing follow-up action items, incomplete timelines, and omitted detection signals. Among those reports, 93% covered incidents that were low-impact, internal-only, or declared preemptively. For high-severity incidents, we’ve made the reviewer mandatory as part of our comprehensive central review process, and reports are not considered complete until all findings have been addressed. The Codex already supports agents that review code, technical designs, and incident reports. We plan to extend that model throughout the SDLC, allowing agents to surface issues consistently across design, implementation, and operations. The longer-term goal is for agents to identify issues as well as propose fixes with increasing autonomy, while engineers remain responsible for reviewing and approving those changes. We are also expanding the Codex beyond engineering. Product, security, compliance, and trust and safety teams are beginning to add their own standards, allowing agents to evaluate work against considerations that extend beyond design and implementation alone. Across a number of engineering workflows, Codex-backed agents have helped us surface issues sooner and apply standards more consistently. We have found AI most useful when it brings the right guidance to engineers at the point of work, and plan to keep extending the approach across Cloudflare. *If you’re interested in building systems like these, our [engineering teams are hiring](https://www.cloudflare.com/careers).*