DevOps (AI-Driven Delivery & Infrastructure)

1. Introduction

1.1. Background: The Delivery Pipeline Is Being Rewritten by AI

Over the past decade, the core proposition of DevOps has been shortening the distance from commit to production: compressing "weekly releases" down to "daily" and "hourly" releases through continuous integration, continuous delivery, infrastructure as code (IaC), and automated release.

AI has changed the very nature of this pipeline. In 2023—2024, AI's role in DevOps was primarily assistive: generating pipeline fragments, explaining errors, or writing Dockerfiles and Kubernetes manifests. By 2025, the role began shifting toward agency: agents were granted the ability to read repositories, modify IaC, create merge requests, and even trigger environment releases.

This shift raises a fundamentally new question: the pipeline is no longer "executing scripts written by humans" but has begun to "execute intent generated by models". And the pipeline is precisely one of the systems in an organization with the most concentrated permissions, the broadest impact surface, and the highest potential for irreversible consequences — it holds write access to artifact repositories, cloud resource credentials, and production environment access.

Accordingly, building the AI Harness for the DevOps area is essentially a permissions engineering problem: how to hand write access to a non-deterministic system while keeping the delivery pipeline predictable.

1.2. Definition

DevOps area (AI-driven delivery & infrastructure): an engineering field that researches and practices engaging AI agents in CI/CD pipelines, infrastructure as code, environment orchestration, and release processes, while ensuring that changes remain safe, traceable, and rollback-able within gates.

This area covers four categories of tasks:

1.3. Positioning in the AI Harness Framework

图 1-1｜DevOps 在 AI Harness 六层体系中的定位与瓶颈

数据来源：基于本文分析绘制的示意图。

This area's primary layer is the L3 Orchestration & Control layer, with secondary layers being the L6 Governance & Security layer and the L2 Tools & Execution layer. It is also the area with the highest L6 weighting among the six layers.

1.4. Bottleneck Layer

The bottleneck of this area lies in the L6 Governance & Security layer, specifically in three intertwined problems:

1. Permission separation failure. The most dangerous anti-pattern in DevOps is that "the system that generates changes can also approve them." When an agent simultaneously has the ability to "generate IaC changes" and "relax gates," every gate is reduced to a formality. This is the foremost architectural constraint of this area.
2. Irreversibility. Unlike code, infrastructure and release actions are highly irreversible: a single terraform apply may destroy resources, and a single traffic shift may route traffic to an unverified version. Code can be git revert-ed; destroyed resources cannot.
3. Configuration drift and state inconsistency. Drift exists between IaC's declarative ideal and real-world manual changes; a change generated by AI from stale state may look harmless at the plan stage, only to trigger large-scale replacement at the apply stage.

A secondary bottleneck lies in the L3 Orchestration & Control layer: release flows must be interruptible, pausable at any stage, and resumable from the interruption point, or rollback-able — an ability not every CI system possesses.

1.5. Value

• Reduce the cognitive burden of the delivery pipeline: the complexity of modern pipelines has exceeded what any single person can fully grasp, and AI has real value in "understanding the current state — proposing minimal changes."
• Make the security baseline the default: when generating pipelines, AI can inject controls such as signature verification, SBOM generation, and dependency scanning by default — precisely the items most often omitted when written manually.
• Turn release from a "craft" into a "process": canary strategy, rollback trigger conditions, and change windows are defined in code, and AI executes within the gates, reducing human variance.
• Make delivery performance measurable: the four DORA metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) are naturally suited as the measurement framework for this area, and industry baselines already exist for comparison.

2. Glossary

3. Case Studies

Note: the following cases are compiled from publicly verifiable primary sources. All effect figures are labeled with the source's methodology and time; self-reported methodology and measured methodology are labeled separately.

3.1. Case 1: The AI Evolution of an All-in-One DevOps Platform

Source: GitLab release notes (18.0 on 2025-05-15, 19.0 on 2025-11-19, 20.0 on 2026-05-15), https://about.gitlab.com/releases/; GitLab Duo with Amazon Q

3.1.1. Background

