Skip to content
知识库

AI 编码质量体系 — 六层判定结构与落地路径

AI 编码质量体系 — 六层判定结构与落地路径

调研类型：跨项目深度调研（原始产出为 mavis deep research 多轮报告） 资料口径：29 条公开资料，含 arXiv 论文、官方报告、官方文档与开源仓库 采集时间：2026-10-24 一句话结论：质量保证的瓶颈已从”写得快不快”转向”审得过来审不过、信任校准准不准、合并之后会不会变坏”，而解法不是更强的模型，是把质量判定拆成层次清晰的执行链——确定性闸门先行，AI 审 AI 居中，风险最高的一小撮交回给人。

摘要：三句话读懂

  1. 生成不再稀缺，验证成为新的排队口。 AI 让一次生成的批量变大，变大后的改动更难审，也更容易引发系统不稳定【1】【15】。
  2. 体系不是”多加一道人工检查”，而是分层判定。 每一层都要回答同样三个问题：判定由谁执行、依据能否被机器复现、失效时谁被叫醒。
  3. 留在体系里的只有三件事：写契约、设阈值、裁决例外。 人工省下来的不是注意力，而是判定成本。

一、瓶颈的转移与数据口径

1.1 交付侧：吞吐下降与稳定性下降

Google DORA 2026 年 4 月的生成式 AI 报告给出一个反直觉的关联：AI 采用度每提高 25%，交付吞吐下降 1.5%，交付稳定性下降 7.2%【15】。

报告的解释是，AI 让开发者一次生成的批量变大，变大后的改动更难审，也更容易引发系统不稳定。同时，“变更失败率持平”并不等于安全——绝对失败数仍在上升。

组织侧的数据指向同一处：

  • Meta 内部人类落地 diff 的有效代码行同比增长 105.9%
  • 人均 diff 量增长 51%
  • 其中 agentic AI 贡献超过 80% 的增量
  • 同时，获得及时审查的 diff 占比在下降【1】

结论：生成侧不再稀缺，验证侧成为新的排队口。

1.2 “AI 到底提不提速”：证据是冲突的，需要原样保留

METR 2025 年对照实验：熟悉自己代码库的资深开源开发者使用 AI 后，完成任务反而慢 19%，置信区间 +2% 到 +39%【16】。

2026 年 2 月，METR 宣布改变第二期实验设计，理由是数据本身不可用：

  • 大量开发者拒绝在没有 AI 的条件下工作
  • 30% 到 50% 的开发者干脆不提交某些任务
  • 样本因此系统性偏向乐观

原始结果：

人群效应量置信区间
原参与者-18%-38% 到 +9%
新参与者-4%-15% 到 +9%

方向上倾向”现在更快”，但被作者本人判定为证据很弱【16】。

2026 年 5 月，METR 针对 349 名技术工作者的调查得到自报价值变化中位 1.4 到 2 倍，同时提示对这一量级应当谨慎【16】。

1.3 口径校准：“AI 写了多少代码”不是质量指标

“AI 写了多少代码”没有统一定义，差别通常来自是否计入人工批准。Google CEO 的公开表述被广泛转引为两个版本：

  • 2024 年三季度财报会：超过四分之一的新代码由 AI 生成，然后由工程师审查并接受
  • 2026 年 4 月 Cloud Next：75% 的新代码由 AI 生成并经工程师批准，比去年秋天的 50% 提高【29】

后一个数字的定义本身就把人工批准计入了分子。

同类说法的成色：

  • Anthropic 内部接近 100% 的说法，同样出自二手转引【29】
  • 常被引用的 Amazon”约 90%“，未找到可靠一手来源

这类数字能说明规模，不能当作质量指标——因为规模正是质量体系要处理的对象，而不是它的成绩。

1.4 证据边界（须显式声明）

  • Devin、Factory、OpenHands 的内部质量机制未取到一手材料
  • DORA 的 AI 能力模型七项枚举与投资回报测算示例来自二手转述，未逐字核对原报告
  • 相关出处均已在正文标注

二、质量体系的六层判定结构

每一层都要回答同样的三个问题：判定由谁执行、依据能否被机器复现、失效时谁被叫醒。 对齐这三点，体系才不会退化成”多写点规则、多加一道人工检查”。

