How Cloudflare enforces engineering standards using AI  🔗 **Source:** [How Cloudflare enforces engineering standards using AI](https://blog.cloudflare.com/engineering-standards-enforcement/) > [!note]+ Document Notes > tags: [engineering-standards, ai-code-review, cloudflare, software-governance, incident-review] > author: Cloudflare > source: The Cloudflare Blog > reference: https://blog.cloudflare.com/engineering-standards-enforcement/ > date created: 2026-08-06 15:31 > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: How Cloudflare enforces engineering standards using AI > <!-- deep-read:sections start --> ## 🧭 Table of Contents - Summary - Main Content - Notes - References - Paraphrase - Newsletter - Action Items - Hypotheses - Methodology - Questions - Future Research - Implications - Learning Styles Assessment - Accessibility Assessment - DEIB Assessment - Logical Validity - DARVO Analysis - Conclusion - Refactor Appendix ### 🔗 References - https://blog.cloudflare.com/engineering-standards-enforcement/ - https://datatracker.ietf.org/doc/html/rfc2119 - https://blog.cloudflare.com/ai-code-review/ ## 📝 Summary - What happened: Cloudflare described an internal Codex: governed engineering standards consumed by AI agents across code review, spec review, and incident review. - Why it matters: the article shows a practical pattern for turning scattered institutional knowledge into enforceable, scoped, machine-readable guidance. - Stakeholders: engineers, reviewers, platform teams, security, reliability, product, compliance, trust and safety, open-source maintainers studying AI-assisted governance. - Risks and tradeoffs: automation can increase consistency, but bad standards, weak lifecycle controls, or opaque enforcement can slow teams and create false confidence. - Bottom line: AI review works best when paired with governed standards, lifecycle states, structured extraction, local tools, and human approval. ## 📖 Main Content Cloudflare’s central move is to make standards explicit before asking agents to enforce them. Guidance is organized into domains, owned by domain leads, written as RFCs, and moved through lifecycle states. Approved standards can create non-blocking findings. Enforced standards can block merges when a MUST requirement is violated. The article argues against dumping a whole standards corpus into an LLM. Cloudflare extracts SHOULD and MUST statements into JSON with stable slugs and metadata, letting agents discover the relevant rules without overloading the context window. The consumers are practical: an AI code reviewer for merge requests, a spec reviewer for design documents, and an incident report reviewer for postmortems. Cloudflare also acknowledges developer experience: AI review can take minutes, so mechanically checkable rules are moving into fast linters and a local CLI. ## 🗒️ Notes - Metrics cited: nearly a quarter million deviations flagged, about 16,000 merge blocks, close to 600 specs reviewed, more than 200 incident reports assessed. - Standards lifecycle matters: approved is advisory; enforced can block. - RFC 2119 language helps agents and humans reason about severity. - Stable statement slugs make exceptions, trends, and rule drift traceable. - The system pairs agents with linters where deterministic checks are faster. ## 📚 References - Cloudflare article: https://blog.cloudflare.com/engineering-standards-enforcement/ - RFC 2119: https://datatracker.ietf.org/doc/html/rfc2119 - Cloudflare AI code review: https://blog.cloudflare.com/ai-code-review/ ## 🗣️ Paraphrase - Cloudflare had engineering guidance scattered across docs, repos, chats, and human memory. - It turned that guidance into an owned RFC corpus called the Cloudflare Codex. - Agents consume extracted structured statements rather than every full RFC by default. - The code reviewer, spec reviewer, and incident reviewer apply the same standards at different lifecycle stages. - Cloudflare is moving some checks into linters and a CLI to reduce wait time. - Future work extends this across the software lifecycle and into product, security, compliance, and trust and safety. ## 📰 Newsletter Cloudflare’s “Codex” is the sort of AI engineering post worth saving because it doesn’t start with the model. It starts with governed standards: owners, RFCs, RFC 2119 language, lifecycle states, structured rule extraction, and clear moments where advisory findings become blocking. That’s the interesting bit for WordPress, open-source, and DevRel: AI review gets better when the organization has done the hard standards work first. ## ✅ Action Items #### DevRel - Turn standards into teachable examples, not hidden CI failures. - Offer local review commands so developers can catch issues before CI. - Publish “why this rule exists” context beside each finding. #### OSPO - Convert contribution and security policies into owned, versioned RFC-like artifacts. - Track rule lifecycle: draft, approved, enforced, deprecated. - Require exception logging and review for blocking automated standards. #### Community - Keep automated review explainable and appealable. - Invite maintainers to propose and revise standards through transparent governance. #### WordPress - Core: explore structured contributor standards for commit, testing, and review expectations. - Core Performance: define measurable performance MUST/SHOULD rules. - Core AI: study rule-grounded agents for Trac, Gutenberg, and release QA. - Core Program Team: map release standards into lifecycle states. - Mobile: apply standards to app review and release gates. - Playground: build reproducible standards-check demos. - Community: make contributor expectations explicit and humane. - Training: create lessons on RFC-style standards and AI review. - Marketing: frame AI tooling around accountability, not novelty. - Support: route repeated support failures into docs and checks. - Design: create review rubrics agents can cite. - Documentation: own and version docs standards. - Photos: apply moderation and metadata standards. - TV: review caption and metadata quality. - Polyglots: define translation quality rules with human review. - Accessibility: encode WCAG-oriented checks where deterministic checks fit. - Meta: build infrastructure for rule discovery and reporting. - CLI: prototype local standards checks. - Hosting: define hosting compatibility checks. - Tide: learn from stable rule slugs and exception tracking. - Openverse: apply standards to ingestion and trust workflows. - Themes: create clearer review rules. - Plugins: create enforceable but appealable plugin-review rules. #### The WPOCC - Fund open standards tooling that small projects can adopt without enterprise overhead. ### FAIR - Treat governance artifacts as portable infrastructure: owned, versioned, auditable, and usable by both people and agents. ## 🧪 Hypotheses - Agents grounded in structured standards produce fewer irrelevant findings than agents given whole policy corpora. - Lifecycle states reduce developer backlash against new automated checks. - Local CLI review reduces CI churn. - Stable rule slugs improve exception review and long-term quality reporting. - Linter-backed deterministic checks lower cost for common rule classes. ### 📊 Methodology - A/B test whole-corpus prompting versus extracted statement retrieval. - Track merge latency and rework before and after local CLI rollout. - Analyze blocked findings by rule, severity, domain, and false-positive rate. - Survey engineers about trust and clarity. ### ❓ Questions - How often are AI findings wrong or disputed? - Who can override an enforced MUST finding? - How are standards retired when they become stale? - What data is visible to the agents, and how is privacy handled? - How does Cloudflare avoid standards becoming bureaucracy for its own sake? ### 🔮 Future Research - Compare standards-as-RFC systems across large engineering organizations. - Study which rules should be linters, which should be agents, and which should stay human-only. - Explore open-source equivalents that work for volunteer maintainers. ### 💡 Implications - Practice: write the standard before writing the agent. - Policy: lifecycle states and owners keep enforcement accountable. - Security: agent review can catch policy drift earlier. - Education: findings become teachable moments when they cite the rule. - Funding: shared standards tooling could help open-source projects without large platform teams. ### 🧠 Learning Styles Assessment - Reading level estimate: grade 12 due to platform, AI, and standards vocabulary. #### 👀 Visual learners - Present: workflow diagram and UI imagery. - Improve: clearer architecture diagram. #### 🔊 Aural learners - Present: no audio. - Improve: narrated case study. #### 🗣️ Verbal learners - Present: strong prose and examples. - Improve: glossary for agent architecture. #### ✋ Kinesthetic learners - Present: CLI concept. - Improve: sample local workflow. #### 🧮 Logical learners - Present: lifecycle states, metrics, JSON example. - Improve: false-positive data. #### 👥 Social learners - Present: governance owners and reviewer roles. - Improve: change-management story. #### 🧍 Solitary learners - Present: detailed standalone article. - Improve: checklist. #### 🌿 Naturalistic learners - Present: lifecycle framing. - Improve: ecosystem map. ### 📊 Accessibility Assessment #### Perceivable - Text and code example are central; images are supportive. #### Operable - Long article with headings. #### Understandable - Clear but dense. #### Reliable parsing - Good semantic sections; code block is readable. #### Cognitive load - Medium-high; strong examples help. #### Low vision - Diagrams may need descriptive alternatives. #### WCAG 2.2 AA fit - Likely strong for text; image alt/detail should be checked on page. ### 🌍 DEIB Assessment #### Cultural breadth - Organization-centered, not community-centered. #### Inclusive language - Neutral and professional. #### Neurodiversity support - Good structure; could use a shorter recap. #### Representation - No named authors or broad representation details in captured content. #### Psychological safety - Advisory-versus-enforced lifecycle helps reduce surprise and blame. ### ✅ Logical Validity #### Strong reasoning - The article links scattered knowledge to drift, then proposes owned RFCs, structured extraction, and lifecycle-based enforcement. #### Fallacies - Possible survivorship/selection bias: success metrics are mostly volume counts, not precision or developer trust. Fix by publishing false-positive and appeal data. #### Tone of voice - Technical, reflective, implementation-focused. ### 🛡️ DARVO Analysis - Not applicable to this source; it is an engineering case study. ## 🎯 Conclusion Cloudflare’s pattern is useful because it frames AI review as a governance system, not a chatbot trick. The durable lesson is to make standards explicit, owned, scoped, and reviewable before automating enforcement. ## 🔄 Refactor Appendix — How Cloudflare enforces engineering standards using AI ### 📚 Literature Atoms ### AI enforcement starts with governed standards - Source: Cloudflare created owned RFC domains before broad agent enforcement. - Use: OSPO and engineering governance. ### Rule lifecycle protects adoption - Source: approved RFCs advise; enforced RFCs can block MUST violations. - Use: change management. ### Structured extraction beats whole-corpus prompting - Source: Cloudflare extracts SHOULD/MUST statements into JSON with slugs and metadata. - Use: agent architecture. ### Developer experience decides whether AI review sticks - Source: Cloudflare added linters and a local CLI to reduce CI delay. - Use: DevRel and tooling. ### 🧠 Permanent Candidates #### Standards are the substrate of trustworthy agents - A review agent can only be as accountable as the rules and governance it cites. #### Blocking automation needs an appeals-and-lifecycle model - Without draft/approved/enforced states, automated review becomes surprise bureaucracy. ### ✏️ Fleeting Queue ### → Things 1 - Compare Cloudflare Codex with Courtney’s local agent skills and AGENTS.md rules. ### → Things 2 - Draft an open-source “standards RFC to agent rule” pattern. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/How Cloudflare enforces engineering standards using AI.md|How Cloudflare enforces engineering standards using AI by Cloudflare]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01kzc98myk648npb88xtkd615m)) - Note: The headline metric and thesis: AI review depends on a shared standards source. - Tags: engineering-standards, ai-code-review, atom/literature/h1 - 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. ([View Highlight](https://read.readwise.io/read/01kzc98np8ybc853m1eyzzhpdp)) - Note: Core operating model: governed standards retrieved at the point of work. - Tags: atom/literature/h1, software-governance, agent-architecture - 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. ([View Highlight](https://read.readwise.io/read/01kzc98pgmz33m2hy6qdh1zwz2)) - Note: Lifecycle states make automated enforcement less surprising and more governable. - Tags: atom/literature/h2, standards-lifecycle, change-management - 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: ([View Highlight](https://read.readwise.io/read/01kzc991yzc0ehspsgpb1e0560)) - Note: Strong technical pattern: compact rule statements instead of sending the whole standards corpus. - Tags: structured-standards, atom/literature/h2, context-management - 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. ([View Highlight](https://read.readwise.io/read/01kzc99646f4sg409kc55d4w5q)) - Note: Useful zettel: severity language plus lifecycle state determines enforcement behavior. - Tags: atom/zettel/z1, rfc-2119, automated-review - 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. ([View Highlight](https://read.readwise.io/read/01kzc996t9tdahbz53qhh0e68g)) - Note: Developer experience split: deterministic checks in linters, optional CLI for agent review. - Tags: atom/literature/h3, developer-experience, local-tools