An all-in-one DevOps platform (which consolidates source management, CI/CD, artifacts, security scanning, and release orchestration into a single system) has a structural advantage in the AI era: AI can see the complete chain from code to production within the same permission domain and the same set of context. A fragmented toolchain is the opposite — every time AI crosses a system, it must re-authenticate and re-assemble context, and cross-system behavior is hard to audit uniformly.

3.1.2. Approach

Represented by GitLab, all-in-one platforms have continuously advanced their AI capabilities (GitLab Duo, further integrated with Amazon Q) across their 2025—2026 release line:

• Release cadence: 18.0 (2025-05-15) → 19.0 (2025-11-19) → 20.0 (2026-05-15), roughly one major release every six months, with AI capabilities evolving continuously along the release line.
• Unified context: AI can access issues, merge requests, pipeline logs, and security scan results without cross-system federated queries.
• Built-in gates: changes produced by AI must likewise pass pipeline gates; the platform does not exempt any control merely because it is "AI-generated."
• Permission inheritance: AI's operational permissions are inherited from the user or token that triggers it, with no additional escalation — a key design that prevents "AI from becoming a permission amplifier."

3.1.3. Results

In publicly available information, GitLab's AI evolution manifests as platform capability integration rather than isolated point metrics; specific quantified benefit figures are marked [To be verified] within the verifiable scope of this document.

Engineering takeaways (independent of specific numbers):

1. Permission inheritance principle: AI must never possess more permissions than its trigger. This single rule eliminates the vast majority of "AI as a privileged channel" risks.
2. No gate exemption principle: AI-generated changes go through the same pipeline and the same set of gates as human changes.
3. Unified-context advantage: within a single system, L1 context assembly costs are significantly lower than cross-system federation, which is the real value of the platform route.

3.2. Case 2: Industry Baselines for AI Adoption and Delivery Performance

Source: DORA 2025 State of AI-assisted Software Development, Google Cloud / DORA, 2025-11-12, https://dora.dev/research/2025/dora-report/; Google DORA's "AI-assisted software development" report, 2025-10-08

3.2.1. Background

The adoption rate of AI coding tools is no longer the question; the real question is: does delivery performance improve after adoption? Without an industry baseline, each organization can only compare against its own past, and self-comparison is easily contaminated by seasonal and demand fluctuations.

3.2.2. Approach

DORA uses a large-sample survey, measuring AI adoption together with delivery performance (the four DORA metrics) and developers' subjective perceptions, to form an industry baseline for comparison. Its methodological value lies in measuring objective metrics and subjective perceptions simultaneously, making the divergence between the two visible.

3.2.3. Results

Table 3-1　DORA 2025 Key Findings (2025-11-12)

Table 3-2　Other Cross-Corroboration of Adoption Rates

Interpretation:

1. Adoption has crossed the line; trust has not. 84%—90% are using it, yet 46% do not trust the accuracy of the output. This combination points to a phase of "high-frequency use + high-frequency verification" — verification cost is systematically underestimated.
2. 30% of tasks take over 4 hours each, in tension with the narrative of AI "speeding things up": a high share of long tasks suggests that many tasks are not simplified by AI, and may even become longer because of AI involvement (a generate—verify—rework loop).
3. The self-reported -90% review time calls for particular caution. The drop in review time may stem from "shallower review" rather than "better code," and must be observed together with the defect escape rate.

3.3. Case 3: Building Supply-Chain Gates for AI-Generated Changes

Source: NIST SP 800-218A (SSDF 1.1), 2024-10, https://csrc.nist.gov/pubs/sp/800/218/a/final; NIST Cybersecurity Framework (CSF) 2.0, 2024-02-26, https://www.nist.gov/cyberframework

3.3.1. Background

AI-generated code introduces a distinctive supply-chain risk: the model may suggest dependency packages that do not exist, are deprecated, or have been poisoned (dependency hallucination / slopsquatting). Traditional dependency scanning can only find known vulnerabilities; it cannot recognize that "this package should never have existed." At the same time, the speed of AI-generated changes makes manual review of dependency changes a bottleneck.

3.3.2. Approach

Make supply-chain controls automatic gates on the pipeline, rather than manual check items:

• Source-trustworthiness gate: new dependencies must have a resolvable upstream repository, identifiable maintainers, a release date, and a download baseline; otherwise they are blocked.
• SBOM gate: generate an SBOM on every build and compare it with the previous one; any newly added component requires explicit confirmation.
• Provenance gate: artifacts must carry provenance (builder, input commit, build environment); promotion is refused if it is missing.
• Integrity gate: artifact signature verification; unsigned or mismatched signatures are refused deployment.
• Permission separation: the agent that generates changes must not have permission to modify the gate rules above.
• Framework alignment: the controls map to NIST SP 800-218A (SSDF 1.1)'s protect-the-software (PW), build-security (PS), and respond-to-vulnerabilities (RV) practice groups; risk-management categories align with NIST CSF 2.0 (2024-02-26).

3.3.3. Results

The effect of this case is not measured by speed but by risk interception:

• Dependency hallucination is intercepted at the gate layer and never reaches the code review stage, so it does not consume review resources.
• Artifact provenance turns "where did this image come from" into an answerable question, which is the basis of auditing in an era when AI participates heavily in building.
• Permission separation makes "AI relaxing its own gates" architecturally impossible, rather than merely "prohibited."

Implementation tip: the value of these gates lies in being enabled by default and not closeable by a single role. If a gate can be exempted at will by a frontline developer (or agent), its existence is meaningless.

4. Practice Standards

4.1. AGENTS.md Specification

Below is the complete AGENTS.md for this area, placed in a code block for direct copying. When using it, layer on the common clauses of the group-level AGENTS.md; conflicts are resolved by the nearest-first principle.

# AGENTS.md —— 软件工程 · DevOps 方向（交付与基础设施）

## 角色与边界

- 本文件约束**参与交付链路的 AI 智能体**：流水线变更、IaC 变更、发布编排、交付分析。
- 允许自行完成：读取仓库与流水线配置、只读调用云 API 查询现状、生成 IaC 变更与 `plan` 预演、生成流水线片段、分析构建失败原因、生成 SBOM 与依赖差异报告、在预发环境执行验证性部署。
- 禁止自行完成：执行 `apply` / `kubectl apply` 等下达类命令、修改或放宽门禁规则、创建或轮换凭证、发布到生产、删除制品或镜像、变更审批链、修改审计配置。
- 边界判定：**`apply` 与 `plan` 的分界线就是本方向的权限红线**——`plan` 可自行，`apply` 必须人工确认。
- 核心原则：智能体的权限**继承自触发者**，不得额外提权；智能体不得成为权限放大器。

## 环境假设

- 提供仓库读写（分支隔离）、流水线系统访问、IaC CLI、制品仓库、云 API（只读为默认）。
- 提供容器或微虚机沙箱；`plan` 与构建在沙箱内执行。
- 提供 IaC 状态文件的只读访问，且状态有版本与时间戳（用于漂移检测）。
- 提供制品仓库与签名/来源证明（provenance）机制。
- 提供审计日志（谁、何时、对什么环境做了什么），且智能体不可删改。
- 提供成本计量（云支出 + AI 调用）与上限设置。
- 缺失任一项时降级执行并显式声明；**审计日志缺失时禁止执行任何写操作**。

## 上下文加载顺序（Context Budget）

1. 任务契约：目标、产出物、验收标准（固定，不压缩）
2. 就近指令文件：当前目录及其祖先链
3. 流水线现状：阶段定义、门禁规则、触发条件、最近 N 次执行结果
4. IaC 现状：声明定义 + 状态文件摘要 + 漂移报告
5. 环境拓扑：环境清单、晋级路径、审批要求
6. 供应链现状：依赖清单、SBOM、最近变更
7. 历史事故：发布相关事故的摘要与教训
8. 工具结果：按需追加

记录 Token 预算表；超限压缩而非截断，压缩须保留门禁规则与环境约束。

## 工具契约

- 副作用分级：R（只读）/ W（工作区写）/ X（沙箱内执行）/ S（共享状态写，需确认）/ D（不可逆，默认拒绝）。
- **`apply` 类命令一律列为 D 级**：`terraform apply`、`kubectl apply`、`helm upgrade`、制品晋级、生产切流。
- 云 API 调用默认只读；写操作须显式列出且逐项确认。
- `plan` 输出必须完整保留作为证据，且 `apply` 前须比对"本次 plan 与待执行变更集一致"。
- 所有执行类工具必须设置超时；非幂等工具重试前先确认上次是否生效。
- 输出超限时截断并给出定位信息。