下表把热门项目的做法抽象为六层结构，逐层给出判定执行者、可机器复现的依据与典型失效信号。

层次判定执行者可机器复现的依据典型失效信号
意图层人写契约，AI 起草带验收标准的规格与可断言的引用规格与实现漂移，验收标准不可执行
规约层人定规则，AI 加载仓库内的规则文件与钩子配置规则被绕过，规则与工具链脱节
验证层机器测试、类型检查、lint、依赖与 SAST、构建断言缺失，或测试与实现同源
审查层AI 审 AI语义审查加确定性复核噪声高于信号，人工复核成本反升
信任层人设阈值，机器执行回滚率、事故率、审查解决率自动放行比例越过安全边界
边界层人授权沙箱、审批策略、权限最小化agent 被不可信内容诱导

这张表暴露的约束

  • 前四层的判定可以高度自动化，人的注意力集中在第五层的阈值设定与第六层的授权边界，以及验证层判不出结果时的兜底。

此外还有三条贯穿全表的原则：

  1. 能用断言判的事情不交给模型。
  2. 判定按风险分层，而不是全量放行。
  3. 每一层都留一个可观测信号，否则阈值无从校准。

三、各层机制与证据

3.1 意图层的规格契约

规格驱动开发在 2026 年已经从”先写需求文档”变成”把规格、计划、任务做成 agent 执行的契约”。

一篇以概念分析为主的论文给出了更清晰的位置：规格是人与 agent 之间的契约基底；体系上区分 agent 周边的技术 harness 与团队周遭的方法论 harness，并归纳出五种人机交互模式。其结论是，规格驱动重建了 vibe coding 溶解掉的三样东西——问责性、可验证性与可迁移性【6】。

对六个主流规格驱动框架的比较指向同一批风险：

  • 规格与代码漂移
  • 过度信任生成物
  • 社区扩展脆弱
  • 平台绑定
  • 缺少流程级基准【7】

最有说服力的证据：规格质量 ↔ 缺陷率的直接关联

EPIC 框架按 ISO/IEC/IEEE 29148 给 114 个开源规格驱动仓库的规格打分，提炼出 10 个质量维度与 40 条实践。结果：

规格质量分组bug 修复占提交的比例
前三分之一11.8%
后三分之一20.4%

【3】

Google 团队把同一思路用到测试生成上：让 agent 先显式写出代码的前置条件、后置条件与未定义行为，再据此生成测试。在 Google 的生产 bug 集合上：

  • 缺陷检出率提升 9.8 个百分点
  • 分支覆盖提升 2.5 个百分点
  • LLM-as-Judge 判定其测试优于基线 77.8%、优于人工编写测试 56.7%【4】

代价同样清楚

  • 规格里写实现细节能帮 agent，却让规格更容易腐化。从业者访谈与 266 个仓库的语料分析发现，规格与代码的校验多半发生在完成时，而不是持续进行【5】。
  • 逐行引用需求编号能把自动幻觉检出率从 0% 提升到 86.4% 和 88.0%，代价是输出确定性下降【14】。
  • 连措辞都会改变 agent 行为：有团队坚持在指令里写 must 而不是 should，因为 agent 可能把 should 当作可选【3】。

落地形态已经相当成熟

Amazon Kiro【20】

  • requirements.md、design.md、tasks.md 三件套推进
  • Requirements-First 与 Design-First 两种流程并行
  • 另有一个不设审批门的 Quick Spec 用于已知场景
  • 专门的 Analyze Requirements 环节挑出规格里的不一致、歧义与缺口
  • Markdown Review 让审阅者逐行批注后一次性回传给 agent

GitHub Spec Kit【21】

  • 流程是宪法、规格、计划、任务、实现、收敛六步
  • 实现与收敛要循环到系统报告收敛为止
  • bug 修复流程给出 verified / partial / failed 终判
  • 构想评估流程给出 go / needs-clarification / kill 决策
  • preset 机制用来强制组织标准或监管要求