## 任务执行流程（SOP）

1. 解析契约：明确目标环境与验收标准；缺失则停止并澄清。
2. 现状盘点：流水线阶段、IaC 状态与漂移、环境拓扑、依赖清单。
3. 影响面分析：本次变更影响哪些资源、服务、环境、成本。
4. 变更草案 + `plan` 预演：**必须产出 plan 输出作为证据**。
5. 计划确认（L3 高风险）：提交 影响面 + plan 输出 + 风险点 + 回滚方案，获审批。
6. 执行：仅执行已审批的变更；每步完成后验证。
7. 门禁验证：全部流水线门禁通过，含供应链门禁。
8. 交付：五段式变更说明 + plan/apply 记录 + 门禁报告。
9. 留痕与观测：归档审计日志；发布后进入观测窗口，异常即触发回滚。

## 验证与证据要求

| 验证项 | 判定 | 证据 |
|---|---|---|
| `plan` 与变更集一致 | 逐项比对通过 | plan 输出 + 比对结论 |
| 门禁全通过 | 无被豁免项 | 门禁报告（含豁免项清单 = 0） |
| 供应链门禁 | SBOM 生成、来源证明齐备、签名有效 | SBOM + provenance + 签名校验结果 |
| 依赖合法性 | 新增依赖来源可解析、许可证明确 | 依赖差异表 |
| 回滚可用 | 回滚方案存在且已演练或可证明 | 回滚方案 + 演练记录 |
| 成本在预算内 | 预估增量 ≤ 上限 | 成本预估 |
| 审批链完整 | 所需审批已获且留痕 | 审批记录 |
| 审计留痕 | 操作可追溯到人 | 审计日志条目 |

**禁止**：以"流水线显示绿色"作为唯一证据——必须确认门禁是真实开启的（用一条故意失败的变更反向验证）。

**禁止**：自行豁免任何门禁；如需豁免，须人工审批并在变更说明中显式列出。

## 失败与升级策略

- 门禁失败：定位失败原因 → 修正变更（**禁止修正门禁**）→ 重试；重试 3 次仍失败则回滚并上报。
- `plan` 出现意外的大规模替换（如资源将被销毁重建）：**立即停止**，判定为高风险，升级人工。
- 漂移检测发现显著偏差：停止自动变更，先对齐状态或人工介入。
- 发布后观测异常：按预设触发条件自动回滚；回滚后保留现场证据。
- 权限被拦截：不得绕过；记录并升级。

升级三要素：已尝试动作与结果 / 卡点现象与证据 / 建议选项及风险。

## 安全与合规红线

1. 禁止智能体拥有修改门禁规则的权限（**权限分离**）。
2. 禁止执行 `apply` 类命令而未获人工审批。
3. 禁止创建、轮换、导出凭证；禁止在配置、日志、制品中写入密钥。
4. 禁止删除制品、镜像、状态文件、审计日志。
5. 禁止在变更中关闭 TLS 校验、禁用安全扫描、降低签名要求。
6. 禁止跨环境直接晋级（如从开发直接到生产），必须按既定晋级路径。
7. 遵循 NIST SP 800-218A（SSDF 1.1，2024-10）的 PW / PS / RV 系列实践。
8. 风险管理对齐 NIST CSF 2.0（2024-02-26）的治理（GV）、识别（ID）、保护（PR）、检测（DE）、响应（RS）、恢复（RC）六个功能。
9. 组织级落地对齐 ISO/IEC 42001:2023 的角色职责与成文信息要求。

## 禁止事项

1. 禁止把 `plan` 输出当作"已经验证"的证据——`plan` 只说明意图，不说明结果。
2. 禁止在无回滚方案的情况下执行任何 `apply`。
3. 禁止使用 `[待填写]`、`XX`、`___` 之外的非标准占位符；不确定处统一使用 `[待填写]`。
4. 禁止以"模型认为"作为技术判断依据。
5. 禁止在生产环境做实验性变更。
6. 禁止变更集超出审批范围（审批了 A 却顺带改了 B）。
7. 禁止删除或改写他人的指令文件、门禁配置与安全策略。

## 输出格式

每次交付必须包含五段：