GSD【26】

  • 把每阶段交给一个全新 sub-agent 并清空会话上下文
  • 让 agent 从文件而不是从对话历史里恢复信息
  • 产物树：PROJECT、REQUIREMENTS、ROADMAP、STATE，加上每阶段的 PLAN、SUMMARY、VERIFICATION、UAT

库内已有条目：[[开源项目分析/AI编码工程化/spec-kit-GitHub官方规范驱动开发|spec-kit]] 即第【21】项。

3.2 规约层的规则与上下文

harness 不是提示词。 harness 指把规约、上下文装配、工具调用、终止条件组织在一起的工程装置，模型只是其中一个部件。

  • Meta-Harness 证明这套装置本身可以被自动优化：搜索出来的 harness 在 agentic coding 任务上超过了人工手写的基线【13】。
  • SWE-bench 官方榜单为了公平比较，加了一个只保留同一执行环境的开关，注释写得很直白：目的是让分数比较模型而不是 harness【27】。

两件事指向同一个判断：同样的模型在不同装置下能差出很多，而装置恰恰是人可以改的部分。

规约载体：从文档变成可执行配置

工具规约载体特点
Claude Code【18】CLAUDE.md + .claude/rules/*.md有专门事件在规则被载入上下文时触发
Cursor【28】常规规则文件 + BUGBOT.mdBUGBOT.md 单独承载团队不变量（如改动特定目录时测试覆盖必须达某阈值）
Codex CLI【19】AGENTS.md + 沙箱与审批策略规约与执行边界绑定

开源侧热度（按 2026 年 10 月 24 日的星数）

项目星数
obra/superpowers【22】约 30.4 万
spec-kit【21】约 14.3 万
agent-skills【23】约 11 万
OpenSpec【24】约 7.3 万
BMAD-METHOD【25】约 5.5 万
gsd-core【26】约 1.1 万

这个热度本身说明一件事：工程团队缺的不是又一个 agent，而是一套能被复用的工程纪律。

库内已有条目：[[开源项目分析/AI编码工程化/Superpowers-AI编码工程师方法论与Skills框架|Superpowers]] 即第【22】项。

上下文管理：规约层最容易被忽略的一环

Spec Growth Engine 指出 agentic 编码有两个结构性失效模式：

  1. 上下文爆炸——agent 必须一次推理整个仓库，输出质量随上下文窗口填满而下降
  2. 无声的规格与代码漂移——直到代价高昂时才被发现【8】

GSD 用每阶段更换新上下文对抗第一种，用漂移闸门对抗第二种。

3.3 验证层的确定性闸门

确定性检查是 agent 的眼睛。

Cursor 官方把”可验证目标”归纳为三类：测试捕捉行为回归，类型检查捕捉结构错误，lint 捕捉风格与模式违规。它给出的最强安全网不是任何单一工具，而是测试、类型检查、lint、Bugbot 与人工审查的叠加——理由是分层验证捕捉不同类型的问题【28】。

Claude Code 的钩子机制把同一思路做成了可执行程序：

  • PreToolUse 事件能在工具调用前拦截并返回拒绝决定
  • Stop 事件可以用单轮 LLM 判定或多轮子代理判定是否可以收工
  • 官方示例就是所有单元测试通过才允许结束【18】

构建通过 ≠ 行为正确

  • OpenHarmony Bench：平均最终构建成功率在 94.77% 到 100% 之间，而任务完成率只有 48.36% 到 58.39%；更反直觉的是，规格驱动任务的完成率在所有配置下最低，没有一个配置超过 35%【11】。
  • SWE-bench：已解的补丁里 29.6% 依然失败，现有工具只能捕获 65% 的缺陷，误报率 35%【9】。

这两组数字说明：agent 需要的不只是”能跑”的反馈，而是”能判断对错”的反馈。

让 LLM 来做判定也有边界

  • 多 agent 交叉的价值来自探测模式互补，而不是投票：四个专用 agent 的组合把缺陷检出率做到 76.1%，相对单 agent 提升 39.7 个百分点，但增益依次递减 14.9、13.5、11.2 个百分点【9】。
  • LLM-as-Judge 在 agentic 场景里校验评分标准时，即便最强模型也仍有显著噪声，多数投票有效但边际收益递减【10】。

可行的分工：能用断言判的事情交给机器，语义判断交给多个视角的 agent，人保留最终裁决。

3.4 审查层的风险分层漏斗

Meta RADAR —— 目前公开材料里唯一一套有大规模遥测支撑的自动审查体系

它是一条多级漏斗：

  1. 按作者与来源类型分类
  2. 过准入闸门与静态启发式
  3. 由机器学习模型给出 Diff Risk Score
  4. 用 LLM 做自动审查
  5. 最后由确定性校验兜底

关键数字：

  • 53.5 万多个 diff 经过审查，33.1 万多个落地
  • 风险阈值从第 25 分位放宽到第 50 分位后，批准率升到 60.31%
  • 被 RADAR 审查过的 diff，回滚率是非 RADAR diff 的三分之一，生产事故率是五十分之一
  • 中位关闭时长下降超过 330%，审查墙钟时间下降 35%【1】

GitHub Copilot code review —— 把审查做薄并让它可度量

  • 累计 6000 万次审查，用量比推出时增长 10 倍
  • 占 GitHub 全部代码审查的五分之一以上
  • 71% 的审查给出可执行反馈，其余 29% 完全沉默
  • 平均每次 5.1 条评论，且没有增加审查摩擦

它的评估方式更值得借鉴：除了开发者的赞同与反对反馈，还看被标记的问题在合并前是否真的被修掉【17】。

沉默优于噪声，是这套设计里最反直觉也最实用的一条。

Cursor —— 三段式审查的位置分工

阶段执行者关注点
本地自审agent 干完活、还没 push 时盯着 agent 的工作过程，一旦走偏立刻中断；让 agent 一次审完整个分支的完整 diff
PR 阶段Bugbot读得懂改动与代码库其余部分的连接；找空指针、竞态、缺失错误处理与安全问题，而不是 linter 那类格式问题；支持在评论里直接提交修复
合并门团队人工最终裁决

【28】

为了让 diff 可审，Cursor 还给出可落地做法：让 agent 把一个几百行的大提交重写成一串小而语义的提交，并在重写后校验 diff 与原始补丁一致以防丢失【28】。

库内已有条目：[[开源项目分析/AI代码审查/Open-Code-Review-阿里AI代码审查工具|Open Code Review]] 可作为确定性工程 × Agent 混合驱动的对照样本。

3.5 信任层的阈值校准与合并后监控

信任不是被声明出来的，是被回滚率和事故率校准出来的。

  • RADAR 的阈值从第 25 分位调到第 50 分位后批准率升到 60.31%，这个调整之所以敢做，是因为回滚率是三分之一、事故率是五十分之一【1】。
  • Copilot 用问题是否在合并前被修掉来评估自己的审查【17】。
  • Cursor 用解决率并做成长曲线看板【28】。

三个体系把”审查得好不好”换成了可回归的指标，而不是靠人的感觉。

只看是否合并的体系是漏的

一项覆盖 182 个仓库的纵向研究追踪 agentic 贡献在合并之后的表现：

  • 整体维护率与人类贡献接近
  • 但纠正性维护显著更高
  • 引入的安全弱点与依赖漏洞也更多
  • 更直接的一条：项目无审查率每提高 10 个百分点，agentic 维护负担平均增加约 6%【2】

DORA 的稳定性下降 7.2% 是同一问题的团队级投影【15】。

因此合并之后的回流指标必须回到体系里：回滚率、生产事故率、缺陷回流、agentic 贡献的纠正性维护占比。

3.6 边界层的权限与攻击面

当大部分代码由 agent 产出，失效路径不再只有”人写错”。

对 agentic 编码助手的 prompt injection 系统性分析（综合 2021 到 2026 年的 78 项研究，梳理出 42 种攻击技术）显示：

  • 在适应性攻击策略下，对现有防御的成功率超过 85%
  • 所评估的 18 种防御里多数缓解率不足 50%
  • 作者因此主张把 prompt injection 当作需要架构级缓解的一等漏洞类别【12】

主流工具的防线设计

Codex【19】

  • 默认关闭网络访问
  • 本地用操作系统强制的沙箱把可见范围限制在当前工作区
  • 再用审批策略控制何时必须停下来问人
  • 官方给出的只读推荐组合：sandbox_mode 设为 read-only 加上 approval_policy 设为 on-request
  • 更严格的 untrusted 审批策略已经被下线

Claude Code【18】

  • 钩子以用户的完整权限执行 shell 命令，官方明确要求校验输入、防范路径穿越、跳过 .env 等敏感文件
  • 更值得注意的是工作区信任的边界：交互式会话会先扣住 settings 文件里的钩子，直到用户接受信任对话框
  • 而 -p 或 SDK 模式从不弹这个对话框，直接把仓库内 .claude/settings.json 里的钩子当作已信任执行——在 CI 里跑 agent 时，这正是真实的攻击面
  • MCP 工具以 mcp__<server>__<tool> 命名，因此可以用匹配规则在钩子里直接拦截对特定工具的调用

判据很简单：agent 的权限应当与它能造成的最大损失成正比，而不是与它的能力清单成正比。

四、热门项目机制对照

下表按机制而非按产品归类，列出各项目在质量体系中负责的环节与可以直接借鉴的设计。

项目类型关键机制可借鉴点
Meta RADAR【1】自动审查体系风险分层漏斗加阈值反校准用回滚与事故数据调阈值
GitHub Spec Kit【21】规格驱动工具链宪法、规格、计划、任务、实现、收敛宪法即项目级工程宪法
Amazon Kiro【20】agentic IDErequirements、design、tasks 三件套与审批门已知场景走无审批的快路径
Claude Code【18】agentic CLI五类钩子处理器与规则文件确定性闸门插入 agent 生命周期
Cursor【28】agentic IDE本地自审、Bugbot 审查、可观测解决率审查三段式与解决率看板
GitHub Copilot code review【17】平台内审查沉默优先、双信号评估以问题是否被修掉评估审查
OpenAI Codex CLI【19】agentic CLI沙箱、审批策略、AGENTS.md默认关网络的最小权限
OpenSpec【24】规格驱动工具轻量事实源，产物任意顺序可编辑规格作为唯一事实源
BMAD-METHOD【25】角色化方法论十二个以上角色逐级交接产物用角色分工代替单体提示词
GSD core【26】上下文工程框架每阶段全新上下文的产物树对抗长会话退化
obra/superpowers【22】技能化工作流把流程做成可复用技能纪律以技能形式分发

这些项目分属不同品类，机制上却收敛到同样三件事：

  1. 把意图前置为可校验的契约
  2. 把判定拆成确定性与语义两层，并让确定性先行
  3. 把合并之后的坏结果纳入反馈回路

差别只在工程品味与落地节奏。

五、度量体系与效果评估

要证明体系有效，需要一组能被趋势检验的指标，而不是一张”AI 写了多少代码”的报表。

四组指标够用：

指标组具体指标回答什么问题
交付稳定性变更失败率、事故率、平均恢复时间体系当下是否成立
判定质量审查解决率、误报率、规格合规率体系当下是否成立
审查覆盖及时审查率、无审查率体系是否在积累负债
长期代价agentic 贡献的纠正性维护占比、引入的安全弱点与依赖漏洞数体系是否在积累负债

前两组告诉你体系当下是否成立，后两组告诉你它是否在积累负债。

DORA 组织能力模型：一个更上位的判据

据二手材料转述，模型列出七项组织能力：

  1. 内部开发者平台
  2. AI 可访问的内部数据
  3. 清晰的 AI 立场
  4. 以用户为中心
  5. 小批量
  6. 版本控制
  7. 对 AI 的信任

结论：同样采纳率下，具备这些能力的团队吞吐上升而稳定性下降被抑制；不具备的团队吞吐与不稳定同升，投资回报转负【15】。

同一份报告给出的组织动作与效果关联同样值得对照：

组织动作AI 采纳度相对提升
透明沟通岗位焦虑+125%
提供固定工作时间学习 AI 工具+131%
制定明确可接受使用政策+451%

【15】

信任本身是变量：39% 的开发者对 AI 输出只有轻微或不信任【15】。这部分损失不来自模型能力，而来自判定不可复核。

度量本身也有陷阱

  • 衡量 AI 应按它清除了多少瓶颈，而不是按它写了多少代码【15】。
  • 部署频率通常先于变更失败率移动，是瓶颈转移的早期信号【15】。
  • 起步阶段会有一段学费：采用后即时生产力因学习成本、验证成本与流水线适配而短暂下降，这是转型成本而非体系失败【15】。
  • 方法论上还要求先取基线——没有采用前的数字，就无法区分 AI 带来的变化与日常波动。

体系本身也需要被评测

  • Meta-Harness 把 harness 代码当作可优化对象并给出基准【13】
  • SWE-bench 官方榜单为可比性固定执行环境【27】

对团队而言含义相同：规约文件、钩子配置与规格模板都是代码，应当有回归用例，改动后要验证它是否仍然能拦住该拦的东西。

六、落地路径与常见误判

落地顺序决定了成本。 按收益与风险比，前三个阶段分别是把确定性变成闸门、把意图前置为契约、把审查交给 AI 并用数据校准信任。

阶段动作产出物度量
一、确定性闸门把测试、类型检查、lint、依赖与 SAST 接进 agent 的编辑与收工路径每条变更都有机器判定与明确的失败原因判定耗时、失败率、逃逸缺陷数
二、意图契约选一类变更强制走规格到计划到任务，规格含可断言的验收标准规格文件、验收标准、任务清单规格合规率、缺陷逃逸率、bug 修复提交占比
三、AI 审查与信任校准上 AI 审查与风险分层自动放行，用回滚与事故数据反校准阈值风险评分与阈值、升级路径、审查解决率看板审查解决率、无审查率、回滚率、事故率

三个阶段的顺序不能颠倒：在闸门与契约到位之前引入自动放行，等于把未校准的信任规模化。

四个常见误判

误判一：把”AI 写了多少代码”当成质量指标。

  • Google 的 75% 里本就含”经工程师批准”【29】；去掉批准环节的自主生成量不是质量指标
  • Meta 的 105.9% 是代码规模，与缺陷率、稳定性之间没有直接映射【1】

误判二：用基准分数替代工程质量。

  • SWE-bench 类基准衡量的是”特定仓库上通过既有测试的能力”，官方榜单本身需要固定执行环境才能让分数可比【27】
  • 已解补丁中仍有 29.6% 失败【9】
  • 构建成功率 94.77% 以上时，任务完成率可以低到 48%【11】

误判三：只做合并前把关。

  • 182 个仓库的纵向证据表明 agentic 贡献的纠正性维护与安全弱点更高【2】
  • 无审查率每升 10 个百分点，agentic 维护负担增加约 6%【2】
  • 只看合并通过率会系统性高估质量

误判四：用更强的模型替代体系。

  • 阈值、规约与规格不会随模型换代自动更新
  • DORA 数据指向的因果方向很清楚：AI 放大既有的工程实践，基础薄弱的团队放大的正是薄弱环节【15】

人工省下来的是什么

人工能省下来的不是注意力，而是判定成本。

  • Meta 用 53.5 万次审查把结论压成一个可调阈值【1】
  • GitHub 用两个信号定义审查是否有用【17】
  • Cursor 用一个解决率让审查效果可回归【28】

共同之处是都不再依赖”信任 AI”，而是靠回滚率、事故率与解决率把信任变成一个能被证伪的数字。

留在体系里的三件事因此清楚：写契约、设阈值、裁决例外。

这也是它与”让人审得更仔细”的本质区别：后者随产出量线性消耗人力，前者把审查带宽交给机器，把人的时间集中在少数几次真正需要判断的地方。

七、与本库已有条目的关系

  • [[开源项目分析/AI编码工程化/spec-kit-GitHub官方规范驱动开发|spec-kit]] — 意图层的代表实现，对应第【21】项与 §3.1 落地形态
  • [[开源项目分析/AI编码工程化/Superpowers-AI编码工程师方法论与Skills框架|Superpowers]] — 规约层的”技能化工作流”，对应第【22】项
  • [[开源项目分析/AI编码工程化/Trellis-AI编码工程框架|Trellis]] — harness 化的另一条路线（跨平台适配器 + spec 学习闭环）
  • [[开源项目分析/AI编码工程化/Ralph-Autonomous-AI-Coding-Loop|Ralph]] — 上下文工程对照样本：每轮 fresh context，对应 §3.2
  • [[开源项目分析/AI编码工程化/Skill-Based-Architecture-项目级Skill编写方法论|SBA]] — 规约层钩子实践（SessionStart/PreToolUse），对应 §3.6
  • [[开源项目分析/AI代码审查/Open-Code-Review-阿里AI代码审查工具|Open Code Review]] — 审查层对照样本：确定性工程 × Agent 混合驱动
  • [[开源项目分析/AI编码工程化/GitHub-Copilot-降本实践-任务质量优先|GitHub Copilot 降本实践]] — 与 §1.3”AI 产出规模 ≠ 质量”的判断互补

八、参考来源

  1. Meta RADAR: Automating Low-Risk Code Review at Meta. https://arxiv.org/abs/2605.30208
  2. Do These Violent Delights Have Violent Ends? Measuring the Post-Merge Fate of Agentic Code. https://arxiv.org/abs/2607.09902
  3. The EPIC Framework for Spec-Driven Development. https://arxiv.org/abs/2610.07534
  4. Grounding AI Agents in Contracts: An Empirical Evaluation of Spec-Driven Test Generation. https://arxiv.org/abs/2608.17177
  5. Spec-Driven Development as Prescribed and as Practiced. https://arxiv.org/abs/2608.25202
  6. Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork. https://arxiv.org/abs/2609.00252
  7. From Prompt to Process: a Process Taxonomy and Comparative Assessment of Frameworks Supporting AI Software Development Agents. https://arxiv.org/abs/2606.04967
  8. The Spec Growth Engine: Spec-Anchored, Code-Coupled, Drift-Enforced Architecture for AI-Assisted Software Development. https://arxiv.org/abs/2606.27045
  9. Multi-Agent Code Verification via Information Theory. https://arxiv.org/abs/2511.16708
  10. Can LLM-as-a-Judge Reliably Verify Rubrics in Agentic Scenarios? https://arxiv.org/abs/2606.29920
  11. OpenHarmony Bench: Evaluating LLMs and Coding Agents on OpenHarmony App Development. https://arxiv.org/abs/2608.16022
  12. Prompt Injection Attacks on Agentic Coding Assistants: A Systematic Analysis of Vulnerabilities in Skills, Tools, and Protocol Ecosystems. https://arxiv.org/abs/2601.17548
  13. Meta-Harness: End-to-End Optimization of Model Harnesses. https://arxiv.org/abs/2603.28052
  14. Citation Discipline in Spec-Driven Development: A Cross-Model Empirical Study of Output Determinism and Automated Hallucination Detection in LLM-Generated Code. https://arxiv.org/abs/2606.30689
  15. DORA, Impact of Generative AI in Software Development. https://dora.dev/ai/gen-ai-report/report/
  16. METR, We are Changing our Developer Productivity Experiment Design. https://metr.org/blog/2026-02-24-uplift-update/
  17. GitHub Blog, 60 million Copilot code reviews and counting. https://github.blog/ai-and-ml/github-copilot/60-million-copilot-code-reviews-and-counting/
  18. Claude Code, Hooks reference. https://docs.claude.com/en/docs/claude-code/hooks.md
  19. OpenAI Developers, Agent approvals & security. https://developers.openai.com/codex/sandbox
  20. Kiro Docs, Specs. https://kiro.dev/docs/specs/
  21. GitHub Spec Kit. https://github.com/github/spec-kit
  22. obra/superpowers. https://github.com/obra/superpowers
  23. addyosmani/agent-skills. https://github.com/addyosmani/agent-skills
  24. Fission-AI/OpenSpec. https://github.com/Fission-AI/OpenSpec
  25. bmad-code-org/BMAD-METHOD. https://github.com/bmad-code-org/BMAD-METHOD
  26. open-gsd/gsd-core. https://github.com/open-gsd/gsd-core
  27. SWE-bench Official Leaderboards. https://swe-bench.github.io/
  28. Cursor Learn, Reviewing and testing code. https://cursor.com/learn/reviewing-testing
  29. Mike Litman, Edited by Humans. https://mikelitman.me/blog/edited-by-humans.html