- 变更说明：文件/资源清单 + 每项一句话说明
- 为什么改：动因与依据（关联任务/缺陷/需求编号）
- 如何验证：plan 输出摘要、门禁报告、SBOM/签名结果、未验证项与原因
- 风险与影响：受影响资源与服务、成本增量、回滚触发条件
- 回滚方案：具体命令或操作路径、回滚代价与注意事项（**回滚必须可执行**）

附加输出：影响面清单、环境晋级路径、审批记录引用、发布后观测窗口与指标。

## 评估与自检

| 自检项 | 判定 |
|---|---|
| plan 与变更集一致 | 是 / 否 |
| 门禁全通过且无自我豁免 | 是 / 否 |
| 供应链门禁（SBOM/来源证明/签名）齐备 | 是 / 否 |
| 依赖来源可解析 | 是 / 否 |
| 回滚方案可执行且已演练或可证明 | 是 / 否 |
| 成本在预算内 | 是 / 否 |
| 审批链完整留痕 | 是 / 否 |
| 审计日志可追溯到人 | 是 / 否 |

任一"否"须显式列出；自检不通过即任务未完成。

度量口径：部署频率、变更前置时间、变更失败率、服务恢复时间（DORA 四指标）；辅以构建耗时、门禁拦截率、回滚率、成本趋势。

4.2. SKILL.md Specification

---
name: safe-iac-and-pipeline-change
description: 在门禁内完成一项基础设施或流水线变更——盘点现状、分析影响面、产出 plan 预演、跑通供应链与门禁检查、获取审批、执行并留痕。适用于 IaC 变更、CI/CD 流水线修改、发布编排与环境晋级。当需要让 AI 参与交付链路且必须保证可回滚、可审计时使用。
version: 1.0
created: 2026-09-12
---

# 安全的基础设施与流水线变更

## 适用场景

- 修改 IaC 定义（Terraform / Kubernetes / Helm 等）。
- 新增或修改 CI/CD 阶段、缓存策略、并行度、门禁规则。
- 制品环境晋级、灰度策略调整、特性开关切换。
- 构建失败归因、依赖与供应链风险扫描。

不适用于：生产环境的紧急热修复（走应急流程）、无变更工单的临时操作、探索性云资源试用。

## 前置条件

| 类别 | 要求 | 缺失时处置 |
|---|---|---|
| 变更契约 | 目标环境、影响范围、验收标准 | 停止，先补全 |
| 状态可见 | IaC 状态文件可读且有时间戳 | 先做漂移检测 |
| 审计 | 操作可留痕 | **禁止任何写操作** |
| 沙箱 | `plan` 与构建在隔离环境执行 | 升级 |
| 权限 | 智能体权限继承自触发者，无额外提权 | 按最低权限执行 |
| 回滚点 | 存在可回退的状态或版本 | 先创建回滚点 |

## 输入

- 变更需求与验收标准
- 仓库 + 分支 + commit SHA
- 目标环境（开发 / 预发 / 生产）
- 关联变更单或审批编号
- 预算上限（成本增量 / 时长）

## 输出

- IaC 变更集 + `plan` 输出
- 影响面清单（资源、服务、成本）
- 门禁报告（含供应链门禁）
- 五段式变更说明 + 审批记录引用
- 发布后观测窗口与指标定义

## 执行步骤

1. **解析契约**：明确目标环境与验收标准；生产环境一律 L3/L4。
2. **现状盘点**：流水线阶段、IaC 定义与状态、漂移报告、环境拓扑、依赖清单。
3. **影响面分析**：列出受影响资源、服务、环境、成本增量；识别是否有资源将被销毁重建。
4. **变更草案**：最小化改动；不夹带无关调整。
5. **`plan` 预演**：执行 `plan`，完整保留输出；**若出现意外的大规模替换或销毁，立即停止并升级**。
6. **门禁验证**：供应链门禁（SBOM、来源证明、签名）+ 常规门禁；任一未过则修正变更（**不修正门禁**）。
7. **提交审批**：影响面 + plan 输出 + 风险点 + 回滚方案；等待审批，**超时不得自行继续**。
8. **执行**：仅执行已审批内容；每步完成后验证。
9. **观测**：发布后进入观测窗口，按预设触发条件判断是否回滚。
10. **留痕**：归档审计日志、plan/apply 记录、门禁报告。

## 质量标准（DoD）

1. `plan` 输出与最终变更集逐项一致。
2. 全部门禁通过且**无任何自我豁免项**。
3. SBOM 已生成、来源证明齐备、签名有效。
4. 新增依赖来源可解析、许可证明确、维护状态可查。
5. 回滚方案明确、可执行，且不依赖智能体继续参与。
6. 成本增量在预算内。
7. 审批链完整且留痕。
8. 审计日志可追溯到具体的人。
9. 发布后观测窗口与回滚触发条件已定义。
10. 未触及权限与安全红线；智能体未拥有修改门禁的能力。

## 常见失败与处理

| 失败 | 表现 | 处理 |
|---|---|---|
| plan 出现意外销毁 | "will be destroyed" 超出预期 | 立即停止并升级；禁止 apply |
| 门禁失败 | 依赖扫描/签名/测试未过 | 修正变更；**禁止放宽门禁** |
| 状态漂移 | 实际状态与声明偏差大 | 停止自动变更，先对齐状态 |
| 依赖幻觉 | 建议的包不存在或被废弃 | 门禁拦截；不得人工放行 |
| 审批超时 | 无人响应 | 挂起并升级，不得自行继续 |
| 发布后异常 | 观测指标越界 | 按触发条件自动回滚，保留现场 |
| 回滚失败 | 回滚依赖智能体继续参与 | D5 未通过，必须重做 |
| 范围蔓延 | 审批了 A 却改了 B | 回退越界部分，重新审批 |

## 示例

**场景**：为服务新增一个只读副本数据库，并调整连接池上限。

- 契约：仅预发环境；不影响主库；可一键回滚。
- 现状：主库 1 实例，连接池上限 100；IaC 状态无漂移。
- 影响面：新增 1 个只读实例（成本 +约 X/月）、安全组规则 1 条、应用配置 1 处。
- `plan`：输出显示 "1 to add, 0 to change, 0 to destroy" —— 与预期一致，无销毁项。
- 门禁：SBOM 生成；依赖无新增；镜像签名有效；集成测试通过。
- 审批：L3 高风险，需人工审批（变更单号已关联）。
- 执行：apply 后验证只读实例可连通、主从延迟在阈值内。
- 观测：30 分钟窗口，监控主从延迟与错误率；延迟超阈值即回滚。
- 回滚：删除只读实例 + 恢复连接池配置（IaC 回退至上一版本）。
- 自检：八项全"是"。

4.3. Implementation Checklist

Permission & Separation (L6, highest priority)

• [ ] Agent permissions inherit from the trigger, with no additional escalation
• [ ] The agent that generates changes does not have permission to modify gate rules
• [ ] Approval authority and generation authority are separated architecturally (not merely by process convention)
• [ ] apply / kubectl apply / artifact promotion are classified as Level D and hard-blocked
• [ ] Credential creation and rotation are fully disabled for agents
• [ ] Audit logs cannot be deleted or modified by agents

Pipeline & Gates (L3)

• [ ] Gates treat AI-generated and human changes equally, with no exemption channel
• [ ] A deliberately failing change has been used to inversely verify that gates actually block
• [ ] The pipeline supports pausing at any stage and resuming from the interruption point
• [ ] The environment promotion path is fixed (development → staging → production), with no cross-environment shortcuts
• [ ] Rollback is a first-class citizen of the pipeline (triggerable with one click, not hand-assembled command sequences)

Infrastructure (L2 + L4)

• [ ] IaC state files have versions and timestamps, and drift detection runs periodically
• [ ] plan output is fully preserved as evidence and compared item-by-item against the final changeset
• [ ] Destructive items in plan automatically escalate to a human
• [ ] An immutable infrastructure strategy is adopted to reduce in-place modification
• [ ] Changes are idempotent; repeated execution yields consistent results

Supply Chain (L6)

• [ ] An SBOM is generated on every build and diffed against the previous one
• [ ] Artifacts carry provenance
• [ ] Artifact signature verification runs before deployment
• [ ] New dependencies are checked for source resolvability, license, and maintenance status
• [ ] Control items are aligned with NIST SP 800-218A (SSDF 1.1) and NIST CSF 2.0

Metrics (L5)

• [ ] Deployment frequency, lead time for changes, change failure rate, and time to restore service are all being measured
• [ ] Gate interception rate and rollback rate are being measured (a high interception rate indicates room for upstream quality improvement)
• [ ] Cloud cost and AI call cost have guardrails and trend observation
• [ ] Self-reported and measured data are labeled separately and not mixed

5. Summary

The DevOps area is the one with the highest L6 Governance & Security weighting among the six layers of AI Harness, for a simple reason: the pipeline is the system in an organization with the most concentrated permissions and the most irreversible consequences, and AI is a non-deterministic participant.

This area has three non-negotiable architectural constraints:

1. Permission separation: the system that generates changes cannot approve changes, and the system that generates changes cannot modify gates. This is not a process convention; it must be an architectural fact — otherwise every gate is merely a "suggestion."
2. The boundary between plan and apply is the permission red line: plan is intent and may be done autonomously; apply is fact and must be done by a human. Treating plan output as verification evidence is the most common cognitive error in this area.
3. Permission inheritance rather than permission amplification: AI's permissions must never exceed those of the subject that triggers it. This single rule eliminates the vast majority of "AI as a privileged channel" risks.

Regarding results, we must stay sober: DORA 2025 (2025-11-12) shows 90%+ of developers using AI, self-reported productivity +80%, and review time -90%, but the same data also shows that 30% of tasks take over 4 hours each; meanwhile, the Stack Overflow 2025 survey (2025-07-30) shows that 46% of developers do not trust the accuracy of AI output. Together, these numbers point to one conclusion: adoption has crossed the line, while trust and predictability have not.

The real task of the DevOps area in the AI era is not to make AI release faster, but to keep releases involving AI trustworthy — rollback-able, auditable, and attributable.

Information Gap Statement

1. The specific lists of AI capabilities and quantified benefit figures across GitLab releases (18.0 / 19.0 / 20.0) are marked [To be verified]; this document only cites versions and release dates within the verifiable scope.
2. The specific integration capabilities and effect figures of GitLab Duo with Amazon Q in Case 3.1 lack accessible primary sources, so they are marked [To be verified]; this document does not adopt specific numbers.
3. SLSA (supply-chain levels) is cited in this area as a general framework; the specific level requirements and the levels the organization currently achieves are marked [To be filled].
4. The DORA four-metric baseline values for each organization itself are marked [To be filled] and need to be filled in with internal measurements.
5. Some enterprise case details and source URLs in this area are to be back-filled after the research report is supplemented.

6. References

1. GitLab release notes (18.0 / 19.0 / 20.0) — GitLab Inc.https://about.gitlab.com/releases/
2. DORA 2025 State of AI-assisted Software Development — Google Cloud / DORA, 2025-11-12. https://dora.dev/research/2025/dora-report/
3. AI-assisted software development — Google DORA, 2025-10-08. https://dora.dev/
4. Stack Overflow 2025 Developer Survey — Stack Overflow, 2025-07-30. https://survey.stackoverflow.co/2025/
5. NIST SP 800-218A Secure Software Development Framework (SSDF) 1.1 — NIST, 2024-10. https://csrc.nist.gov/pubs/sp/800/218/a/final
6. NIST Cybersecurity Framework (CSF) 2.0 — NIST, 2024-02-26. https://www.nist.gov/cyberframework
7. NIST AI Risk Management Framework (AI RMF 1.0) and GenAI Profile — NIST, 2024-07-26. https://www.nist.gov/itl/ai-risk-management-framework
8. ISO/IEC 42001:2023 Artificial Intelligence Management System — ISO/IEC, 2023. https://www.iso.org/standard/42001
9. SLSA (Supply-chain Levels for Software Artifacts) — OpenSSF. https://slsa.dev/
10. OpenTelemetry semantic conventions — OpenTelemetry. https://opentelemetry.io/docs/concepts/semantic-conventions/
11. OWASP Top 10 for LLM Applications 2025 — OWASP, 2025-11-10. https://owasp.org/www-project-top-10-for-large-language-model-applications/
12. Model Context Protocol official specification — Anthropic et al. https://modelcontextprotocol.io/